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

1 大数据常用的选主机制

Leader选举算法非常多，大数据领域常用的有以下两种:

1.1 Zab(zookeeper使用)

Zab协议有四个阶段

• Leader election
• Discovery (E#epoch establish)
• Synchronization (5X#sync with followers)
• Broadcast

比如3个节点选举leader：编号为1、2、3。 1先启动，选择自己为leader，然后2启动

首先也选择自己为leader，由于1,2都没过半，选择编号大的为leader，所以1、2都

选择2为leader，然后3启动发现1，2已经协商好且数量过半，于是3也选择2为leader，leader选举结束。

1.2 Raft

类似美国大选。

在Raft中，任何时候一个服务器可以扮演下面角色之一：

• Leader

  处理所有客户端交互，日志复制等，一般只有一个Leader

• Follower

  类似选民，完全被动

• Candidate候选人

  可被选为一个新的领导人

启动时在集群中指定一些机器为Candidate，然后Candidate开始向其他机器(尤

其是Follower)拉票，当某个Candidate的票数超过半数，它就成为leader。

都是 paoxs 算法的变种。

由于Kafka集群依赖zookeeper集群，所以最简单最直观的方案是，所有Follower

都在ZooKeeper上设置一个Watch，一旦Leader宕机，其对应的ephemeral

znode会自动删除，此时所有Follower都尝试创建该节点，而创建成功者

(ZooKeeper保证只有一个能创建成功)即是新的Leader，其它Replica即为

Follower。

2 常用选主机制的缺点

2.1 split-brain (脑裂)

这是由ZooKeeper的特性引起的，虽然ZooKeeper能保证所有Watch按顺序触发，但是网络延迟，并不能保证同一时刻所有Replica“看”到的状态是一样的，这就可能造成不同Replica的响应不一致，可能选出多个领导“大脑”，导致“脑裂”。

2.2 herd effect (羊群效应)

如果宕机的那个Broker上的Partition比较多， 会造成多个Watch被触发，造成集群内大量的调整，导致大量网络阻塞。

2.3 ZooKeeper负载过重

每个Replica都要为此在ZooKeeper上注册一个Watch，当集群规模增加到几千个Partition时ZooKeeper负载会过重。