kafka-再均衡

再均衡（Rebalance）本质上是一种协议，规定了一个消费组中所有消费者如何达成一致来分配订
阅主题的每个分区。
比如某个消费组有20个消费组，订阅了一个具有100个分区的主题。正常情况下，Kafka平均会为每
个消费者分配5个分区。这个分配的过程就叫再均衡

• 什么时候再均衡？
  再均衡的触发条件：

1. 组成员发生变更(新消费者加入消费组组、已有消费者主动离开或崩溃了)
2. 订阅主题数发生变更。如果正则表达式进行订阅，则新建匹配正则表达式的主题触发再均衡。
3. 订阅主题的分区数发生变更

• 如何进行组内分区分配？
  三种分配策略：RangeAssignor和RoundRobinAssignor以及StickyAssignor

• 谁来执行再均衡和消费组管理？
  Kafka提供了一个角色：Group Coordinator来执行对于消费组的管理。
  Group Coordinator——每个消费组分配一个消费组协调器用于组管理和位移管理。当消费组的第
  一个消费者启动的时候，它会去和Kafka Broker确定谁是它们组的组协调器。之后该消费组内所有消费
  者和该组协调器协调通信

• 如何确定coordinator？
  两步：

1. 确定消费组位移信息写入 __consumers_offsets 的哪个分区。具体计算公式：
   __consumers_offsets partition# = Math.abs(groupId.hashCode() %
   groupMetadataTopicPartitionCount) 注意：groupMetadataTopicPartitionCount
   由 offsets.topic.num.partitions 指定，默认是50个分区。
2. 该分区leader所在的broker就是组协调器。

• Rebalance Generation
  它表示Rebalance之后主题分区到消费组中消费者映射关系的一个版本，主要是用于保护消费组，
  隔离无效偏移量提交的。如上一个版本的消费者无法提交位移到新版本的消费组中，因为映射关系变
  了，你消费的或许已经不是原来的那个分区了。每次group进行Rebalance之后，Generation号都会加
  1，表示消费组和分区的映射关系到了一个新版本，如下图所示： Generation 1时group有3个成员，随
  后成员2退出组，消费组协调器触发Rebalance，消费组进入Generation 2，之后成员4加入，再次触发
  Rebalance，消费组进入Generation 3

• 协议(protocol)
  kafka提供了5个协议来处理与消费组协调相关的问题：
  Heartbeat请求：consumer需要定期给组协调器发送心跳来表明自己还活着
  LeaveGroup请求：主动告诉组协调器我要离开消费组
  SyncGroup请求：消费组Leader把分配方案告诉组内所有成员
  JoinGroup请求：成员请求加入组
  DescribeGroup请求：显示组的所有信息，包括成员信息，协议名称，分配方案，订阅信息
  等。通常该请求是给管理员使用
  组协调器在再均衡的时候主要用到了前面4种请求

*　liveness
消费者如何向消费组协调器证明自己还活着？ 通过定时向消费组协调器发送Heartbeat请求。如果超过了设定的超时时间，那么协调器认为该消费者已经挂了。一旦协调器认为某个消费者挂了，那么它就会开启新一轮再均衡，并且在当前其他消费者的心跳响应中添加“REBALANCE_IN_PROGRESS”，告诉其他消费者：重新分配分区

＊　再均衡过程
再均衡分为2步：Join和Sync

1. Join， 加入组。所有成员都向消费组协调器发送JoinGroup请求，请求加入消费组。一旦所有
   成员都发送了JoinGroup请求，协调i器从中选择一个消费者担任Leader的角色，并把组成员信
   息以及订阅信息发给Leader。
2. Sync，Leader开始分配消费方案，即哪个消费者负责消费哪些主题的哪些分区。一旦完成分
   配，Leader会将这个方案封装进SyncGroup请求中发给消费组协调器，非Leader也会发
   SyncGroup请求，只是内容为空。消费组协调器接收到分配方案之后会把方案塞进SyncGroup
   的response中发给各个消费者

注意：在协调器收集到所有成员请求前，它会把已收到请求放入一个叫purgatory(炼狱)的地方。然
后是分发分配方案的过程，即SyncGroup请求

注意：消费组的分区分配方案在客户端执行。Kafka交给客户端可以有更好的灵活性。Kafka默认提
供三种分配策略：range和round-robin和sticky。可以通过消费者的参数：
partition.assignment.strategy 来实现自己分配策略。

＊　消费组状态机
消费组组协调器根据状态机对消费组做不同的处理：

说明：

1. Dead：组内已经没有任何成员的最终状态，组的元数据也已经被组协调器移除了。这种状态
   响应各种请求都是一个response： UNKNOWN_MEMBER_ID
2. Empty：组内无成员，但是位移信息还没有过期。这种状态只能响应JoinGroup请求
3. PreparingRebalance：组准备开启新的rebalance，等待成员加入
4. AwaitingSync：正在等待leader consumer将分配方案传给各个成员
5. Stable：再均衡完成，可以开始消费