golang 中自带了非常方便解析json 的库 encoding/json,一般情况下也是使用这个库来作为 json 的 encode / decode。但是在有些场景下，比如解析大量json格式的日志数据的时候，json的解析性能问题就是一个需要特别关注的问题了。

滴滴出行平台技术部的开源json解析库 json-iterator，性能比原生的 encoding/json 快很多。

下面自己就简单测试了下两者的区别,测试代码很简单，就简单测试了下两者 Unmarshal 和 Marshal 的性能表现：

使用 codis 过程中，当 codis dashboard 异常挂掉之后，重启 codis-dashboard的时候，无法启动，日志报错信息为：

1
2

2017/08/31 14:43:46 dashboard.go:234: [PANIC] create zk node failed
[error]: dashboard already exists: {"addr": "192.168.0.1:28087", "pid": 15716}

提示无法创建 zookeeper node,因为已经存在 dashboard node 了。

处理方案：连上 zookeeper, 删除相应的节点后重新启动 codis-dashboard。

1
2

/usr/local/zookeeper/bin/zkCli.sh -server 192.168.0.1:2181
delete /zk/path/dashboard

codis-dashboard 重新起来之后，发现还是无法连接 codis。

很多语言都支持可变参数，下面记录下平时主要使用的几种语言的可变参数用法。主要有 go、php、python、java、js等语言的可变参数的基本使用。

相信大多数人和我一样，都是在 mac 或者 windows 上写 go 代码，但是最终上线运行却是在 Linux 系统之上。这就涉及到一个问题：由于操作系统架构的差异，编译过后的二进制程序能够在多个系统下正常运行么？

go 不像 java 等运行于 JVM 之上的语言，也不像 php , python 等解释性语言，它需要编译后不依赖于其他环境就能执行，但是编译过程却依赖于系统架构，所以 go 需要交叉编译。

释义：交叉编译，就是在一个平台上生成另一个平台上的可执行代码。

go 非常方便的支持交叉编译。

Search Type 有助于理解 Elasticsearch 在多个分片(shard)的情况下，是如何搜索的，是如何决定返回数据数量、如何排序、如何算分的？

执行过程

在多个分片情况下，查询 0-20 条记录，elasticsearch 会将请求转发到每个分片上，从每个分片上获取 20 条记录，然后返回给分发节点进行汇总，最后再从汇总的结果中取 0-20 数据返回给客户端。
则就是 elasticsearch 分布式搜索的基本的执行过程。

Search Type

Elasticsearch 中的 search type 主要有 6种：Query then fetch、Dfs Query then fetch、Count、Scan、Query and fetch、Dfs query and fetch。