一、故障描述
4.26号凌晨3点业务服务开始报警,现象表现为消费用户消息的kafka集群出现堆积,导致用户在聊天室房间内的状态更新延迟,最终用户在聊天室房间的IM长链接断开,用户在聊天室中无法发消息,无法上麦。
在问题排查过程中,了解问题流程图如下:
其中主要分为5个模块,分别为:用户、im长链接器、kafka、im-session服务、api服务。
当用户与im-connector建立完长链接以后,用户进入、退出聊天室以及与聊天室的心跳事件均会通过im-connector写入下游的kafka中。
im-sesion服务主要负责消费kafka中的用户事件消息,并写入用户的session信息中,当kafka到im-session这个消费链路出现问题以后,用户在聊天室的session信息错误,导致用户通过api拉取的session信息错误,最终导致了故障。
分析完整体流程以后,其中问题也就主要定位在kafka与消费kafka的im-session之间,im-session消费kafka数据变慢,导致im-session更新用户房间状态延迟,kafka消息积压,进而导致故障产生。
二、排查可能的原因
通过上述分析,我们考虑到是kafka消费慢导致的问题主要涉及三方面可能的原因,于是主要通过以下三个方面来排查问题:
-
kafka本身问题,导致consumer拉取消息慢的问题
-
消费者问题,im-session服务消费慢导致消息延迟的问题
-
网络问题,消息从kafka到consumer之间网络延迟的问题
2.1 kafka问题?
首先我们考虑会不会是kafka自身问题导致,如果是kafka本身出现问题,比如同步数据过程导致磁盘io增加,拉取kafka数据变慢也是有可能的,或者是topic分区离线等也会导致积压问题,于是查看了kafka相关监控信息:
kafka监控:
从上述监控中可以看出,在问题发生时kafka的topic 分区是正常的处于同步状态,没有离线的partition。