建议使用以下浏览器,以获得最佳体验。 IE 9.0+以上版本 Chrome 31+ 谷歌浏览器 Firefox 30+ 火狐浏览器
请选择 进入手机版 | 继续访问电脑版
设置昵称

在此一键设置昵称,即可参与社区互动!

确定
我再想想
选择版块
直达楼层
标签
您还可以添加5个标签
  • 没有搜索到和“关键字”相关的标签
  • 云产品
  • 解决方案
  • 技术领域
  • 通用技术
  • 平台功能
取消

采纳成功

您已采纳当前回复为最佳回复
发表于2018年08月08日 17:50:52 2975 1
直达本楼层的链接
楼主
显示全部楼层
Kafka无法消费!?究竟是bug的“沦丧”还是配置的“扭曲”?


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


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

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


那如何确定Consumer GroupCoordinator呢?分两步走:

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

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

21中计算的该partitionleader所在的broker就是被选定的Coordinator

定位过程

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

      1.jpg

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

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


1.   61015:48:30,006 Broker 1成为controller

2.jpg

此时感知的节点为12,节点3 zk读不出来:

3.jpg

31847的时候把__consumer_offsets的分区3Leader选为1ISR[1,2]leader_epoch14

4.jpg

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

5.jpg

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

6.jpg

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

7.jpg

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

3. Broker 212号的21:43:19又感知Broker 1网络中断,并处理节点失败事件:

8.jpg

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

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

       9.png

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

    10.png

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

根因总结

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

问题总结

    这是一个典型的由于网络异常导致脑裂,进而出现了多个Controller,华为云分布式消息服务(DMSKafka经过电信级的可靠性验证,已经完美解决了这些问题,您值得拥有!



欢迎扫码查看更多精彩:

中间件小哥.jpg

举报
分享

分享文章到朋友圈

分享文章到微博

采纳成功

您已采纳当前回复为最佳回复

高晓云

发帖: 33粉丝: 52

级别 : 版主

发消息 + 关注

发表于2018年08月09日 09:16:14
直达本楼层的链接
沙发
显示全部楼层

嚯嚯

点赞 评论 引用 举报

游客

富文本
Markdown
您需要登录后才可以回帖 登录 | 立即注册

结贴

您对问题的回复是否满意?
满意度
非常满意 满意 一般 不满意
我要反馈
0/200