ReplicaStateMachine：副本状态机

• ReplicaStateMachine:副本状态机抽象类，定义了一些常用方法(如 startup、 shutdown 等)，以及状态机最重要的处理逻辑方法 handleStateChanges。
• ZkReplicaStateMachine:副本状态机具体实现类，重写了 handleStateChanges 方 法，实现了副本状态之间的状态转换。目前，ZkReplicaStateMachine 是唯一的 ReplicaStateMachine 子类。
• ReplicaState:副本状态集合，Kafka 目前共定义了 7 种副本状态。

副本状态及状态管理流程

副本状态机一旦被启动，就意味着它要行使它最重要的职责了:管理副本状态的转换。

源码中的 ReplicaState 定义了 7 种副本状态。

1. NewReplica:副本被创建之后所处的状态。
2. OnlineReplica:副本正常提供服务时所处的状态。
3. OfflineReplica:副本服务下线时所处的状态。
4. ReplicaDeletionStarted:副本被删除时所处的状态。
5. ReplicaDeletionSuccessful:副本被成功删除后所处的状态。
6. ReplicaDeletionIneligible:开启副本删除，但副本暂时无法被删除时所处的状态。
7. NonExistentReplica:副本从副本状态机被移除前所处的状态。

ReplicaState 接口及其实现对象定义了每种状态的序号，以及合法的前 置状态。

sealed trait ReplicaState {
  def state: Byte
  def validPreviousStates: Set[ReplicaState]
}

case object NewReplica extends ReplicaState {
  val state: Byte = 1
  val validPreviousStates: Set[ReplicaState] = Set(NonExistentReplica)
}

handleStateChanges 方法

第 1 路:转换到 NewReplica 状态

即目标状态是 NewReplica 的代码

第 2 路:转换到 OnlineReplica 状态

即转换副本对象到 OnlineReplica，这是副本对象正常工作时所处的状态。

第 3 路:转换到 OfflineReplica 状态

将副本对象的状态转换成 OfflineReplica。

---

PartitionStateMachine：分区状态机

PartitionStateMachine 负责管理 Kafka 分区状态的转换，和 ReplicaStateMachine 是一 脉相承的。从代码结构、实现功能和设计原理来看，二者都极为相似。

• PartitionStateMachine:分区状态机抽象类。它定义了诸如 startup、shutdown 这 样的公共方法，同时也给出了处理分区状态转换入口方法 handleStateChanges 的签 名。
• ZkPartitionStateMachine:PartitionStateMachine 唯一的继承子类。它实现了分区 状态机的主体逻辑功能。和 ZkReplicaStateMachine 类似，ZkPartitionStateMachine 重写了父类的 handleStateChanges 方法，并配以私有的 doHandleStateChanges 方 法，共同实现分区状态转换的操作。
• PartitionState 接口及其实现对象:定义 4 类分区状态，分别是 NewPartition、 OnlinePartition、OfflinePartition 和 NonExistentPartition。除此之外，还定义了它 们之间的流转关系。
• PartitionLeaderElectionStrategy 接口及其实现对象:定义 4 类分区 Leader 选举策 略。你可以认为它们是发生 Leader 选举的 4 种场景。
• PartitionLeaderElectionAlgorithms:分区 Leader 选举的算法实现。既然定义了 4 类选举策略，就一定有相应的实现代码，PartitionLeaderElectionAlgorithms 就提供了 这 4 类选举策略的实现代码。

分区状态

Kafka 为分区定义了 4 类状态。

1. NewPartition:分区被创建后被设置成这个状态，表明它是一个全新的分区对象。处于 这个状态的分区，被 Kafka 认为是“未初始化”，因此，不能选举 Leader。
2. OnlinePartition:分区正式提供服务时所处的状态。
3. OfflinePartition:分区下线后所处的状态。
4. NonExistentPartition:分区被删除，并且从分区状态机移除后所处的状态。

分区 Leader 选举的场景及方法

每个分区都必须选举出 Leader 才能正常提供服务，因此，对于分区而言，Leader 副本是 非常重要的角色。

分区 Leader 选举有 4 类场景

1. OfflinePartitionLeaderElectionStrategy:因为 Leader 副本下线而引发的分区 Leader 选举。
2. ReassignPartitionLeaderElectionStrategy:因为执行分区副本重分配操作而引发的分 区 Leader 选举。
3. PreferredReplicaPartitionLeaderElectionStrategy:因为执行 Preferred 副本 Leader 选举而引发的分区 Leader 选举。
4. ControlledShutdownPartitionLeaderElectionStrategy:因为正常关闭 Broker 而引发 的分区 Leader 选举。

PartitionLeaderElectionAlgorithms

针对这 4 类场景，分区状态机的 PartitionLeaderElectionAlgorithms 对象定义了 4 个方 法，分别负责为每种场景选举 Leader 副本，这 4 种方法是:

• offlinePartitionLeaderElection;
• reassignPartitionLeaderElection;
• preferredReplicaPartitionLeaderElection;
• controlledShutdownPartitionLeaderElection。

1、assignments

这是分区的副本列表。该列表有个专属的名称，叫 Assigned Replicas，简称 AR。当我们 创建主题之后，使用 kafka-topics 脚本查看主题时，应该可以看到名为 Replicas 的一列数 据。这列数据显示的，就是主题下每个分区的 AR。assignments 参数类型是 Seq[Int]。这 揭示了一个重要的事实:AR 是有顺序的，而且不一定和 ISR 的顺序相同!

2、isr

ISR 在 Kafka 中很有名气，它保存了分区所有与 Leader 副本保持同步的副本列表。注意， Leader 副本自己也在 ISR 中。另外，作为 Seq[Int]类型的变量，isr 自身也是有顺序的。

3、liveReplicas

从名字可以推断出，它保存了该分区下所有处于存活状态的副本。怎么判断副本是否存活 呢?可以根据 Controller 元数据缓存中的数据来判定。简单来说，所有在运行中的 Broker 上的副本，都被认为是存活的。

4、uncleanLeaderElectionEnabled

在默认配置下，只要不是由 AdminClient 发起的 Leader 选举，这个参数的值一般是 false，即 Kafka 不允许执行 Unclean Leader 选举。所谓的 Unclean Leader 选举，是指 在 ISR 列表为空的情况下，Kafka 选择一个非 ISR 副本作为新的 Leader。由于存在丢失数 据的风险，目前，社区已经通过把 Broker 端参数 unclean.leader.election.enable 的默认 值设置为 false 的方式，禁止 Unclean Leader 选举了。

代码首先会顺序搜索 AR 列表，并把第一个同时满足以下两个条件的副本作为新的 Leader 返回:

1. 该副本是存活状态，即副本所在的 Broker 依然在运行中;
2. 该副本在 ISR 列表中。