部分内容摘自：Kafka的Rebalance机制可能造成的影响及解决方案_星空的风fly-CSDN博客_kafka rebalance引起的问题

kafka的rebalance机制

kafka集群模式下，一个topic有多个partition，对于消费端，可以有多个consumer同时消费这些partition。为了保证大体上partition和consumer的均衡性，提升topic的并发消费能力，所以会有Rebalance。Rebalance 本质上是一种协议，规定了一个 Consumer Group 下的所有 consumer 如何达成一致，来分配订阅 Topic 的每个分区。

Kafka的Consumer Rebalance方案是基于Zookeeper的Watcher来实现的。consumer启动的时候，在zk下都维护一个”/consumers/[group_name]/ids”路径，在此路径下，使用临时节点记录属于此cg的消费者的id，该id信息由对应的consumer在启动时创建。每个consumer都会在此路径下建立一个watcher，当有节点发生变化时，就会触发watcher，然后触发Rebalance过程。

rebalance可能发生的时机

条件1：有新的consumer加入

条件2：旧的consumer挂了

条件3：coordinator挂了，集群选举出新的coordinator（0.10 特有的）

条件4：topic的partition新加

条件5：consumer调用unsubscrible()，取消topic的订阅

即：

1、消费组成员的加入或离开（这个是我们最常遇到）

2、分区个数的增加

3、对Topic的订阅发生变化

Rebalance的过程

第一步：所有消费成员都向Coordinator发送请求，请求入Consumer Group。一旦所有成员都发送了请求，Coordinator会从中选择一个Consumer担任Leader的角色，并把组成员信息以及订阅信息发给Leader。
第二步：Leader开始分配消费方案，指明具体哪个Consumer负责消费哪些Topic的哪些Partition。一旦完成分配，leader会将这个方案发给Coordinator。Coordinator接收到分配方案之后会把方案发给各个Consumer，这样组内的所有成员就都知道自己应该消费哪些分区了。

rebalance的影响

Rebalance对我们数据的影响主要有以下几点：

1、可能重复消费: Consumer被踢出消费组，可能还没有提交offset，Rebalance时会Partition重新分配其它Consumer,会造成重复消费，虽有幂等操作但耗费消费资源，亦增加集群压力

2、集群不稳定：Rebalance扩散到整个ConsumerGroup的所有消费者，因为一个消费者的退出，导致整个Group进行了Rebalance，并在一个比较慢的时间内达到稳定状态，影响面较大

3、影响消费速度：频繁的Rebalance反而降低了消息的消费速度，大部分时间都在重复消费和Rebalance

避免rebalance措施

1、业务需要不可避免
（1）针对分区个数的增加， 一般不会常有，是需要增加的时候都是业务及数据需求，不可避免

（2）对Topic的订阅增加或取消亦不可避免

2、合理设置消费者参数
 下边是我们遇到的，要格外关注及重视

（1）未能及时发送心跳而Rebalance

session.timeout.ms  一次session的连接超时时间

heartbeat.interval.ms  心跳时间，一般为超时时间的1/3，Consumer在被判定为死亡之前，能够发送至少 3 轮的心跳请求

（2）Consumer消费超时而Rebalance

max.poll.interval.ms  每隔多长时间去拉取消息。合理设置预期值，尽量但间隔时间消费者处理完业务逻辑，否则就会被coordinator判定为死亡，踢出Consumer Group，进行Rebalance

max.poll.records  一次从拉取出来的数据条数。根据消费业务处理耗费时长合理设置，如果每次max.poll.interval.ms 设置的时间较短，可以max.poll.records设置小点儿，少拉取些，这样不会超时。

总之，尽可能在max.poll.interval.ms时间间隔内处理完max.poll.records条消息，让Coordinator认为消费Consumer还活着