消费者组重平衡如何避免吗？Rebalance_mq 上线rebalance规避

1.了解“协调者” Coordinator

在Kafka中"协调者"，专门为消费组服务，负责为组执行Rebalance以及提供位移管理和组员管理等。

2.kafka确定消费组的协调者所在Broker的算法有2个步骤

步骤1

 	确定位移主题的那个分区来保存该Group组数据：通过分区策略（比如 轮询、随机）但是这里用的是HashPartitioner哈希
 分区，partitionId=Math.abs(groupId.hashCode() % offsetsTopicPartitionCount)。通过hash值处于分区数进行。
1
2

步骤2

找出该分区的Leader副本所在Broker，该 Broker 即为对应的 Coordinator。
1

3.Rebalance的缺点

缺点也很简单，就是类似JVMGC 垃圾回收会停下手里的一切事去进行Rebalance，并且由于我们常用kafka的版本它进行rebalance会出现以下问题：

3.1 理想情况下

当消费者3倍踢出消费组的时候，协调者应该以最小的消耗去将多余消息分配给其余消费者，但是实际情况下不是这样。

3.2 真实情况

将消费者3去掉后，是将所有的消息重组放入其余消费者中。

4.如何避免Rebalance 重平衡

我们站在消费端的角度来看（组成员数量发生变化）

4.1 第一类非必要 Rebalance ，未能及时发送心跳，导致 Consumer 被“踢出”Group而引发的

解决方法：

#单位ms 设置心跳传送时间几毫秒一次 ，默认是3000ms
heartbeat.interval.ms

#单位ms 多长时间没有心跳，后连接超时，默认10000ms
session.timeout.ms
1
2
3
4
5

比如
设置 session.timeout.ms = 6000。
设置 heartbeat.interval.ms = 2000。
这样就正常情况下最起码会发3次心跳给broker

4.2 第二类非必要 Rebalance 是 Consumer 消费时间过长导致的

这个参数最好设置大一些，比如你逻辑处理最长要10分钟，那你需要设置的比这个大为你的业务处理逻辑留下充足的时间，从而防止超时导致Rebalance。

#使用消费者组管理时调用 poll() 之间的最大延迟。这为消费者在获取更多记录之前可以空闲的时间量设置了上限。
#如果在此超时到期之前未调用 poll()，则认为消费者失败，组将重新平衡，以便将分区重新分配给另一个成员。
# 默认3000ms
max.poll.interval.ms
1
2
3
4

4.3 如果还有问题就考虑GC问题

由于频繁发生Full GC 而导致非预期的Rebalance