背景
kafka重平衡的主要发生在消费者端，重平衡的目的，主要是为了均衡消费者消费kafka的消息而筹划的，对于动态参加消费者，减少消费者，以及消息分区变革这些场景中，若不筹划消费者重平衡，轻易出现某个消费者消费消息出现倾斜的情况，如：某个消费者消费的消息特别多，而某些消费者不消费消息，造成资源的浪费。
触发条件
- 消费者组内成员变动，如新增消费者，消费者下线。
- 主题的分区数发生变动，kafka支持动态增加主题的分区，当增加主题的分区时会触发重平衡。
- 订阅的主题发生变革。当消费者组使用正则表达式订阅主题时，这时kafka的主题发生变革时，就会触发重平衡流程。
以上这几个场景就是kafka触发重平衡流程的场景，其他的场景，如消费者消费消息时间过长，这些场景其实可以归纳为第一类场景，无非就是消费者心跳检测超时，导致消费者下线，从而触发的重平衡。
在了解重平衡之前，你必要知道这两个脚色
群组协调器（Coordinator）：群组协调器是一个能够从消费者群组中收到全部消费者发送心跳消息的 broker。在最早期的版本中，元数据信息是保存在 ZooKeeper 中的，但是现在元数据信息存储到了 broker 中。每个消费者组都应该和群组中的群组协调器同步。当全部的决议要在应用步伐节点中举行时，群组协调器可以满意 JoinGroup 请求并提供有关消费者组的元数据信息，例如分配和偏移量。群组协调器还有权知道全部消费者的心跳，消费者群组中还有一个脚色就是领导者，注意把它和领导者副本和 kafka controller 举行区分。领导者是群组中负责决议的脚色，所以如果领导者掉线了，群组协调器有权把全部消费者踢出组。因此，消费者群组的一个很重要的举动是选举领导者，并与协调器读取和写入有关分配和分区的元数据信息。
消费者领导者：每个消费者群组中都有一个领导者。如果消费者停止发送心跳了，协调者会触发重平衡。
在了解重平衡之前，你必要知道状态机是什么
Kafka 筹划了一套消费者组状态机(State Machine) ，来资助协调者完成整个重平衡流程。消费者状态机主要有五种状态它们分别是 Empty、Dead、PreparingRebalance、CompletingRebalance 和 Stable。
了解了这些状态的含义之后，下面我们用几条路径来表示一下消费者状态的轮转
- 消费者组一开始处于 Empty 状态，当重平衡开启后，它会被置于 PreparingRebalance 状态等待新消费者的参加，一旦有新的消费者参加后，消费者群组就会处于 CompletingRebalance 状态等待分配，只要有新的消费者参加群组或者离开，就会触发重平衡，消费者的状态处于 PreparingRebalance 状态。等待分配机制指定好后完因素配，那么它的流程图是这样的
- 在上图的基础上，当消费者群组都到达 Stable 状态后，一旦有新的消费者参加/离开/心跳逾期，那么触发重平衡，消费者群组的状态重新处于 PreparingRebalance 状态。那么它的流程图是这样的。
- 在上图的基础上，消费者群组处于 PreparingRebalance 状态后，很不幸，没人玩儿了，全部消费者都离开了，这时候还可能会保存有消费者消费的位移数据，一旦位移数据逾期或者被刷新，那么消费者群组就处于 Dead 状态了。它的流程图是这样的
- 在上图的基础上，我们分析了消费者的重平衡，在 PreparingRebalance或者 CompletingRebalance 或者 Stable 任意一种状态下发生位移主题分区 Leader 发生变动，群组会直接处于 Dead 状态，它的全部路径如下
这里面必要注意两点：
一样平常出现 Required xx expired offsets in xxx milliseconds 就表明Kafka 很可能就把该组的位移数据删除了
只有 Empty 状态下的组，才会执行逾期位移删除的操纵。
重平衡流程
上面我们了解到了消费者群组状态的转化过程，下面我们真正开始先容 Rebalance 的过程。重平衡过程可以从两个方面去看：消费者端和协调者端，首先我们先看一下消费者端
从消费者看重平衡
从消费者看重平衡有两个步调：分别是 消费者参加组 和 等待领导者分配方案。这两个步调后分别对应的请求是 JoinGroup 和 SyncGroup。
新的消费者参加群组时，这个消费者会向协调器发送 JoinGroup 请求。在该请求中，每个消费者成员都必要将自己消费的 topic 举行提交，我们上面描述群组协调器中说过，这么做的目的就是为了让协调器收集充足的元数据信息，来选取消费者组的领导者。通常情况下，第一个发送 JoinGroup 请求的消费者会自动称为领导者。领导者的使命是收集全部成员的订阅信息，然后根据这些信息，订定具体的分区消费分配方案。如图
在全部的消费者都参加进来并把元数据信息提交给领导者后，领导者做出分配方案并发送 SyncGroup请求给协调者，协调者负责下发群组中的消费计谋。下图描述了 SyncGroup 请求的过程
当全部成员都乐成接收到分配方案后，消费者组进入到 Stable 状态，即开始正常的消费工作。
从协调者来看重平衡
从协调者角度来看重平衡主要有下面这几种触发条件，
- 新成员参加组
- 构成员主动离开
- 构成员崩溃离开
- 构成员提交位移
我们分别来描述一下，先从新成员参加组开始
新成员参加组
我们讨论的场景消费者集群状态处于Stable 等待分配的过程，这时候如果有新的成员参加组的话，重平衡的过程
从这个角度来看，协调者的过程和消费者雷同，只是刚刚从消费者的角度去看，现在从领导者的角度去看
构成员离开
构成员离开消费者群组指的是消费者实例调用 close() 方法主动关照协调者它要退出。这里又会有一个新的请求出现 LeaveGroup()请求 。如下图所示
构成员崩溃
构成员崩溃是指消费者实例出现严肃故障，宕机或者一段时间未响应，协调者接收不到消费者的心跳，就会被认为是构成员崩溃，崩溃离组是被动的，协调者通常必要等待一段时间才气感知到，这段时间一样平常是由消费者端参数 session.timeout.ms 控制的。如下图所示
重平衡时提交位移
这个过程我们就不再用图形来表示了，大抵描述一下就是 消费者发送 JoinGroup 请求后，群组中的消费者必须在指定的时间范围内提交各自的位移，然后再开启正常的 JoinGroup/SyncGroup 请求发送。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
