记一次zk集群引发的线上问题-排查策略

 

故障描述(What happened):

10:20 发布estate.realtor.ap.fdd服务(上线)

10:25 发现服务发布失败，看了日志，发现一直在初始化dubbo，时间过长，关掉了健康检查（该服务较重，重启时间较长，健康检查最长120s超时)

10:26 重新发布服务，发布系统发布成功

10:28 业务方发现二手房业务不可用

10:30 回滚到上一个版本(estate.realtor.ap.fdd #6134)

10:35 发现二手房服务仍不可用

10:40 回滚到(estate.realtor.ap.fdd #6134)版本，恢复

 

 

根源分析(What did we learn):

1.异常日志

关掉健康检查后，服务发布时观察日志，发现如下异常：



2.定位问题

发现上述异常是netty抛出的，所以定位到服务使用的dubbox的异常，经过阅读dubbox和netty的相关部分源码，发现异常是如下代码抛出的





经过异常打印的调用链，大致可以得知：

异常的原因是进行初始化的时候，dubbo进行socket连接的时候出现异常；

netty的多路复用模型中的selector初始化失败，之后继续从线程池中拿出的IO worker线程进行连接；

在该连接事件的register方法中selector为null，抛出worker线程shutdown，关闭dubbo进程，服务挂掉；

 

3.继续确认问题

由于dubbo依赖zk，dubbo的连接过程会获取remoteAddress，localAddress进行操作，服务重启不会存在localAddress，所以会去取remoteAddress，zk的不稳定（超时）会对dubbo的注册进行影响；联系到ABC后端群反馈出的no provider问题（zk），大致可以理解成dubbo注册zk超时，导致Selector获取不到正确地址，Set<SelectionKey>无法正常写入（初始化），在register的过程中异常。

 

4.验证猜想

使用master最新版本在测试预发实验，没有问题

15:40 使用最新master版本（estate.realtor.ap.fdd #6140)灰度发布（设置1%的流量），重启后能正常接收请求

16:00 重新发布，正常