kafka分区管理

根据kafka消息的管理，我们知道kafka对消息进行了分区管理，并将分区尽量均匀分布到集群中，每个partition都有一个leader。那么客户端怎么知道某个partition的leader信息？partition leader又是怎么维护的呢？

1.partition isr

每个partition在其zk的/state节点中保存了该partition的信息，如下：

{"controller_epoch":1,"leader":0,"version":1,"leader_epoch":0,"isr":[0]}

其中isr全称in sync replica，这个partition同步中的副本，是partition所有副本的子集，若partition leader宕机后将从该列表中选取broker作为leader。该集合中的broker均能够跟进partition leader的消息同步进度，这里的进度是根据配置文件配置的，包含最大落后消息数、心跳时间间隔，若落后消息数超过配置上限或心跳间隔超过配置时间将从该列表中移除。

2.controller

早期版本kafka依赖zk管理集群，新版本引入controller来管理。所有的broker启动后会去zk上注册controller临时节点，但只有一个broker能够注册成功，这个broker即为contoller。若controller宕机后，zk上的临时节点会消失，其他broker又会一起去注册，产生新的controller。注册失败的broker叫做broker follower，会读取controller的信息并保存到内存中。
由zookeeper如何保存kafka集群信息metadata
可知，这个controller节点为zk下的/controller节点，包含如下信息：

{"version":1,"brokerid":0,"timestamp":"1605488793510"}

controller注册成功后，会向zk注册监听器watcher，监听相关节点变化，而其他broker则不用再监听zk。
controller主要职责包括：
监听partition变化，处理partition重新分配、leader选举、isr列表更新；
监听/broker/ids节点，处理broker移除、新增变化；
监听topic的新增移除；
监听/broker/topics节点，维护topic、partition metadata；

3.controller分区管理

1. controller首先从zk的/broker/topics节点读取各topic partition的副本信息，从中选取一个作为leader，选取方法见kafka消息的管理，将所有副本放入isr集合，并将数据同步到各broker。
2. controller会监听zk 的/admin/ressign_part节点，用户执行分区更改脚步的内容会写入该节点，controller读取格式化信息并重新分区。
3. controller监听/broker/topic节点变化信息，监听partition的增减情况，当发生partition增减时，重新执行leader选举和isr同步，并更新所有broker信息。
4. controller监听/broker/ids节点，当有broker宕机时，controller从isr列表中选取新的leader；若isr列表为空，则从所有副本中选取leader；若所有副本列表都为空，则等待副本重新加入。