crontroller会维护每台broker上的分区副本和每个分区的leader副本信息，即副本状态和分区状态，因此，controller引入了两个状态机，分别用来管理副本状态和分区状态。

副本状态机，Replica State Machine，有如下7种状态:

NewReplica:crontroller创建副本时的最初状态，在此状态下的副本只能成为follower副本。

OnlineReplica:启动副本后变更为该状态，处于该状态下的副本既可以成为follower副本，又可以成为leader副本。

OfflineReplica:当副本所在的broker发生异常奔溃后，该副本将会变更为该状态。

ReplicaDeletionStarted:如果开启了topic删除操作，topic下所有分区的所有副本都会被删除，此时副本进入该状态。

ReplicaDeletionSuccessful:如果副本成功响应了删除副本请求，便会进入该状态。

ReplicaDeletionIneligible:如果副本删除失败，则会进入该状态。

NotExistentReplica:如果副本被成功删除，则会进入该状态。

整体变更流程如下:

当创建某个topic后，最初该topic下所有分区的所有副本都是NonExistent状态，然后controller会加载副本信息到内存中，此时同步更新副本状态为NewReplica,然后controller会确定分区的leader和ISR并将这些信息发送到所有副本，同步到所有broker上。完成这些，副本状态会被修改为OnlineReplica，如果某个时刻开启了topic删除操作，controller会尝试停止所有副本，对于follower角色所在副本会停止向leader获取数据，对于leader角色所在副本会被设置为NO_LEADER,然后进入OfflineReplica状态，当删除任务开启后，状态会被变更为ReplicaDeletionStarted，当副本数据被成功删除后，副本状态会更新为ReplicaDeletionSuccessful，之后会自动更新为NonExistent终止状态，并且controller的上下文缓存会清除这些副本信息，如果部分副本删除失败，则会进入ReplicaDeletionIneligible状态，等待进行重试。

分区状态机，Partition State Machine，用来负责集群下所有分区的状态管理，含有4个分区状态:

NonExistent:不存在的分区或已删除的分区。

NewPartition:一旦被创建，分区便处于该状态。

OnlinePartition:当分区的leader被选出后，进入此状态。

OfflinePartition:当leader所在的broker宕机后，分区将进入该状态，此时无法正常工作。

整体变更流程如下:

当某个topic创建后，crontroller会创建分区对象，最初所有分区状态会被设置为NonExistent，然后Crotroller会读取副本分配方案，此时分区状态会进入NewPartition状态，然后controller会初始化leader和ISR信息，并设置分区状态为OnlinePartition。如果某时刻进行了删除topic或关闭broker操作，则会将分区状态变为OfflinePartition状态，删除成功后，最终会将分区状态设置为NonExistent，如果关闭的是leader副本所在的broker，则还需要开启新一轮的leader选举并调整分区状态为OnlinePartition。

对集群状态的维护是crontroller保持运行状态一致性的基本要素，为了保持controller稳定地对外提供服务，controlller还需要承担以下职责。

1).更新集群员数据信息。kafka中要求clients能够通过集群中任意一台broker查询topic的分区信息等元数据，因此，controller实现了如下机制，当有分区信息发生变更时，controller将变更后的信息封装进UpdateMetatataRequests请求，然后广播发送给集群中的每个broker，使得clients在请求数据时总是能够获取到最新，最及时的分区信息。

2).创建topic。可以有3种方式创建topic。第1种，通过kafka-topics脚本的--create创建。第2种，构造CreateTopicsRequest请求创建。配置broker端参数auto.create.topics.enable为true，然后发送MetadataReRequest请求。创建topic后，会在Zookeeper的/brokers/topics下创建一个对应的znode节点，然后将该topic的分区以及副本列表信息写入znode中。

3).可以通过kafka-topics脚本的--delete方式或者构造构造DeleteTopicsRequest的方式来删除topic，进行删除时会在Zookeeper的/admin/delete_topics下新建一个znode节点，然后开启删除topic操作。删除完成后，会移除该znode节点。

4).分区重分配，由kafka集群的管理员发起，在该操作中需要手动制定分配方案并按照一定格式写入ZooKeeper的/admin/resaasign_partitions节点。分区副本重配是一个先扩展再收缩的过程，controller先将分区副本集合进行扩展，等到全部与leader保持同步后将leader设置为新分配方案中的副本，然后再执行收缩阶段，将分区副本集合缩减为新分配方案中的副本集合。

5).preferred leader选举。设置位于副本列表的第一位的副本为该分区的preferred leader。当分区的leader由于某种原因发生变更后，可以通过以下两种方式将leader重新调整为perferred leader。第一种方式是设置broker端参数auto.leader.rebalance.enable为true,使得controller会定时自动调整preferred leader。第二种方式是通过kafka-preferred-replica-election脚本手动触发。实现这两种方法时会向Zookeeper的/admin/preferred_replica_election节点写入数据。

6).topic分区扩展，当现有topic的分区数据不足以支撑业务量后，需要增加分区，可以通过kafka-topics脚本的--alter选项实现。

7).broker加入集群。当broker启动成功后会在Zookeeper的/broker/ids下创建一个znode节点，会在znode中写入broker的信息。

8).broker崩溃。当broker奔溃后，broker与Zookeeper的会话会失效并导致临时znode节点被删除。当发现该节点删除后，controller便会知道该broker退出集群，接下来会开启broker退出逻辑，更新集群元数据并同步到其他broker上。

9).受控关闭。也可称为优雅关闭，指的是通过kafka-server-stop脚本，kill -15方式关闭broker，优雅关闭是相对于强制关闭而言，强制关闭通常由掉电，kill -9实现，受控关闭能最大限度地降低broker的不一致性。在受控关闭时，即将关闭的broker会向controller发送CrontrolledShutdownRequest请求，然后会处于阻塞状态，直到接收到controller端发送的ControlledShutdownResponse时，broker可以正常退出。

10).controller leader选举。当kafka中的controller发生故障或者显式关闭，kafka需要保证能够及时选举出新的controller。当关闭controller所在的broker或者controller所在的broker宕机，崩溃，或手动删除，修改Zookeeper中的/crontroller节点这些情况都会导致发生controller leader选举。当选举成为controller后，会增加controller的版本号，更新/controller_epoch节点的值。