kafka大量消息堆积故障复盘
- 一、前言
- 二、过程复盘
- 三、总结
- 1、产生原因
- 2、解决方案
- 2.1、优先处理堆积数据，恢复生产环境
- 2.2、处理堆积数据
一、前言
这个事是上个老东家遇到的，我是一个旁观者的角度目睹整个故障的产生和修复，过后也未进行总结复盘。最近吧，自己被安排解决kafka重复消费的一些问题，就想起来这个事，索性就把整个事件进行一个回顾，另外也把kafka大量消息堆积的处理方案也进行总结归纳，这个问题还是比较常见的。
二、过程复盘
某一天晚上，公司某一个程序员写的某一个程序挂掉了，服务呢也没有被重新拉起来。这个服务的逻辑并不是很复杂，主要是消费kafka消息并计算出一个数据，但并发量很大，每天有大概几百w的量级。
这个服务挂掉后，kafka集群的消息就一直开始堆积，到第二天来到公司后发现，大概一共堆积了200w的消息，重启服务器后，发现以服务的消费速度要完全消费掉所有的堆积数据也需要1天多，这么多的数据很明显不能让他持续堆积着，一个是影响最新数据的处理，另外也占用多余的资源。
所以我们技术部的大leader提出了一个解决方案，新增一批5个消费者和5个kafka分区，这些消费者的主要功能是消费数据并入库存储（临时开发），一个消费者qps为500，5个消费者一分种的吞吐量为500 * 60 * 5 = 15w，200w堆积消息20分钟内能解决掉。当然这只是第一个步骤，这个步骤完成后可以保证生产环境正常工作。
第二个步骤，解决这些未消费的消息。正常情况下，我们的消费者的吞吐量远大于生产者的吞吐量的，我们只需要把再写一个服务：把临时存储的200w堆积消息，以不会产生堆积的速度再次生产到kafka集群中，让消费者消费掉就可以了。
三、总结
懒的画图了，贴个还算清晰的kafka的架构图：
1、产生原因
- consumer意外down机
- consumer吞吐量低于producer
- partition分区过少
- consumer处理超时，导致频繁rebalance
2、解决方案
2.1、优先处理堆积数据，恢复生产环境
- 增大partition个数
- 增加消费者数量
- 消费堆积数据入库保存
- 减少consumer处理时长
- 避免产生rebalance
注意：
同一个消费群组的consumer个数要等于partition个数，这样能让consumer的消费能力提升到最大。
同一个topic下的partition和sonsumer对应关系：
2.2、处理堆积数据
- 非时间敏感数据，读库并生产到消费队列。
- 时间敏感数据，梳理业务影响，采取能保证数据一致性的方案，如手动导入、重新构造等等。
参考链接：
Kafka 消费者与消费组
如何处理大量积压消息
