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

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

当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的上下文缓存会清楚这些副本信息。

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

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

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