Kafka消息积压的解决方案

Kafka积压是什么，简单说，就是生产者发消息的速度大于消费者处理消息的速度，于是Lag越来越大，消息越堆越多，Kafka不是你加机器就能快的。
原因是：
（1）Partition数量不够，比如一个Topic只有4个Partition,在同一个消费组里加到20个消费者，也没有用，最多也就4个消费者真正干活，剩下的16个在旁边精神加班，让你以为扩容，实际上只是让监控页面看起来热闹一点；
（2）瓶颈根本不在消费者数量，很多消费逻辑最后都要写数据库、调接口、查缓存、落文件，如果真正慢的是数据库写入、下游接口响应、锁竞争、事务提交，盲目加消费者，只会把更多请求同时打到下游，原来只是Kafka积压，最后可能变成数据库连接池打满、接口超时、线程池爆满，这就像饭店后厨出菜慢，不看锅够不够、厨师够不够，还是煤气没开，上来先招20个服务员，服务员是多了，但是菜还是出不来；
（3）异常消息反复重试，有时候不是整体消费能力不足，而是某几条消息一直处理失败，比如数据格式错了、业务状态不对、下游返回异常，消费者反复拉取、反复失败、反复重试，这时候加消费者没用。
所以Kafka消息积压，不是扩容，而是定位，先看Lag是持续增长，还是短时间突增，再看每个Partition的Lag是否均匀，再看消费者处理耗时，是业务逻辑慢，还是下游依赖慢，再看消费失败率，有没有大量重试，还要看消费者线程池、数据库连接池、接口超时这些地方，如果确认是消费能力不足，那再考虑扩容，但扩容也不是只加消费者实例，要先看Partition数量够不够，如果Partition太少，要评估是否增加Partition，如果单条消息处理太慢，要考虑批量消费、批量写入、异步处理，如果下游扛不住，要做限流、降级、削峰，如果是异常消息导致积压，就要把异常消息隔离出来，比如进入死信队列、失败表、补偿任务，别让一条坏消息拖住整个消费链路，业务系统里最怕的不是消息多，而是坏消息一直在主链路里循环刷存在感。

总结：Kafka消息积压不是看见Lag就扩容，而是先找到Lag为什么变大，扩容只是手段，不是答案，先排查Lag趋势、Partition分布、消费耗时、失败重试和下游依赖，再决定是扩分区、加消费者、优化消费逻辑、批量处理，还是死信和补偿。