偶然的一天，发现redis一个实例无法启动，启动的时候，从 aof 文件往内存中加载数据的时候，出现了错误：

1

Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix filename

提示，需要使用 redis-check-aof 来修复 aof 文件。

按照其步骤，先备份再修复：

1
2
3
4
5
6

[root@hostname 6379]# redis-check-aof --fix appendonly.aof
0x        6a60a5cb: Expected prefix '
AOF analyzed: size=1784722401, ok_up_to=1784718795, diff=3606
This will shrink the AOF from 1784722401 bytes, with 3606 bytes, to 1784718795 bytes
Continue? [y/N]: y
Successfully truncated AOF

修复完成后，重新启动 redis 就能正常启动了。

同样，redis 如果采用的 rdb 模式持久化数据的话，如果需要修复 rdb 文件，可以使用 redis-check-dump file.rdb 来修复。

面对复杂的查询或者算分逻辑，Elasticsearch 可以使用 Scrpits 脚本功能来实现，实际项目之中也用的非常频繁。
在脚本中需要访问文档中的字段，此时有三种方式可以访问，分别是 doc , _fields , _source。这三个字段使用的时候还是有区别的。

1
2
3
4
5
6
7
8
9
10
11
12
13

"filtered" : {
    "query" : {
        ...
    },
    "filter" : {
        "script" : {
            "script" : "doc['num1'].value > param1"
            "params" : {
                "param1" : 5
            }
        }
    }
}

下面通过几个示例脚本来分别说明三者之间的区别。

Linux 可使用 sort 命令来对文件内容或者其他命令的输出内容进行排序。常见的场景是按大小排列日志文件、按文件名排序等。

sort 命令常用的参数有：

• r sort默认排序为升序，如果需要降序，则执行 -r即可。reverse
• n sort排序默认是当做字符来排序的，所以会遇到 10<2 的情况,使用 n 让其当做 number 来排序
• u 去重,排重
• t 指定分割符号，有时候需要将内容分割，按照其中部分内容排序
• k 指定排序列，一般配合 t 使用，注意，列从 1 开始
• o 将输出结果重定向写入文件，写入原文件时不能使用 > 。

example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

[root@linux]$ls search2*|sort -rn -k 4 -t '.'
search2.stdout.log.20
search2.stdout.log.19
search2.stdout.log.18
search2.stdout.log.17
search2.stdout.log.16
search2.stdout.log.15
search2.stdout.log.14
search2.stdout.log.13
search2.stdout.log.12
search2.stdout.log.11
search2.stdout.log.10
search2.stdout.log.9
search2.stdout.log.8
search2.stdout.log.7
search2.stdout.log.6
search2.stdout.log.5
search2.stdout.log.4
search2.stdout.log.3
search2.stdout.log.2
search2.stdout.log.1
search2.stdout.log

在 beego 群里，有同学问了一个看似比较的简单的问题。问题是这样的: 一个beego web项目，将项目的端口号从默认的 8080 改为 6666 之后通过 Chrome 浏览器无法访问，但是通过其他浏览器却可以访问。

但是并未在意，认为这可能是chrome浏览器或者系统不小心配置了代理导致的，后来我自己在本机上也实验以下，将应用端口改为 6666 之后，通过 Chrome 浏览器也无法访问。报错信息如下:

1
2
3
4

This site can’t be reached

The webpage at http://localhost:6666/ might be temporarily down or it may have moved permanently to a new web address.
ERR_UNSAFE_PORT

报错信息中提到了 ERR_UNSAFE_PORT。

解决方案：

1

/Applications/Google Chrome.app/Contents/MacOS/Google Chrome --explicitly-allowed-ports=6666,8888

或者换端口，避开Chrome的非安全端口限制。
参考资料：

• https://jazzy.id.au/2012/08/23/why_does_chrome_consider_some_ports_unsafe.html
• https://support.google.com/chrome/forum/AAAAP1KN0B0l5d-nXEjLMM?hl=en
  Read more »

记得当初刚接触学习 golang 的时候,当时使用还是 go 1.4版本,和其他语言的入门一样，写了一个简单的 hello world 程序。

1
2
3
4
5
6
7

package main

import "fmt"

func main() {
	fmt.Println("Hello World!")
}

程序非常简单，整个源文件大小才 4KB。然后执行 go build 编译成可执行文件，结果让我非常惊讶的是这段简单的代码生成的可执行文件竟然有4M之多。