双十一期间Kafka以这种方式丢消息让我猝不及防

讲真，我今年的双十一有点“背”，负责的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
• Pre