记一次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.异常日志

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

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

2.定位问题

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

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

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

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

异常的原因是进行初始化的时候,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 重新发布,正常