AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

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:174632

评论

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

一个独立开发者,他是如何做到月入 20 万的?

非著名程序员

程序员 独立开发者 副业赚钱 开发者 程序人生

阿里笔记之数据模型

迹_Jason

大数据

凡事必先骑上虎背

Steve

学习 态度 方法论

你不是迷茫,只是缺乏目标

Steve

学习 身心健康 方法 自我管理

求稳不得

孙苏勇

职业 发展 职场

黄金思维圈,养成透过现象看本质的能力

非著名程序员

读书笔记 程序员 程序人生 提升认知

越是困难,越是要做有分析判断能力的人

霍太稳@极客邦科技

创业 团队管理 个人成长

申请鲲鹏920测试机试水+编译nginx

草宝虫

nginx 鲲鹏920 centos7 armv8

两边夹的应用二

孙苏勇

算法 两边夹 重排序 函数式接口 Lambda

微服务架构深度解析与最佳实践 - 第三部分

kimmking

微服务 最佳实践 深度解析 高可用

微服务架构深度解析与最佳实践 - 第五部分

kimmking

微服务 最佳实践 深度解析 高可用

数据分析师应该了解的数据湖

数据社

大数据 数据仓库 数据湖 数据分析

最近看了两本书:The Rules of Life 和 Make Big Happen

霍太稳@极客邦科技

创业 团队管理 自我管理

微服务架构深度解析与最佳实践 - 第六部分

kimmking

微服务 最佳实践 深度解析 高可用

程序员职业生涯的八点感想

池建强

程序员 职业

两边夹的应用

孙苏勇

算法 积水问题 两边夹

微服务架构深度解析与最佳实践-第二部分

kimmking

微服务 最佳实践 深度解析 高可用

一个运营经理人的工作两周年总结

霍太稳@极客邦科技

高效工作 身心健康 项目管理 自我管理

微服务架构深度解析与最佳实践 - 第七部分

kimmking

微服务 最佳实践 深度解析 高可用

亚马逊云 AWS LightSail 搭建高性能 LNMP 环境并安全部署 Wordpress

SnowHide雪诺海德

nginx Wordpress 部署 SELinux 安全上下文配置 亚马逊云 AWS Lightsail 安全

微服务架构深度解析与最佳实践(全篇汇总)

kimmking

微服务 最佳实践 深度解析 高可用

一文讲清楚 MySQL 事务隔离级别和实现原理,开发人员必备知识点

古时的风筝

MySQL 数据库 事务隔离级别 mysql事务 数据库事务

小程序的当下和未来可能 | GMTC.2019深圳站演讲文稿

崔红保

小程序 uni-app

聊聊:Python

谢烟客

Python 人工智能 编程

平均响应1000ms到200ms,PHP和Go那家强?

拖地先生

php 架构 性能优化 后台开发 运维

微服务架构深度解析与最佳实践 - 第四部分

kimmking

微服务 最佳实践 深度解析 高可用

2019 年

贾献华

2020 2019 总结 日历 计划

归去来兮:递归

曲镇

算法

微服务架构深度解析与最佳实践-第一部分

kimmking

微服务 最佳实践 深度解析 高可用

【译】Rust 开发者的2019

WasmEdge

程序员 rust

浅谈数据中台

数据社

大数据 数据中台 数据仓库

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