Kafka核心技术与实战
胡夕
人人贷计算平台部总监,Apache Kafka Contributor
立即订阅
8408 人已学习
课程目录
已完结 46 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么要学习Kafka?
免费
Kafka入门 (5讲)
01 | 消息引擎系统ABC
02 | 一篇文章带你快速搞定Kafka术语
03 | Kafka只是消息引擎系统吗?
04 | 我应该选择哪种Kafka?
05 | 聊聊Kafka的版本号
Kafka的基本使用 (3讲)
06 | Kafka线上集群部署方案怎么做?
07 | 最最最重要的集群参数配置(上)
08 | 最最最重要的集群参数配置(下)
客户端实践及原理剖析 (14讲)
09 | 生产者消息分区机制原理剖析
10 | 生产者压缩算法面面观
11 | 无消息丢失配置怎么实现?
12 | 客户端都有哪些不常见但是很高级的功能?
13 | Java生产者是如何管理TCP连接的?
14 | 幂等生产者和事务生产者是一回事吗?
15 | 消费者组到底是什么?
16 | 揭开神秘的“位移主题”面纱
17 | 消费者组重平衡能避免吗?
18 | Kafka中位移提交那些事儿
19 | CommitFailedException异常怎么处理?
20 | 多线程开发消费者实例
21 | Java 消费者是如何管理TCP连接的?
22 | 消费者组消费进度监控都怎么实现?
深入Kafka内核 (5讲)
23 | Kafka副本机制详解
24 | 请求是怎么被处理的?
25 | 消费者组重平衡全流程解析
26 | 你一定不能错过的Kafka控制器
27 | 关于高水位和Leader Epoch的讨论
管理与监控 (12讲)
28 | 主题管理知多少?
29 | Kafka动态配置了解下?
30 | 怎么重设消费者组位移?
31 | 常见工具脚本大汇总
32 | KafkaAdminClient:Kafka的运维利器
33 | Kafka认证机制用哪家?
34 | 云环境下的授权该怎么做?
35 | 跨集群备份解决方案MirrorMaker
36 | 你应该怎么监控Kafka?
37 | 主流的Kafka监控框架
38 | 调优Kafka,你做到了吗?
39 | 从0搭建基于Kafka的企业级实时日志流处理平台
高级Kafka应用之流处理 (3讲)
40 | Kafka Streams与其他流处理平台的差异在哪里?
41 | Kafka Streams DSL开发实例
42 | Kafka Streams在金融领域的应用
结束语 (1讲)
结束语 | 以梦为马,莫负韶华!
特别放送 (2讲)
加餐 | 搭建开发环境、阅读源码方法、经典学习资料大揭秘
用户故事 | 黄云:行百里者半九十
Kafka核心技术与实战
登录|注册

17 | 消费者组重平衡能避免吗?

胡夕 2019-07-11
你好,我是胡夕。今天我要和你分享的内容是:消费者组重平衡能避免吗?
其实在专栏第 15 期中,我们讲过重平衡,也就是 Rebalance,现在先来回顾一下这个概念的原理和用途。Rebalance 就是让一个 Consumer Group 下所有的 Consumer 实例就如何消费订阅主题的所有分区达成共识的过程。在 Rebalance 过程中,所有 Consumer 实例共同参与,在协调者组件的帮助下,完成订阅主题分区的分配。但是,在整个过程中,所有实例都不能消费任何消息,因此它对 Consumer 的 TPS 影响很大。
你可能会对这里提到的“协调者”有些陌生,我来简单介绍下。所谓协调者,在 Kafka 中对应的术语是 Coordinator,它专门为 Consumer Group 服务,负责为 Group 执行 Rebalance 以及提供位移管理和组成员管理等。
具体来讲,Consumer 端应用程序在提交位移时,其实是向 Coordinator 所在的 Broker 提交位移。同样地,当 Consumer 应用启动时,也是向 Coordinator 所在的 Broker 发送各种请求,然后由 Coordinator 负责执行消费者组的注册、成员管理记录等元数据管理操作。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Kafka核心技术与实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(57)

  • Icedmaze
    在 Rebalance 过程中,所有 Consumer 实例都会停止消费,等待Rebalance的完成。
    这里想问的是,如果我有一个长耗时的业务逻辑需要处理,并且offset还未提交,这时候系统发生了Rebalance的话,是等待所有消费端当前消息都处理完成,再进行停止消费,并进行重新分配分区,还是说强制停止消费。
    如果强制停止消费的话,那么那些已经处理完成一半的数据并offset未提交的数据,势必会导致Rebalance后重新进行消费,导致数据产生重复消费。

    作者回复: 你所谓的处理是指业务上的处理逻辑。对于Kafka而言,从poll方法返回消息的那一刻开始这条消息已经算是“消费”完成了。

    2019-07-11
    5
    15
  • 墨渊战神01
    Consumer 消费时间过长为啥会导致rebalance?是不能及时发心跳 导致coordinator认为该consumer挂了吗?

    作者回复: consumer主动关闭会主动向Coordinator发送LeaveGroup请求,从而让Coordinator第一时间开启rebalance

    2019-07-11
    5
  • 千屿
    我遇到一个很奇怪的问题,我消费者单线程使用订阅模式消费主题,主题下有三个分区,但是每次启动消费者,只能消费到一个分区的数据,在启动的日志里已经显示了该group已经分配到了三个分区,可是只会poll一个分区的数据。当我用多线程启动三个消费者实例是正常的,启动两个实例只能消费到两个分区数据,求各位大神指点下,谢谢了!

    作者回复: 是否是因为某个分区的数据量太多,造成了其他分区的“假饿死”?

    2019-07-11
    1
    4
  • 丘壑
    根据公式计算记过:partitionId=Math.abs(groupId.hashCode() % offsetsTopicPartitionCount)只可能是一个分区值,该分区值对于的leader副本的broker也只可能是集群中的一台,那么一个group进行位移提交的时候,只能是与集群中的一台broker进行交互了?这样是不是就会有性能瓶颈啊,没有充分利用集群中的broker啊,

    作者回复: 不同的group id会被哈希到不同的分区上,从而不同的broker能充当不同group的Coordinator

    2019-07-11
    4
  • Liam
    问个小白问题,如何排查得知broker rebalance 过多,通过broker日志吗?什么日志呢

    作者回复: 去找Coordinator所在的broker日志,如果经常发生rebalance,会有类似于"(Re)join group" 之类的日志

    2019-07-11
    3
    3
  • 诗泽
    如果同一个group 的不同consumer 设置的session.timeout.ms 的不一样怎么办?协调者以最后一个consumer 为准吗?

    作者回复: 取最大的

    2019-07-11
    1
    2
  • 李奕慧
    “每个 Consumer 实例都会定期地向 Coordinator 发送心跳请求,表明它还存活着。”这个是后台自动触发的还是每次主动poll消息触发的啊?

    作者回复: 0.10.1之前是在调用poll方法时发送的,0.10.1之后consumer使用单独的心跳线程来发送

    2019-07-11
    1
    2
  • 巧克力黑
    Spark Streaming消费Kafka的日志中,会有很多Marking the coordinator xxx:9092 (id: 2147483645 rack: null) dead for group xxx_etl日志。请教老师,这是什么原因引起的,对消费者任务有影响么?

    作者回复: 很多种原因而且如果我没记错的话,这是个INFO日志,你最好调整一下日志级别,看看能否打出真实的原因。从这个错误本身来看,这个异常就是表示consumer无法连接上Coordinator或Coordinator本身不可用了,可能的原因确实太多了

    2019-09-11
    1
  • godtrue
    1:rebalance是啥?
    Rebalance 就是让一个 Consumer Group 下所有的 Consumer 实例就如何消费订阅主题的所有分区达成共识的过程。在 Rebalance 过程中,所有 Consumer 实例共同参与,在协调者组件的帮助下,完成订阅主题分区的分配。但是,在整个过程中,所有实例都不能消费任何消息,因此它对 Consumer 的 TPS 影响很大。

    2:rebalance有啥弊端?
    2-1:Rebalance 影响 Consumer 端 TPS。这个之前也反复提到了,这里就不再具体讲了。总之就是,在 Rebalance 期间,Consumer 会停下手头的事情,什么也干不了。
    2-2:Rebalance 很慢。如果你的 Group 下成员很多,就一定会有这样的痛点。还记得我曾经举过的那个国外用户的例子吧?他的 Group 下有几百个 Consumer 实例,Rebalance 一次要几个小时。在那种场景下,Consumer Group 的 Rebalance 已经完全失控了。
    2-3:Rebalance 效率不高。当前 Kafka 的设计机制决定了每次 Rebalance 时,Group 下的所有成员都要参与进来,而且通常不会考虑局部性原理,但局部性原理对提升系统性能是特别重要的。

    3:rebalance啥时候发生?
    3-1:组成员数量发生变化
    3-2:订阅主题数量发生变化
    3-3:订阅主题的分区数发生变化

    4:rebalance的算法是啥?
    4-1:全员参与的分区分配策略——目前的算法,也是rebalance慢的根源
    4-2:粘性的分区分配策略——尽量不动没有问题的分区,重新分配有问题的分区

    5:rebalance能否避免?
    不能完全避免
    只能最大限度的设置更为合理的参数,来避免非必要的rebalance,比如这些参数
    5-1:session.timeout.ms
    5-2:heartbeat.interval.ms
    5-3:max.poll.interval.ms
    5-4:GC参数

    疑问?
    rebalance的算法为啥最早是全员参与的方式?kafka起源于大数据,估计分区数比较多的情况应该早已经猜到。
    另外,粘性的分区分配策略具体是怎么实现的,听起来不难,但是写kafka的人都实现的不佳,想必不是那么容易的,老师觉得实现的痛点在哪里?
    2019-08-16
    1
  • 小头针
    胡老师,请问后面会讲到controller么?因为它也涉及到选举,请问controller的选举机制又是怎样的呢?

    作者回复: 会讲到controller,如果有未涉及的部分, 也可以直接在这里留言提问 :)

    2019-07-15
    1
  • 小白
    一个consumer group下的多个consumer部署在k8s上,每次发布新版本滚动升级的过程,就是不断发生Rebalance的过程好像没有太好的解决办法。
    2019-07-14
    1
  • 花开成海
    请问,内部topic可以增加分区数量吗?有实践过吗?有一个很大集群,内部topic某个分区的副备偶发的被剔除isr然后再加入,观察发现这个分区的写入较大,所以希望增加分区数量。

    作者回复: 别增加。目前源代码中内部topic的分区被hard code成50了,如果后面修改会造成各种问题。已经有对应的bug来解决此事了,但代码还没有merge

    2019-07-12
    1
  • Icedmaze
    那可否认为,之前poll的数据还是会被继续进行业务逻辑处理,若在rebalance停止消费期间offset并未进行提交,可能会造成该partition里面的同一批消息被重新分配给其他消费实例,造成重复消费问题。

    作者回复: 是的

    2019-07-12
    1
  • lmtoo
    这个Rebalance是针对ConsumerGroup消费的某一个主题的,还是针对所有消费主题的?如果给消费者组增加了一个新的topic,会对该ConsumerGroup在其他已经消费的主题再平衡吗?

    作者回复: 针对整个group的。如果消费者组订阅信息发生变化也是会发生rebalance的。

    2019-07-11
    2
    1
  • ikimiy
    0.9版本里面好像没有最长消费时间参数max.poll.interval.ms,在0.9版本中如何控制消费时长
    关于GC的设置,老师后续会有讲到吗?应该如何设置是最佳实践

    作者回复: 0.9的确没有这个参数。你依然只能设置session.timeout.ms来规避

    2019-07-11
    1
  • 美美
    为啥rebalance很慢没有解释
    2019-11-25
  • James
    请问一下
    brokder挂了,不会导致订阅主题的分区数发生变化吗,然后重平衡

    作者回复: broker挂了,分区数不会变啊

    2019-11-13
  • James
    今天出现Rebalance,但是还是不知道是什么原因.
    不知道是gc,还是因为Rebalance导致gc..还是参数的设置不合理.(有数据处理后插入redis),好像也有出现broker一个节点挂了. 问题真多都不知道是什么原因.慢慢排查吧(累死了)
    2019-11-13
  • 注定非凡
    1 什么是重平衡
    A :让一个Consumer Group下所有的consumer实例就如何消费订阅主题的所有分区达成共识的过程。
    B :在重平衡过程中,所有Consumer实例共同参与,在协调者组件的帮助下,完成订阅分区的分配。
    C :整个过程中,所有实例都不能消费任何消息,因此对Consumer的TPS影响很大

    2 为什要避免重平衡
    A :Rebalance影响Consumer端的TPS,因为重平衡过程中消费者不能消费消息
    B :Rebalance很慢,如果有数百个消费者实例,整个过程耗时可能达到几个小时
    C :Rebalance效率低,这个过程是全员参与,通常不考虑局部性原理,但局部性原理对系统性能提升特别重要。
    D :真实的业务场景中,很多Rebalance都是计划外或是不必要的。

    3 何时会触发重平衡
    A :组成员数量发生变化
    B :订阅主题数量发生变化
    C :订阅主题分区数发生变化。

    4, 要避免哪些重平衡
    最常见的是消费者数发生变化触发的重平衡,其他的重平衡是不可避免的,但消费者数量变化是可避免的

    A :Consumer实例增加
    当启动一个配置相同的group.id值的consumer程序时,就是向这个组中增加一个消费者实例,这中秋情况一般是我们为了提升消费者端的TPS,是计划内的,所以也不用避免。

    B :Consumer实例减少
    (1)按计划的减少消费者实例,同样不用避免
    (2)计划外的减少触发的重平衡才是我们要关注的。

    5 如何避免重平衡
    在某些情况下,Consumer实例会被Coordinateor错误地认为“已停止”,进而被踢出Group。这种情况导致的重平衡是需要避免的。

    A :Consumer实例不能及时的发送心跳请求
    当消费者组完成重平衡后,每个Consumer实例都会定期地向Coordinator发送心跳请求,如这个心跳请求没有被及时发送,Coordinator就会认为该Consumer已经掉线,将其从组中移除,并开启新一轮重平衡。

    解决:Consumer端设置:
    》Session.timeout.ms:默认为10秒,表示10秒内Coordinator没有收到Group下某个Consumer实例的心跳,就认为实例下线。这个可以适当的增大
    》heartbeat.interval.ms:控制发送心跳请求的频率,频繁的发送心跳请求会额外消耗带库资源。
    》max.poll.interval.ms:限定Consumer端应用程序两次调用poll方法的最大时间间隔。默认值是5分钟,表示如果Consumer程序在5分钟之内无法消费完poll方法返回的消息,那么consumer会主动的发起“离开组”的请求,

    建议:session.timeout.ms=6s
    Heartbeat.interval.ms=2s
    保证Consumer实例在判定为“dead”之前,能够发送至少3轮的心跳请求,即session.timeout.ms >=3 * heartbeat.interval.ms。

    B :Consumer消费时间过长
    消费者端处理了一个很重的消费逻辑,耗时较长,导致Consumer端应用程序两次调用poll方法的时间超出设置的最大时间间隔。

    解决:
                        1,将max.poll.interval.ms参数设置较大一些
                        2,优化消费者端业务逻辑,压缩消费耗时

    C :GC影响
    Consumer端的GC表现也会导致频繁的重平衡,频繁的Ful GC会导致长时间的断顿。
    解决:
    JVM调优。
    2019-11-04
  • rhwayfun
    觉得很有必要实现粘性分区分配(局部性原理),我觉得实现起来应该不难,为啥一直不推出呢

    作者回复: 新版本已经推出来了

    2019-11-01
收起评论
57
返回
顶部