Kafka集群Leader与分区Leader选举机制相关技术问题咨询

1. Kafka集群是否存在Leader broker？该角色由谁选举产生？ #

Kafka集群存在被称为Controller的管理角色，也就是通常所说的Leader broker，是集群中唯一负责分区Leader选举、副本重分配、topic创建/删除等集群管理任务的节点。
该角色由ZooKeeper（KRaft模式下由控制器Quorum）选举产生：所有broker启动时都会尝试在ZooKeeper中创建/controller临时节点，第一个创建成功的节点即为集群Controller，其余broker会监听该节点的状态，一旦节点失效就会触发新一轮Controller选举。

2. 创建topic时的初始分区Leader是由ZooKeeper选举还是broker自行选举？ #

初始分区Leader由集群Controller直接分配，无需额外选举流程：

• 创建topic的请求首先会提交到ZooKeeper，记录topic的分区、副本配置信息
• Controller监听到ZooKeeper中新增的topic配置事件后，会遵循优先副本优先原则，直接指定每个分区的AR（分配副本）列表中第一个可用副本作为初始Leader，将分区Leader信息更新到ZooKeeper后同步给集群内所有broker。

3. 未配置自动重平衡时，扩容ZooKeeper到3个节点就能解决Leader为NONE、不触发重平衡的问题是什么原因？ #

该问题的核心是单节点ZooKeeper可用性不足导致的集群元数据读写异常，和分区Leader选举逻辑本身无关：

• 单节点ZooKeeper集群没有冗余能力，一旦节点出现网络抖动、负载过高、磁盘IO阻塞等问题，就会出现读写超时甚至服务不可用的情况。此时Controller既无法正常感知broker的存活状态，也无法向ZooKeeper写入新的分区Leader元数据，就会出现分区Leader被置为NONE、无法触发重平衡的现象。
• 扩容为3节点ZooKeeper集群后，ZK集群满足过半可用原则，只要超过半数节点存活即可正常对外提供读写服务，可用性大幅提升。此时Controller可以正常监听到broker下线事件，也可以正常写入新的Leader元数据，即使没有配置auto.leader.rebalance.enable参数，也会自动触发故障转移，将故障节点上的分区Leader切换到其他可用的ISR副本上。

补充说明：auto.leader.rebalance.enable参数控制的是集群空闲时自动将分区Leader调整回优先副本的定时任务，和故障场景下的强制Leader转移逻辑无关，故障转移是Controller的默认内置逻辑，无需额外开启该参数。

内容的提问来源于stack exchange，提问作者YeonCheol Jang