再平衡是指分区的所属权从一个消费者转移到另一个消费者的行为，它为消费者组具备高可用性和伸缩性提供保障，使我们可以既方便又安全地删除消费者组内的消费者或往消费者组内添加消费者。

缺点：
1.再平衡发生期间，消费者组内的消费者无法读取消息
2.Rebalance很慢。如果一个消费者组里面有几百个Consumer实例，Rebalance一次要几个小时
3.在进行再平衡的时候消费者当前的状态也会丢失，offset还未来得及提交。会造成重复消费。

Rebalance发生的时机：
1.消费者组成员数量发生变化
2.订阅主题数量发生变化
3.订阅主题的分区数发生变化

消费者端发生rebalance的原因：
1.Consumer未能及时向Coordinator发送心跳，导致消费者被踢出消费者组。
2.Consumer消费时间过长，超过设置的参数时间。
3.Consumer端频繁的Full GC导致长时间停顿。

Kafka触发Rebalance机制：
消费者组成员发生了变更（新的消费者加入，消费者挂了）；
消费者无法在指定的时间内完成消息的消费
消费者组订阅的topic发生了变化
订阅的Topic的分区发生了变化

Coordinator：
每个消费者组都会有一个coordinator,Coordinator负责处理组内的消费者和位移管理，Coordinator并不负责消费者组内的partition分配。消费者通过心跳的方式告知Coordinator自己存活状态。

Rebalance流程：
1.根据消费者组的ID对保存offset主题的分区数求模，计算出将那个分区的节点作为Coordinator。
2.所有消费者或和Coordinator进行交互，请求加入当前消费者组。Coordinator会从所有消费者中随机选择一个消费者作为leader consumer。
3.leader Consumer从Coordinator获取所有的消费者信息，并将消费组订阅的partition分配结果封装为SyncGroup请求（leader consumer不会直接与组内其他消费者交互），leader Consumer将每个消费者的分区信息发送给Coordinator，Coordinator再将消费的分区信息发送给每一个消费者。

每个消费者组都有一个broker负责协调（group coordinator）,各个消费者通过发送心跳的方式向组协调者同步状态，当有消费者一定时间没有给组协调者发送心跳或者有新的消费者加入到消费者组是，机会触发消费者组的再平衡。

  1. 新加入消费者触发再平衡
    a. 新加入消费者向组协调者发送joinGroup请求，携带订阅的topic信息
    b. 组协调者收到其他消费者的心跳请求时，在响应中告诉消费者再平衡
    c. 组内原有消费者会重新发送joinGroup到组协调者
    d. 组协调者根据joinGroup请求选择出消费者leader,将topic和分区信息响应给各个消费者
    e. leader消费者将分区分配好
    f. 消费者发送SynGroup请求给协调者请求重新分配好的分区信息，其中消费者leader会携带分配好的分区信息。
    g. 组协调者将分区信息响应给消费者，每个消费者就知道自己负责的消费分区。
  2. 消费者主动离开导致再平衡
    a. 消费者发送leaveGroup请求给组协调者
    b. 组消费者接收组内其他消费者的心跳请求时，在响应中告诉消费者需要再平衡
    c. 消费者重新发送joinGroup请求到组协调者
    d. 组协调者根据发送joinGroup请求选择消费者leader，将topic分区信息响应给各个消费者
    e. 消费者leader将消费者分区分配好
    f. 消费者发送SyncGroup请求给组协调者请求重新分配好的分区信息，其中消费者leader会携带将分配好的分区信息
    g. 组协调者将各个消费者负责的分区信息响应给消费者，完成再平衡。
  3. 消费者失去心跳导致再平衡
    a. 消费者一定时间内没有发送心跳信息给组协调者
    b. 组协调者收到组内其他消费者的心跳请求时，在响应中告诉消费者再平衡
    c. 消费者重新发送joinGroup请求到组协调者
    d. 组协调者选择出消费者leader，将topic和分区信息响应给每个消费者
    e. 消费者leader将分区分配好
    f. 消费者发送SyncGroup请求给组协调者请求新分配好的分区信息，消费者leader会携带分配好的分区信息
    g. 组协调者将给个消费者负责分区信息响应给消费者，在平衡完成。