ReplicaStateMachine：副本状态机

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

副本状态及状态管理流程

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

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

NewReplica:副本被创建之后所处的状态。
OnlineReplica:副本正常提供服务时所处的状态。
OfflineReplica:副本服务下线时所处的状态。
ReplicaDeletionStarted:副本被删除时所处的状态。
ReplicaDeletionSuccessful:副本被成功删除后所处的状态。
ReplicaDeletionIneligible:开启副本删除，但副本暂时无法被删除时所处的状态。
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 类状态。

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

分区 Leader 选举的场景及方法

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

分区 Leader 选举有 4 类场景

OfflinePartitionLeaderElectionStrategy:因为 Leader 副本下线而引发的分区 Leader 选举。
ReassignPartitionLeaderElectionStrategy:因为执行分区副本重分配操作而引发的分区 Leader 选举。
PreferredReplicaPartitionLeaderElectionStrategy:因为执行 Preferred 副本 Leader 选举而引发的分区 Leader 选举。
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 返回: