记一次哈啰物联网平台规则引擎kafka消息积压线上事故复盘

背景

2022.1.20晚上8点业务线开始切换LBS相关流量，在之后的1个小时时间内，积压量呈明显上升趋势，一路飙到50W左右。

现象一：kafka积压图

这幅图比较明显可以看出，消费者消费速度跟不上生产者的生产消息速率，导致客服端消费出现积压的情况。

现象二：kafka消费详情监控大图

当时现场图后来就找不回来了，凭印象说明了一下数字。

​

这幅图经过分析我们知道这个topic对应的partition默认是20，由于我的消费组内消费者实例数是17个，所以从宏观上分析，势必会有3个消费者会承担多消费一个分区的情况。

其他都会只是1个实例消费一个partition的情况。

原因分析

原因主要还是跟消费者自身的消费速率有关。

忙日志分析

规则引擎拿到设备消息后会同步调用下游一个LBS地图服务。

过程：将设备上报的内容（含地理位置信息）经过LBS平台服务，换取设备当前地理位置坐标信息。

在终端输入命令：thread-n3-i 500

阿里开源诊断工具Arthas：thread命令

列出500毫秒内最忙的3个线程栈，其中就有两个属于调用地理位置服务的线程。

上述说明这个地理位置服务其实吞吐率并不高。

查看下游服务指标

​

这幅下游服务指标更形象的说明这一点。

总结

通过上述的分析我们​总结以下原因：

1）消费者线程数设置不合理

我们自己封装了相应SDK：HMS-Client。

应用内设置了消费线程的数量是5。

这个项目是其他项目拷贝过来，其他项目可能流量没那么大，所以设置了比较低的值。

意思是最高只会有5个线程去拉取消息来消费。

因为我的应用资源利用率不高，提高消费线程数是合理的。

2）尽可能提高单个消费者利用率

​

目前只有2-3个实例会去处理多个partition,其他大多数实例只会处理一个partition,在不缩容服务实例数的情况下（我的实例数是17个），当下实例的处理效率是不高的。

解决方案

第一步：

增加KAFKA的分片数（临时止血方案）让中间件从原来的分片数20调整到60，积压下降的非常明显。消费组内的消费者实例一个承担了基本3-4个分区消息数。

第二步：

调整Client 消费线程数，从原来的5调整到20个线程