文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

Kafka无法消费?!我的分布式消息服务Kafka却稳如泰山!

2023-06-04 21:59

关注

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

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

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

那如何确定Consumer Group的Coordinator呢?分两步走:

一个Consumer Group对应一个__consumers_offsets的分区,首先先计算Consumer Group对应的__consumers_offsets的分区,计算公式如下:

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

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

定位过程

Coordinator节点找到了,现在看看Coordinator是否有问题:

Kafka无法消费?!我的分布式消息服务Kafka却稳如泰山!

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

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

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

Kafka无法消费?!我的分布式消息服务Kafka却稳如泰山!

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

Kafka无法消费?!我的分布式消息服务Kafka却稳如泰山!

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

Kafka无法消费?!我的分布式消息服务Kafka却稳如泰山!

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

Kafka无法消费?!我的分布式消息服务Kafka却稳如泰山!

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

Kafka无法消费?!我的分布式消息服务Kafka却稳如泰山!

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

Kafka无法消费?!我的分布式消息服务Kafka却稳如泰山!

注意这个时间点,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网络中断,并处理节点失败事件:

Kafka无法消费?!我的分布式消息服务Kafka却稳如泰山!

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

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

Kafka无法消费?!我的分布式消息服务Kafka却稳如泰山!

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

Kafka无法消费?!我的分布式消息服务Kafka却稳如泰山!

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

根因总结

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

问题总结

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

 

阅读原文内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯