2019-03-29
记一次16个小时的 beta 环境 zk 集群故障
最近公司的 beta 环境 zk 集群经历了一次大震荡，16个小时的恢复时间，听起来就感觉不可思议，但是问题真的没那么简单 。。。
发现问题的过程：
1. 当天下午有开发人员找我们说应用连不上 db （db的相关信息保存在中间层的 zk 里面）, 但是其他应用是可以连上的。通过 zk client 连上 zk server 发现 zk 节点下有对应 db 信息。 接下来仔细查看应用启动日志，发现里面有多次连接 zk 失败并不断重连的记录，再通过 netstat 查看到 zk server 的连接，发现连接没有建立成功。
2. 在有问题的宿主上 telnet zk 地址发现连接超时，这时确认是 zk 集群出了问题
3. 联系 zk 团队负责人并处理
zk 集群负责团队的处理过程
1. 逐个重启 zk
2. 重启过程中发现，其他节点都登陆不上了
3. 通过监控发现，各个节点的 tcp 连接爆增
4. ops 临时把 zk 集群的网络流量都封了
5. 扩容 zk 集群，调整为 8 个节点，调大了 zk session timeout, 并逐个重启 zk 节点
6. 逐渐放开流量
7. 全部放开后，集群又被击垮了，每个节点已经建立的 zk 连接达到 65000 个
8个节点加起来一共50多万已建立的连接
8. 重新调整 zk 参数，并让 ops 重新封流量，并重启 zk
9. 放开流量，不过又被击垮了
- 封流量，并对客户端 ip 进行限流，分析问题
抽查了一些应用宿主，发现机器又很多和 zk 的连接状态是 sync_sent， 难怪zk 集群会有那么多连接
开发人员查了一下 client 端代码，发现处理连接的地方有 bug, 如果失败会不断重连。而 zk server 端的 maxClientCnxns 默认值是60， 所以每个 client 最多会有60个并发连接，客户端也在不断重试 - 找到问题后，最简单的办法是重启所有环境的应用，但是由于应用众多 (超过5000个)，有依赖关系，重启后各个开发人员想恢复也需要很久，所以没有选择重启应用。
- 最后负责 zk 的一起决定新建 zk observer 集群，老集群继续封流量，有问题的应用需要用户自己该下 zk 地址并重启
整个过程包括开发人员配合改新的地址一共耗费了 16个小时
事后总结：
1）beta 环境的 zk 监控有限
2） zk 集群的恢复手段需要完善
3）中间件客户端代码处理连接部分的 bug 需要修复
4）思考如何处理大流量集群的故障治愈，减少故障时间
