写点什么

Kafka 无法消费,究竟是 bug 的错还是配置的问题?

  • 2019-10-21
  • 本文字数:1459 字

    阅读完需:约 5 分钟

Kafka无法消费,究竟是bug的错还是配置的问题?

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

问题现象

消费请求卡死在查找 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,华为云分布式消息服务(DMS)Kafka 经过电信级的可靠性验证,已经完美解决了这些问题,快点击“阅读原文”了解更多吧!


本文转载自公众号中间件小哥(ID:huawei_kevin)。


原文链接:


https://mp.weixin.qq.com/s/baxyONDEHTlPrSwszjo3Jw


2019-10-21 14:174620

评论

发布
暂无评论
发现更多内容

如何用AR Engine环境Mesh能力实现虚实遮挡

HarmonyOS SDK

AR

大数据学习培训机构怎么去选择

小谷哥

小程序运营怎么做?

源字节1号

软件开发 前端开发 后端开发 小程序开发

LinkedList源码分析(四)

知识浅谈

linkedlist 10月月更

算数、赋值、比较、逻辑、三元运算符

共饮一杯无

Java 运算符 10月月更

数字化转型:营销数字化

小鲸数据

数字化 营销数字化 客户数据平台 CDP 营销数据中台

Python进阶(十)Python 编程规范

No Silver Bullet

Python 编程规范 10月月更

如何在 SAP BTP 平台上重用另一个已经开发好的 service

汪子熙

云原生 SaaS 云平台 SAP 10月月更

STM32L051测试 (二、开始添加需要的代码)

矜辰所致

stm32 STM32CubeMX 10月月更

年底前端面试题总结(上)

loveX001

JavaScript

vivo互联网机器学习平台的建设与实践

vivo互联网技术

人工智能 机器学习 推荐系统

Qt | 深入了解Qt的委托类

YOLO.

qt 10月月更 C++

SeaTunnel连接器V1到V2的架构演进与探究

Apache SeaTunnel

API 数据集成 连接器 Apache SeaTunnel 数据集成平台

Qt | Qt的动画框架和类

YOLO.

qt 10月月更 C++

web前端技术培训学习好点

小谷哥

谈谈前端性能优化-面试版

loveX001

JavaScript

前端培训学习的就业前景是什么样的

小谷哥

前端线下面授培训机构该怎么选择?

小谷哥

又一里程碑!阿里首推Java面试通关手册,必须人手一份!

Geek_0c76c3

Java 数据库 程序员 架构 面试

web3 chainlink 预言机喂价、VRF

1_bit

智能合约 web3 chanlink

打破“双十定律”,华为云AI推动超级抗菌药Drug X研发加速

华为云开发者联盟

AI 华为云 药物研发 盘古大模型 企业号十月 PK 榜

AndroidStudio最新版(2021.1.21)编译C++代码生成so文件

中国好公民st

c++ Android; 10月月更

两数之和

掘金安东尼

算法 10月月更

上岸稳了!GitHub标星115k+的阿里内部Java学习教程限时开源

Geek_0c76c3

Java 数据库 程序员 架构 开发

搜索中常见数据结构与算法探究(一)

京东科技开发者

数据结构 ES 哈希 数据结构算法 搜索算法

MobPush iOS端常见问题

MobTech袤博科技

ios

初学大数据培训学习入门

小谷哥

翻遍GitHub,这份MySQL全面手册,受喜爱程度不输任何大厂笔记

Geek_0c76c3

Java MySQL 程序员 架构 面试

研发效能领域的“百科全书”重磅来袭!

博文视点Broadview

Java数据类型转换

共饮一杯无

Java 类型转换 10月月更

全网首发“Java面试考点大全”,25+专题梳理:JVM+多线程+Spring全家桶+MySQL+Redis等

Geek_0c76c3

Java 数据库 程序员 架构 面试

Kafka无法消费,究竟是bug的错还是配置的问题?_文化 & 方法_余洲_InfoQ精选文章