Kafka消费者Relance机制和分区机制

kafka消费者Relance

rebalance就是说如果消费组里的消费者数量有变化或消费的分区数有变化，
kafka会重新分配消费者消费分区的关系。比如consumer group中某个消费者挂了，此时会自动把分配给他的分区交给其他的消费者，如果他又重启了，那么又会把一些分区重新交还给他。

注意：rebalance只针对subscribe这种不指定分区消费的情况，如果通过assign这种消费方式指定了分区，kafka不会进行rebanlance。
如下情况可能会触发消费者rebalance

1. 消费组里的consumer增加或减少了
2. 动态给topic增加了分区
3. 消费组订阅了更多的topic

rebalance过程中，消费者无法从kafka消费消息，这对kafka的TPS会有影响，如果kafka集群内节点较多，比如数百个，那重平衡可能会耗时极多，所以应尽量避免在系统高峰期的重平衡发生

消费者Rebalance分区分配策略

主要有三种rebalance的策略：range、round-robin、sticky。
Kafka 提供了消费者客户端参数partition.assignment.strategy 来设置消费者与订阅主题之间的分区分配策略。默认情况为range分配策略。

.假设一个主题有10个分区(0-9)，现在有三个consumer消费：range策略就是按照分区序号排序，假设 n＝分区数／消费者数量 = 3， m＝分区数%消费者数量 = 1，那么前 m 个消费者每个分配 n+1 个分区，后面的（消费者数量－m ）个消费者每个分配 n 个分区。比如分区0_{3给一个consumer，分区4}6给一个consumer，分区7~9给一个consumer。

round-robin策略就是轮询分配，比如分区0、3、6、9给一个consumer，分区1、4、7给一个consumer，分区2、5、8给一个consumer

sticky策略初始时分配策略与round-robin类似，但是在rebalance的时候，需要保证如下两个原则。
1）分区的分配要尽可能均匀 。
2）分区的分配尽可能与上次分配的保持相同。

当两者发生冲突时，第一个目标优先于第二个目标 。这样可以最大程度维持原来的分区分配的策略。

比如对于第一种range情况的分配，如果第三个consumer挂了，那么重新用sticky策略分配的结果如下：
consumer1除了原有的0~3，会再分配一个7
consumer2除了原有的4~6，会再分配8和9

Rebalance

消费者组的几种状态：

协调者在管理消费者组成员的时候，会对消费者组标定状态。在协调者的视角，消费者组一共有 5 种状态：
● Empty：表示组内没有任何成员，但可能存在已经提交的位移数据，而且这些数据还没有过期。
● Dead：表示组内没有任何成员，而且元信息已经被移除。
● PreparingRebalance：表示准备开始 Rebalance，所有消费成员都需要重新向协调者请求加入消费者组。
● CompletingRebalance：表示所有的成员已经重新加入消费者组，正在等待分配方案。
● Stable：表示稳定状态，也就是完成 Rebalance 后可以正常消费数据的状态。

关系图：

当消费者组处于 Stable 状态时，消费者实例会定期向协调者发送心跳通知，作用就是告诉协调者实例在正常运行，当有新成员计入、成员主动离开、成员失联被动离开的场景下，协调者会通过响应心跳请求的方式，告诉所有实例，要进行 Rebalance 了。
我们分别梳理一下协调者发起新一轮 Rebalance 前，这三种情况的流程。
第一种，当有新的实例加入的时候，新加入的实例会向协调者发送 JoinGroup 请求，协调者收到后，会向所有实例响应新一轮 Rebalance 开始的信息。
第二种，当有成员主动离开消费者组，离组的成语啊你会向协调者发送 LeaveGroup 的请求，协调者收到后，会向所有实例响应新一轮 Rebalance 开始的信息。
第三种，协调者没有在规定时间内接收到某个成员的心跳通知，那么这个成员会被踢出消费者组，测试，协调者会向所有实例响应新一轮 Rebalance 开始的信息。

消费者组relabance会经过下面几个阶段

当有消费者加入消费组时，消费者、消费组及组协调器之间会经历以下几个阶段。
还有一个需要了解的地方是，当 Rebalance 开启的时候，协调者会给成员一定的时间，来提交自己当前的位移信息，然后在开始 JoinGroup 和 SyncGroup 请求

第一阶段：选择组协调器

组协调器GroupCoordinator：每个consumer group都会选择一个broker作为自己的组协调器coordinator，负责监控这个消费组里的所有消费者的心跳，以及判断是否宕机，然后开启消费者rebalance。

consumer group中的每个consumer启动时会向kafka集群中的某个节点发送FindCoordinatorRequest 请求来查找对应的组协调器GroupCoordinator，并跟其建立网络连接。
协调者，也叫做 Coordinator，它是一个专门为消费者群提供服务的角色，主要负责 Rebalance 的执行、位移管理、组成员管理等。

组协调器选择方式：
consumer消费的offset要提交到__consumer_offsets的哪个分区，这个分区leader对应的broker就是这个consumer group的coordinator，

消费者是如何找到自己所对应的协调器呢：
消费者实例的位移信息保存在 Kafka 内部创建的位移主题中，先找到当前消费者组的数据保存在位移主题的那个分区中，该分区的 Leader Replica 副本所在的 Broker 就是对应的协调者所在的 Broker。
如一个topic：topicTest 有3个分区partition 每个分区有两个副本replicate 在kafka集群broker0 broker1 broker2上 如该消费者组对应的位移主题所在分区为partition1 假设 partition1 partition2 partition3 分别在broekr1 broker22 broker0上，而partition1对应的两个副本replicat0 replicate1 位于broekr1 broker0上，leader Replicate是 replicate1,那么 replicate1对应的broker1就是就是该消费者组的组协调器

第二阶段：加入消费组JOIN GROUP
在成功找到消费组所对应的 GroupCoordinator 之后就进入加入消费组的阶段，在此阶段的消费者会向 GroupCoordinator 发送 JoinGroupRequest 请求，并处理响应。然后GroupCoordinator 从一个consumer group中选择第一个加入group的consumer作为leader(消费组协调器)，把consumer group情况发送给这个leader，接着这个leader会负责制定分区方案。

第三阶段（ SYNC GROUP)
consumer leader通过给GroupCoordinator发送SyncGroupRequest，接着GroupCoordinator就把分区方案下发给各个consumer，他们会根据指定分区的leader broker进行网络连接以及消息消费。