Kafka消费慢优化

更多请关注：https://t.zsxq.com/fhroW

案例1：SQL导致消费慢

• 现象：消息堆积严重，排查日志后发现耗时主要在查库操作、Redis操作。SQL耗时较为严重。

如果代码中有打印耗时最好，如果没有打印耗时，需要逐行排查日志，结合时间找到耗时的操作。

SQL和Redis操作的耗时都可以从几个方面来分析：获取连接耗时、执行查询耗时、返回数据耗时。

获取连接耗时并不好排查，可以通过独立连接池来测试，正常来说，连接池内连接充足时获取连接都很快。

执行查询耗时可以通过执行计划、数据量等判断

返回数据耗时也不好排查，如果返回数据量很大，可能会有问题。

• 解决：优先解决SQL耗时，结合业务，消费逻辑中的SQL大多都是查询配置类数据的SQL，将此类SQL改造为查询Redis，Redis有效期根据业务设置过期时间，以防数据更改。

案例2：投递下游队列导致消费慢

• 现象：消息堆积严重，排查后发现消费逻辑中，还要逐条投递到下级队列中。

• 解决：改为批量投递，然而kafka并没有批量投递的功能，所以改造下级队列消费逻辑，投递消息体再封装一遍，dto中包含List

• 注意：

• 改造后投递的消息较大，可能超过了kafka单次投递的最大字节数，需要在代码中判断。

• 同时要考虑下级队列消费能力是否能跟上，上级队列消费速度提升后，下级队列的消费压力也会增加，所以也要评估下级队列消费能力。

案例3：服务CPU高导致消费慢

• 现象：消息堆积严重，A服务部署了三个实例，在三台机器，通过kafka分区堆积情况发现，其中一个实例消费的分区堆积数量明显多余其他分区。

而后发现这个实例所在机器还部署有其他重要服务。

• 分析：猜测服务器资源不足导致该实例CPU飙高，将该机器其他服务迁走之后，发现消费能力略有提升，但不明显。通过监控发现该实例的负载高、CPU高，即使是迁走服务之后也没有降下去。这个服务是接收回调的，所以业务高峰期有大量回调时会有大量请求。可能是三个实例不足以处理请求了.

• 解决：新增一台实例，部署在新服务器上。之后发现消费能力提升极大。。。

• 注意：新增实例后要注意调整消费者线程数，本例中分区数为12，加实例之前线程数为4，加之后调整为3

案例4：路由策略导致个别分区积压

• 现象：消息堆积，查看分区堆积情况后发现，仅个别分区堆积，再查看日志，部分分区每次消费都是500条，部分分区每次只消费几十条。

• 分析：路由策略导致消息分配不均衡

• 解决：本业务是聊天内容处理，以chatId为路由键，业务需要保持同一个chatId的消费顺序，所以路由键不能调整。

• 注意：对于有消费顺序的业务，路由键还是不要轻易调整，如果非要调整，调整之后要保证旧路由键的消息处理完之后，再处理新的路由过来的消息