kafka的leader选举过程（详细）

梦里梦外; 2022-12-14 03:56 340阅读 0赞

## 前言 ##

要理解kafka的leader选举，先了解下zookeeper的基本操作

## zookeeper的基本操作 ##

备注：本章主要是指作为zookeeper的客户端的基本操作

**1）四种节点类型**

PERSISTI   PERSIST\_SEQUENTIAL   EPHEMERAL    EPHEMERAL\_SEQUENTIAL

（1）PERSIST：永久节点，会被持久化到磁盘之中。即使zookeeper重启之后，节点还是会存在。

（2）EPHEMERAL：瞬时节点，zookeeper重启之后，不会存在。假设Client没有了userheart了，这个节点也不会存在。Client与zookeeper的session结束了，这个节点也不会有了

（3）SEQUENTIAL:顺序节点。假设不是顺序节点的话，Client1创建了节点/a，那么其它Client就不能再创建节点/a，否则将报错。但是如果是SEQUENTIAL节点的话，Client1创建了节点/a，若其它Client也创建节点/a，则不会报错，也可以创建成功，只不过命名规则会在末尾加序号，越早创建的序号靠前。

**2）可注册Watch操作**

为什么要注册Watch操作呢？因为我们其实希望Client可以感知到节点的各种更新操作，但是也不喜欢定时去查看这种变化，而是去订阅这种变化，每当节点有变化时，把这信息发给客户端。

（1）创建节点

（2）删除节点

（3）修改节点

（4）子节点的相关操作

**3）Watch特征**

（1）Client先得到通知再得到数据

例如修改了某个节点的数据，Client先是得到这个节点的数据被修改的信息，然后再得到被修改后的数据。

（2）Watch被fire后即取消，不会再Watch后续变化。

**\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\***

备注：zookeeper有两种选举方式，zookeeper官方更推荐第二种，而kafka更倾向于使用第一种。

## 第一种：抢注leader节点——非公平模式 ##

这种方式和java里多线程的方式一样，谁抢到了资源就是谁的。这里同理，无论先后，谁抢到leader就是谁的。

（1）创建leader父节点，例如/kafka，并将其设置成persist节点。

（2）各客户端通过/kafka下创建leader节点，如/kafka/leader，来竞争leader节点，并且这个节点应该设置成ephemeral。

（3）若创建leader节点成功，则该客户端成功竞选为leader

（4）若创建leader节点失败，则竞选leader失败。而此时，则会在/kafka/leader节点上注册exist的watch，一旦后期这个leader被删除了，则可通过watch获取到信息，去竞争leader。

（5）leader可通过删除leader节点来放弃leader

（6）如果leader宕机了，因为leader节点被设置成ephemeral了，所以leader节点会自行删除。而由于其它follower已经在leader上注册了watch，所以会得到leader被删除的消息，参与leader竞选，从而保证总有客户端已leader角色工作。

## 第二种：先到先得，后者监视前者——公平模式 ##

（1）创建Leader父节点，如 /kafka，并将其设置为persist节点  
（2）各客户端通过在/kafka下创建Leader节点，如/kafka/leader，来竞争Leader。该节点应被设置为ephemeral\_sequential  
（3）客户端通过getChildren方法获取/kakfa/下所有子节点，如果其注册的节点的id在所有子节点中最小，则当前客户端竞选Leader成功  
（4）否则，在前面一个节点上注册watch，一旦前者被删除，则它得到通知，返回step （3）（并不能直接认为自己成为新Leader，因为可能前面的节点只是宕机了）  
（5）Leader节点可通过自行删除自己创建的节点以放弃Leader

## kafka“各自为政”的leader选举 ##

kafka在kafka0.8.2之前的版本均是采用这种选举方式

**1）“各自为政”Leader Election**  
 每个Partition的多个Replica同时竞争Leader

**2）优点**  
实现简单

**3）缺点**  
Herd Effect  
Zookeeper负载过重  
Latency较大

总结：缺点很明显，假设有很多个kafka的broker，每个broker又有多个topic，每个topic又有多个partition。这样各自为政的选举，相当耗性能的。

## kafka基于controller的leader选举 ##

kafka在0.8.2版开始采用了这种选举方式

**1）基于Controller的Leader Election**  
整个集群中选举出一个Broker作为Controller  
Controller为所有Topic的所有Partition指定Leader及Follower

**2）优点**  
极大缓解Herd Effect问题  
减轻Zookeeper负载  
Controller与Leader及Follower间通过RPC通信，高效且实时

**3）缺点**  
引入Controller增加了复杂度  
需要考虑Controller的Failover

总结：1、kafka利用zookeeper去选举出controller；2、kafka通过controller选指定出leader和follower，而无需通过zookeeper了。