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

精选留言(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

  

  