Kafka Controller(状态管理)

Controller用来协调和管理Kafka集群，在一个Kafka集群中，只有一个broker可以当选Controller，当Controller在的broker宕机后，其他Broker可以竞争当选Controller。

状态管理

Controller被用在状态管理，主要用来管理每台broker上的分区副本和每台broker上分区的leader副本信息。上述两种状态可以成为副本状态和分区状态。为了维护以上两种状态，Kafka引入了副本状态机和分区状态机。

副本状态机

• New：controller刚刚创建副本时副本的状态，此状态的副本只能成为follower副本
• Online：启动副本后变更为该状态，此状态的副本既可以成为follower副本也可以成为leader副本
• Offline：当副本所在的broker宕机后，副本的状态就会转变为Offline
• ReplicaDeletionStarted：当Kafa集群开启了topic删除且收到某个topic的删除命令时，该topic下的副本就会进入该状态
• ReplicaDeletionSuccessful：当副本成功删除以后，副本就会进入该状态
• ReplicaDeletionIneligible：当有副本删除失败时，副本就会进入该状态，等待controller的重试
• NonExistent：当副本成功删除后，副本进入该状态，或者Topic刚刚创建副本并未建立时，副本就处于该状态。

当Kafka Topic刚刚创建时，该Topic的副本处于NonExistent状态，此时controller加载Zookeeper中该Topic每个分区的副本信息到内存中，同时将副本更新为New状态，之后controller选择分区的第一个副本作为leader副本并设置所有副本进入ISR，然后再Kafka中持久化该决定。

当确定了分区副本以及leader以后，controller会将这些信息发送给各个副本，同时将副本状态同步给所有的broker。上述操作完成以后，副本就会进入Online状态。

当开启了Topic删除操作，controller会停止所有副本，如果是follower副本将停止向leader副本fetch数据，如果是leader副本，controller会设置该分为的leade为NO_LEADER，之后副本进入Offline状态。紧接着，controller会将副本的状态变为ReplicaDeletionStarted状态表明开始进行Topic删除。controller会向所有的副本发出删除请求，请求他们删除本地的副本数据，当所有副本删除成功以后，便会进入ReplicaDeletionSuccessful状态。假设删除过程中有其中一个副本删除失败，则会进入ReplicaDeletionIneligible状态，等待controller的重试。同时处于ReplicaDeletionSuccessful状态会自动变为NonExistent状态，同时controller的上下文缓存会清楚这些副本信息。

分区状态机

• NonExistent：表明分区不存在或分区已被删除
• New：一旦分区被创建，分区便处于该状态。此时Kafka已经确定了分区列表，但是还没有选出Leader和ISR。
• Online：一旦分区leader被选出，则进入该状态，表示分区可以正常工作
• Offline：当分区leader所在的broker宕机以后则会进入该状态，表明分区无法正常工作

当创建Topic时，controller负责创建分区对象，首先会短暂的将所有分区置为NonExistent状态，之后读取Zookeeper中的副本分配方案，然后令分区进入New状态。处于New状态的分区当选出Leader副本和ISR时，将会进入Online状态。

若用户发起了删除Topic操作，分区会进入NonExistent状态，并且还会开启分区下的副本删除操作。如果是关闭broker操作或者宕机，controller会判断broker是否是分区leader，如果是则需要开启新一轮的分区leader选举然后将分区状态改回Online状态。

controller职责

Controller除了状态管理以外，还有更重要的职责，这些职责功能我们下一节中讲述。