一次 kafka 消息堆积问题排查

栏目: IT技术 · 发布时间: 4年前

内容简介:收到某业务组的小伙伴发来的反馈,具体问题如下:项目中某 kafka 消息组消费特别慢,有时候在 kafka-manager 控制台看到有些消费者已被踢出消费组。从服务端日志看到如下信息:

收到某业务组的小伙伴发来的反馈,具体问题如下:

项目中某 kafka 消息组消费特别慢,有时候在 kafka-manager 控制台看到有些消费者已被踢出消费组。

从服务端日志看到如下信息:

一次 kafka 消息堆积问题排查

该消费组在短时间内重平衡了 600 多次。

从 cat 查看得知,每条消息处理都会有 4 次数据库的交互,经过一番沟通之后,发现每条消息的处理耗时大概率保持在 200ms 以上。

Kafka 发生重平衡的有以下几种情况:

  1. 消费组成员发生变更,有新消费者加入或者离开,或者有消费者崩溃;
  2. 消费组订阅的主题数量发生变更;
  3. 消费组订阅的分区数发生变更。

在第 2、3 点都没有发生的情况下,那么就是由消费组成员发生了变化导致 Kafka 发生重平衡。

在查看 kafka 客户端日志,发现有很多如下日志:

一次 kafka 消息堆积问题排查

日志的描述得知,消费者被被剔除的原因是调用 poll() 方法消费耗时太久了,其中有提到 max.poll.interval.ms 和 max.poll.records 两个参数,而且还会导致提交

max.poll.interval.ms 表示消费者处理消息逻辑的最大时间,对于某些业务来说,处理消息可能需要很长时间,比如需要 1 分钟,那么该参数就需要设置成大于 1分钟的值,否则就会被 Coordinator 剔除消息组然后重平衡, 默认值为 300000;

max.poll.records 表示每次默认拉取消息条数,默认值为 500。

我们来计算一下:

200 * 500 = 100000 < max.poll.interval.ms =300000,

前面我也讲了,当每条消息处理时间大概率会超过 200ms。

结论:

本次出现的问题是由于客户端的消息消费逻辑耗时太长,如果生产端出现消息发送增多,消费端每次都拉取了 500 条消息进行消费,这时就很容易导致消费时间过长,如果超过了 max.poll.interval.ms 所设置的时间,就会被消费组所在的 coordinator 剔除掉,从而导致重平衡,Kafka 重平衡过程中是不能消费的,会导致消费组处于类似 stop the world 的状态下,重平衡过程中也不能提交位移,这会导致消息重复消费从而使得消费组的消费速度下降,导致消息堆积。

解决办法:

根据业务逻辑调整 max.poll.records 与 max.poll.interval.ms 之间的平衡点,避免出现消费者被频繁踢出消费组导致重平衡。


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

程序员成长的烦恼

程序员成长的烦恼

吴亮、周金桥、李春雷、周礼 / 华中科技大学出版社 / 2011-4 / 28.00元

还在犹豫该不该转行学编程?还在编程的道路上摸爬滚打?在追寻梦想的道路上你并不孤单,《程序员成长的烦恼》中的四位“草根”程序员也曾有过类似的困惑。看看油田焊接技术员出身的周金桥是如何成功转行当上程序员的,做过钳工、当过外贸跟单员的李春雷是如何自学编程的,打小在486计算机上学习编程的吴亮是如何一路坚持下来的,工作中屡屡受挫、频繁跳槽的周礼是如何找到出路的。 《程序员成长的烦恼》记录了他们一步一......一起来看看 《程序员成长的烦恼》 这本书的介绍吧!

HTML 编码/解码
HTML 编码/解码

HTML 编码/解码

URL 编码/解码
URL 编码/解码

URL 编码/解码

html转js在线工具
html转js在线工具

html转js在线工具