Zookeeperbug的排查方法

本篇内容主要讲解“Zookeeper bug的排查方法”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“Zookeeper bug的排查方法”吧!

起因

某一天突然有同事说zk client连不上server，考虑到最近业务代码没有变更，怀疑是运维同学做了什么操作导致，急忙联系运维同学，确实最近做了变更。为了避免扩大影响范围，先让运维同学回滚了变更，回滚后可以正常访问了。

复现问题

询问运维同学后，得到变更流程：由于zk集群有一台服务器存在性能隐患，需要变更到新的一个实例。于是运维先将新机器加入zk集群，修改旧服务器上配置逐个重启，重启后新zk的角色是leader，此时zk状态正常，运维同学也就认为变更完成。

结果意想不到的是使用mntr命令查看，所有的机器状态都是正常，但是zk client无法访问，一访问就卡住，问题可以在测试环境稳定复现。

问题排查

1 猜测zk端口没有监听成功，登录服务器使用netstat查看server打开的三个端口都是正常状态，也使用了telnet测试可以连上。

2 猜测同步节点数不足一半，或者follower连不上leader触发重新选举，但很快就被排除，因为上面说了使用mntr命令查看节点状态都正常，从日志中也未能找到对应日志记录。

3 我们再使用stat来观察server的连接情况，运行zk client发现server收到了client的请求，但是没有回消息，看来原因就是zk server没处理client的请求了。

跟踪到这里，就应该进入源码了，由于对zk源码不熟悉，咨询了某位大佬，建议我们看zk请求处理类CommitProcessor。

在CommitProcessor我们发现了原因，代码如下：

@Override public void start() {     ...     if (workerPool == null) {         workerPool = new WorkerService("CommitProcWork", numWorkerThreads, true);     }     ... }  public void shutdown() {     LOG.info("Shutting down");      halt();      if (workerPool != null) {         workerPool.join(workerShutdownTimeoutMS);     }      if (nextProcessor != null) {         nextProcessor.shutdown();     } } 复制

在shutdown中调用了 workerPool.join实际上已经将请求处理的开关关闭了，但是并没有将workerPool设置为null。在start方法中会根据workerPool==null来创建WorkerService并开始处理请求。

修改后重新验证解决。

到此，相信大家对“Zookeeper bug的排查方法”有了更深的了解，不妨来实际操作一番吧！这里是编程笔记网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！