某天凌晨接到售后的电话,说线上设备出现了批量离线的问题,下意识以为是之前 Netty 相关服务代码导致的问题又复现了,但是排查了一下发现并不是这个原因
现在把这个问题记录下来,虽然至今还没有找到具体原因但是已经大致缩小了范围
各个服务平台报出无法与 mq 建立连接的错误
查询 mq 服务进程发现进程 pid 还在但是端口号却没了
因为急着解决问题,于是联系运维重启了 mq 服务(这里不应该,其实应该先查一下 mq 进程的状态,这里直接重启导致后面无法细致排查)
事后分析 mq 日志及源码,发现在出现问题之前的一些迹象:
凌晨 00:10,mq 集群 Master 主机发生了不明原因的网络波动,导致 master 与 zookeeper 的连接超时,断开连接
断开连接之后 mq master 自动降级为 slave
mq master 在降级为 slave 的过程中先要将自己的 master 服务和 broker 服务停止,然后以 slave 角色重新启动
在 mq 重启的过程中又恢复了与 zookeeper 的连接
在 mq 停止 master 服务过程中没有停止成功,处于挂起状态
由于 mq master 服务 hang 在挂起状态,导致 mq 集群没有完成角色切换,这个状态就是 master 死了一半,但是其他 slave 依旧还是 slave
整个 mq 集群没有办法对外服务,消费者无法消费,导致 mq 消息堆积,导致设备显示离线
以上就是目前分析出的整个状况,因为没有保留事故现场并且因为急着恢复服务导致没有排查出真正的原因,是什么原因导致的 master 与 zookeeper 连接断开,以及为什么 master 服务会没有完成重启动作