在一个月黑风高的夜晚,忽然收到现网生产环境Kafka消息积压的告警,梦中惊醒啊,立刻起来排查日志。html
问题现象网络
消费请求卡死在查找Coordinator分布式
Coordinator为什么物?Coordinator用于管理Consumer Group中各个成员,负责消费offset位移管理和Consumer Rebalance。Consumer在消费时必须先确认Consumer Group对应的Coordinator,随后才能join Group,获取对应的topic partition进行消费。3d
那如何肯定Consumer Group的Coordinator呢?分两步走:日志
一、一个Consumer Group对应一个__consumers_offsets的分区,首先先计算Consumer Group对应的__consumers_offsets的分区,计算公式以下:htm
__consumers_offsets partition# = Math.abs(groupId.hashCode() % groupMetadataTopicPartitionCount,其中groupMetadataTopicPartitionCount由offsets.topic.num.partitions指定。blog
二、1中计算的该partition的leader所在的broker就是被选定的Coordinator。事件
定位过程内存
Coordinator节点找到了,如今看看Coordinator是否有问题:get
不出所料,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,华为云分布式消息服务(DMS)Kafka通过电信级的可靠性验证,已经完美解决了这些问题,点击这里了解更多~