50万奖金+官方证书,深圳国际金融科技大赛正式启动,点击报名 了解详情
写点什么

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

评论

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

11 万字的字节码编程系列合集放送(ASM、Javassist、Byte-buddy、Javaagent)

小傅哥

Java asm bytebuddy 《字节码编程》

DevOps生命周期,你想知道的全都在这里了!

禅道项目管理

DevOps 测试 持续集成

OneData之OneModel

KAMI

大数据 数据中台 数据治理 OneData

Collaboration on SaaS

zhenglei

SaaS Collaboration Cisco Webex

Java如何处理异常情况

Rayjun

Java 异常

从连续两届图灵奖(2018-2019)看GPU发展史

GPU

人工智能 gpu 计算机基础 计算机图形学 计算机体系结构

少说废话,先干起来

大辉辉

学习 个人成长 自律

游戏夜读 | Scikit-learn迎来0.21版本

game1night

2020年比以往任何时候更想做成的使命感

乐少

OneData之OneService

KAMI

大数据 数据中台 数据治理 OneData

OneData之OneID

KAMI

大数据 数据中台 数据治理 OneData

一种练好英语口语的方法

董一凡

学习

EasyExcel最权威教程

知春秋

Java Excel EasyExcel

码农理财(一)

北漂码农有话说

理财

【高级进阶】写给大忙人看的JDK14新特性

知春秋

Java java 14 java 14 新特性

有问必答(2020-05-09):如何督促自己做好一件事情?

冯夷

生活

都前后端分离了,咱就别做页面跳转了!统统 JSON 交互

江南一点雨

spring Spring Boot spring security

微服务为什么要有服务发现与注册?

攀岩飞鱼

微服务

Kotlin协程实践之进程、线程、协程

陈吉米

Java kotlin 协程 Coroutine

写作对我的意义

Neco.W

总结 思考 写作 感悟

微服务涉及的技术生态有哪些?

攀岩飞鱼

分布式 微服务 方法论 软件架构

浅谈Cloud Native技术对云上产品的影响

韩超

Docker Kubernetes 云原生 IaaS PaaS

计算机中的递归对普通人有什么启示?

BitSea

算法

程序员的晚餐 | 5 月 17 日 当西红柿遇上鱼

清远

美食

sync.Map源码分析

陈思敏捷

源码 源码分析 Go 语言

数据治理与OneData 体系

KAMI

大数据 数据中台 数据治理 OneData

发布Maven包的正确姿势

廖雪峰

maven 开源

从零到部署:用 Vue 和 Express 实现迷你全栈电商应用(一)

图雀社区

node.js vue.js Vue

回“疫”录(19):都什么时候了,还在搞“填表抗疫”

小天同学

疫情 回忆录 现实纪录 纪实 形式主义

机会,是不会让你准备好的

Winann

学习 生活 知识管理 机会

Docker 镜像制作教程:针对不同语言的精简策略

硅基新手村

Docker Dockerfile

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