在一个月黑风高的夜晚，突然收到现网生产环境 Kafka 消息积压的告警，梦中惊醒啊，马上起来排查日志。

成都创新互联长期为上1000+客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为原州企业提供专业的网站制作、网站设计，原州网站改版等技术服务。拥有十年丰富建站经验和众多成功案例,为您定制开发。

问题现象：消费请求卡死在查找 Coordinator

Coordinator 为何物？ Coordinator 用于管理 Consumer Group 中各个成员，负责消费 offset 位移管理和 Consumer Rebalance 。 Consumer 在消费时必须先确认 Consumer Group 对应的 Coordinator ，随后才能 join Group ，获取对应的 topic partition 进行消费。

那如何确定 Consumer Group 的 Coordinator 呢？分两步走：

1 、一个 Consumer Group 对应一个 __consumers_offsets 的分区，首先先计算 Consumer Group 对应的 __consumers_offsets 的分区，计算公式如下：

__consumers_offsets partition# = Math.abs(groupId.hashCode() % groupMetadataTopicPartitionCount ，其中 groupMetadataTopicPartitionCount 由 offsets.topic.num.partitions 指定。

2 、 1 中计算的该 partition 的 leader 所在的 broker 就是被选定的 Coordinator 。

定位过程

Coordinator 节点找到了，现在看看 Coordinator 是否有问题：

不出所料， Coordinator 对应分区 Leader 为 -1 ，消费端程序会一直等待，直到 Leader 选出来为止，这就直接导致了消费卡死。

为啥 Leader 无法选举？ Leader 选举是由 Controller 负责的。 Controller 节点负责管理整个集群中分区和副本的状态，比如 partition 的 Leader 选举， topic 创建，副本分配， partition 和 replica 扩容等。现在我们看看 Controller 的日志：

1.          6 月 10 日 15:48:30,006 秒 Broker 1 成为 controller

此时感知的节点为 1 和 2 ，节点 3 在 zk 读不出来：

31 秒 847 的时候把 __consumer_offsets 的分区 3 的 Leader 选为 1 ， ISR 为 [1,2] ， leader_epoch 为 14 ：

再过 1 秒后才感知到 Controller 发生变化，自身清退

2.          Broker 2 在其后几百毫秒后 (15:48:30,936) 也成为 Controller

但是 Broker2  是感知到 Broker 3 节点是活的，日志如下 :

注意这个时间点， Broker1 还没在 zk 把 __consumer_offsets 的分区 3 的 Leader 从节点 3 改为 1 ，这样 Broker 2 还认为 Broker 3 是 Leader ，并且 Broker 3 在它认为是活的，所以不需要重新选举 Leader 。这样一直保持了相当长的时间，即使 Broker 1 已经把这个分区的 Leader 切换了，它也不感知。

3.          Broker 2 在 12 号的 21:43:19 又感知 Broker 1 网络中断，并处理节点失败事件：

因为 Broker 2 内存中认为 __consumer_offsets 分区 3 的 Leader 是 broker 3 ，所以不会触发分区 3 的 Leader 切换。

Broker 2 但是在处理失败的节点 Broker 1 时，会把副本从 ISR 列表中去掉，去掉前会读一次 zk ，代码如下：

但是发现 zk 中分区 3 的 Leader 已经变为 1 ， ISR 列表为 [1,2] ，当要去掉的节点 1 就是 Leader 的时候， Leader 就会变为 -1 ，  ISR 只有 [2] ，从日志也可以看到：

这样分区 3  的 Leader 一直为 -1 ，直到有新的事件触发节点 2 重新选举才能恢复（例如重启某个节点）。

根因总结

出现网络异常后，由于新老 controller 之间感知的可用节点不同，导致新 controller 对某个分区的 Leader 在内存中的信息与 zk 记录元数据的信息不一致，导致 controller 选举流程出现错误，选不出 Leader 。   需要有新的选举事件才能触发 Leader 选出来，例如重启。

问题总结

这是一个典型的由于网络异常导致脑裂，进而出现了多个 Controller ，菊厂分布式消息服务 Kafka（ https://www.huaweicloud.com/product/dmskafka.html ） 经过电信级的可靠性验证，已经完美解决了这些问题 。

 

当前标题：Kafka无法消费?!我的分布式消息服务Kafka却稳如泰山！
本文路径：http://hbruida.cn/article/jsgdgd.html