Kafka Partition Leader选举机制原理详解（下）

3 Kafka Partition选主机制

3.1 优势

Kafka的Leader Election方案解决了上述问题，它在所有broker中选出一个controller，所有Partition的Leader选举都由controller决定。

controller会将Leader的改变直接通过RPC的方式(比ZooKeeper Queue的方式更高效)通知需为此作为响应的Broker。

没有使用 zk，所以无 2.3 问题；也没有注册 watch无 2.2 问题

leader 失败了，就通过 controller 继续重新选举即可，所以克服所有问题。

3.2 Kafka集群controller的选举

每个Broker都会在Controller Path (/controller)上注册一个Watch。 当前

Controller失败时，对应的Controller Path会自动消失(因为它是ephemeral

Node)，此时该Watch被fire，所有“活” 着的Broker都会去竞选成为新的

Controller (创建新的Controller Path)，但是只会有一个竞选成功(这点由

Zookeeper保证)。竞选成功者即为新的Leader，竞选失败者则重新在新的

Controller Path上注册Watch。因为Zookeeper的Watch是一次性的， 被fire一次

之后即失效，所以需要重新注册。

3.3 Kafka partition leader的选举

由controller执行：

• 从Zookeeper中读取当前分区的所有ISR(in-sync replicas)集合
• 调用配置的分区选择算法选择分区的leader

• 

• 上面五种分区算法都是选择PreferredReplica作为当前Partition的leader。区别仅

仅是选择leader之后的操作有所不同。

所以，对于下图partition 0先选择broker2，之后选择broker 0作カleader；对于

partition 1先选择broker 0，之后迭拝broker 1作カleader；partition 2先选择

broker1，之后选择 broker2作为leader。