Kafka消费者重平衡

这篇具有很好参考价值的文章主要介绍了Kafka消费者重平衡。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

「(重平衡)Rebalance本质上是一种协议,规定了一个Consumer Group下的所有Consumer如何达成一致,来分配订阅Topic的每个分区」

比如某个Group下有20个Consumer实例,它订阅了一个具有100个分区的Topic。

正常情况下,Kafka平均会为每个Consumer分配5个分区。这个分配的过程就叫Rebalance。

「Rebalance的触发条件有3个。」

  1. 组成员数发生变更。比如有新的Consumer实例加入组或者离开组,或是有Consumer实例崩溃被踢出组。
  2. 订阅主题数发生变更。Consumer Group可以使用正则表达式的方式订阅主题,比如consumer.subscribe(Pattern.compile(“t.*c”))就表明该Group订阅所有以字母t开头、字母c结尾的主题,在Consumer Group的运行过程中,你新创建了一个满足这样条件的主题,那么该Group就会发生Rebalance。
  3. 订阅主题的分区数发生变更。Kafka当前只能允许增加一个主题的分区数,当分区数增加时,就会触发订阅该主题的所有Group开启Rebalance。

Rebalance发生时,Group下所有的Consumer实例都会协调在一起共同参与。

「分配策略」

当前Kafka默认提供了3种分配策略,每种策略都有一定的优势和劣势,社区会不断地完善这些策略,保证提供最公平的分配策略,即每个Consumer实例都能够得到较为平均的分区数。

比如一个Group内有10个Consumer实例,要消费100个分区,理想的分配策略自然是每个实例平均得到10个分区。

这就叫公平的分配策略。

举个简单的例子来说明一下Consumer Group发生Rebalance的过程。

假设目前某个Consumer Group下有两个Consumer,比如A和B,当第三个成员C加入时,Kafka会触发Rebalance,并根据默认的分配策略重新为A、B和C分配分区

Rebalance之后的分配依然是公平的,即每个Consumer实例都获得了2个分区的消费权。

在Rebalance过程中,所有Consumer实例都会停止消费,等待Rebalance完成,这是Rebalance为人诟病的一个方面。

目前Rebalance的设计是所有Consumer实例共同参与,全部重新分配所有分区。

「Coordinator会在什么情况下认为某个Consumer实例已挂从而要退组呢?」

当Consumer Group完成Rebalance之后,每个Consumer实例都会定期地向Coordinator发送心跳请求,表明它还存活着。

如果某个Consumer实例不能及时地发送这些心跳请求,Coordinator就会认为该Consumer已经死了,从而将其从Group中移除,然后开启新一轮Rebalance。

Consumer端有个参数,叫session.timeout.ms(默认10s)

该参数的默认值是10秒,即如果Coordinator在10秒之内没有收到Group下某Consumer实例的心跳,它就会认为这个Consumer实例已经挂了。

除了这个参数,Consumer还提供了一个允许你控制发送心跳请求频率的参数,就是heartbeat.interval.ms(默认3s)

这个值设置得越小,Consumer实例发送心跳请求的频率就越高。

频繁地发送心跳请求会额外消耗带宽资源,但好处是能够更加快速地知晓当前是否开启Rebalance,因为,目前Coordinator通知各个Consumer实例开启Rebalance的方法,就是将REBALANCE_NEEDED标志封装进心跳请求的响应体中。

除了以上两个参数,Consumer端还有一个参数,用于控制Consumer实际消费能力对Rebalance的影响,即max.poll.interval.ms(默认5min)参数。

它限定了Consumer端应用程序两次调用poll方法的最大时间间隔。

它的默认值是5分钟,表示你的Consumer程序如果在5分钟之内无法消费完poll方法返回的消息,那么Consumer会主动发起离开组的请求,Coordinator也会开启新一轮Rebalance。

「可避免Rebalance的配置」

第一类Rebalance是因为未能及时发送心跳,导致Consumer被踢出Group而引发的

  • 设置session.timeout.ms = 6s。
  • 设置heartbeat.interval.ms = 2s。
  • 要保证Consumer实例在被判定为dead之前,能够发送至少3轮的心跳请求,即session.timeout.ms >= 3 * heartbeat.interval.ms

session.timeout.ms设置成6s主要是为了让Coordinator能够更快地定位已经挂掉的Consumer。

「第二类Rebalance是Consumer消费时间过长导致的」

你要为你的业务处理逻辑留下充足的时间,这样Consumer就不会因为处理这些消息的时间太长而引发Rebalance了。

生产kafka消费者频繁rebalance,Kafka,kafka,分布式

参考案例:

一次 kafka 消息堆积问题排查如题https://mp.weixin.qq.com/s/VgXukc39tFBXrR0yKg7vdA

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

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 之间的平衡点,避免出现消费者被频繁踢出消费组导致重平衡。

 文章来源地址https://www.toymoban.com/news/detail-852615.html

到了这里,关于Kafka消费者重平衡的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 保障效率与可用,分析Kafka的消费者组与Rebalance机制

    上手第一关,手把手教你安装kafka与可视化工具kafka-eagle Kafka是什么,以及如何使用SpringBoot对接Kafka 架构必备能力——kafka的选型对比及应用场景 Kafka存取原理与实现分析,打破面试难关 防止消息丢失与消息重复——Kafka可靠性分析及优化实践 我们上一期从可靠性分析了消息

    2024年02月06日
    浏览(46)
  • Kafka消费者重平衡

    「(重平衡)Rebalance本质上是一种协议,规定了一个Consumer Group下的所有Consumer如何达成一致,来分配订阅Topic的每个分区」 。 比如某个Group下有20个Consumer实例,它订阅了一个具有100个分区的Topic。 正常情况下,Kafka平均会为每个Consumer分配5个分区。这个分配的过程就叫Rebal

    2024年04月15日
    浏览(27)
  • Kafka消费者组重平衡(一)

    重平衡,也就是Rebalance, 就是让一个 Consumer Group 下所有的 Consumer 实例就如何消费订阅主题的所有分区达成共识的过程。在 Rebalance 过程中,所有 Consumer 实例共同参与,在协调者组件的帮助下,完成订阅主题分区的分配。 Kafka消费者重平衡时一个很重要的概念,本文主要从什么

    2024年02月08日
    浏览(23)
  • Kafka学习---4、消费者(分区消费、分区平衡策略、offset、漏消费和重复消费)

    1.1 Kafka消费方式 1、pull(拉)模式:consumer采用从broker中主动拉取数据。 2、push(推)模式:Kafka没有采用这种方式。因为broker决定消息发生速率,很难适应所有消费者的消费速率。例如推送的速度是50M/s,Consumer1、Consumer2就来不及处理消息。 pull模式不足之处是如果Kafka没有数

    2024年02月16日
    浏览(46)
  • Kafka系列之:Kafka生产者和消费者

    batch.size:只有数据积累到batch.size之后,sender才会发送数据,默认16K。 linger.ms:如果数据迟迟未达到batch.size,sender等待linger.ms设置的时间到了之后就会发送数据。单位ms,默认值是0ms,表示没有延迟。 0:生产者发送过来的数据,不需要等数据罗盘应答。 1:生产者发送过来的

    2023年04月09日
    浏览(46)
  • kafka生产者消费者练习

    需求:写一个生产者,不断的去生产用户行为数据,写入到kafka的一个topic中 生产的数据格式: 造数据 {“guid”:1,“eventId”:“pageview”,“timestamp”:1637868346789} isNew = 1 {“guid”:1,“eventId”:“addcard”,“timestamp”:1637868347625} isNew = 0 {“guid”:2,“eventId”:“collect”,“timestamp”

    2024年02月08日
    浏览(46)
  • 【消息队列】细说Kafka消费者的分区分配和重平衡

    我们直到在性能设计中异步模式,一般要么是采用pull,要么采用push。而两种方式各有优缺点。 pull :说白了就是通过消费端进行主动拉去数据,会根据自身系统处理能力去获取消息,上有Broker系统无需关注消费端的消费能力。kafka采用pull模式 push : Broker主动推送消息到消费端

    2024年02月12日
    浏览(37)
  • Kafka 消费者“group_name”组正在永远重新平衡

    前些天发现了一个巨牛的人工智能学习网站,通俗易懂,风趣幽默,忍不住分享一下给大家。点击跳转到网站。 卡夫卡:2.11-1.0.1。 主题:并发度为 5 且分区为 5 。 当应用程序重新启动并且在分区分配之前在主题上发布消息时,主题的 5 个消费者找到组协调器并向组协调器发

    2024年02月11日
    浏览(37)
  • Kafka3.0.0版本——消费者(分区的分配以及再平衡)

    1.1、消费者分区及消费者组的概述 一个consumer group中有多个consumer组成,一个 topic有多个partition组成。 1.2、如何确定哪个consumer来消费哪个partition的数据 Kafka有四种主流的分区分配策略: Range、RoundRobin、Sticky、CooperativeSticky。 可以通过配置参数 partition.assignment.strategy ,修改分

    2024年02月07日
    浏览(53)
  • kafka消费者详解,根据实际生产解决问题

    1.首先kafka每创建一个消费者就是一个消费者组,必须指定groupip 2.两个消费者组之间不相互影响,消费同一个主题的同一个分区,两个消费者组不相互影响,各自记录自己的offset 3.在开发中如果没有指定每个消费者去消费特定的分区,那么kafka默认是按照roundRobin轮询的方式分

    2024年02月10日
    浏览(49)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包