讲真,我今年的双十一有点“背”,负责的Kafka集群出了一些幺蛾子,但正是这些幺蛾子,让我这个双十一过的非常充实,也让我意识到如果不体系化学习Kafka,是无法做到生产集群及时预警,将故障扼杀在摇篮中,因此也下定决心研读kafka的内核。
本文就先来分享一个让我始料未及的故障:Kafka生产环境大面积丢失消息。
首先要阐述的是消息丢失并不是因为断电,而且集群的副本数量为3,消息发送端设置的acks=-1(all)。
这样严苛的设置,那为什么还会出现消息丢失呢?请听笔者慢慢道来。
1、故障现象
故障发生时,接到多个项目组反馈说消费组的位点被重置到几天前了,截图如下:
从上面的消费组延迟监控曲线上来看,一瞬间积压数从零直接飙升,初步怀疑是位点被重置了。
那位点为什么会被重置呢?
什么?你这篇文章不是说要讲Kafka为什么会丢消息吗?怎么你又扯说消费组位点被重置呢?标题党!!!
NO、NO、NO,各位看官,绝对不是文不对题,请带着这个疑问,与我共同探究吧。
2、问题分析
遇到问题,莫慌,讲道理,基于MQ的应用,消费端一般都会实现幂等,也就是消息可以重复被处理,并且不会影响业务,故解决的方式就是请项目组先评估一下,先人工将位点设置到出现问题的前30分钟左右,快速止血。
一波操作猛如虎,接下来就得好好分析问题产生的原因。
通过查看当时Kafka服务端的日志(server.log),可以看到如下日志:
上面的日志被修改的“面目全非”,其关键日志如下:
- Member consumer-1-XX in group consumerGroupName has failed, removing it from the group
- Preparing to rebalance group XXXX on heartbeat expiration
上面的日志指向性非常明显:由于心跳检测过期,消费组协调器将消费者从消费组中移除,重而触发重平衡。
消费组重平衡ÿ