背景
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个线程
