Kafka Partition Leader选主机制

更多干货 分布式实战（干货） spring cloud 实战（干货） mybatis 实战（干货） spring boot 实战（干货） React 入门实战（干货） 构建中小型互联网企业架构（干货） python 学习持续更新 ElasticSearch 笔记 kafka storm 实战 (干货) 一、概述 大数据常用的选主机制 常用选主机制的缺点 Kafka Partition选主机制 二、大数据常用的选主机制 Leader选举算法非常多，大数据领域常用的有 以下两种:

Zab(zookeeper使用);

Raft； …… 它们都是Paxos算法的变种。

Zab协议有四个阶段:

Leader election;

Discovery（或者epoch establish）； Synchronization（或者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选举结束。

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

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

Follower: 类似选民，完全被动 Candidate候选人: 可以被选为一个新的领导人 启动时在集群中指定一些机器为Candidate ，然后Candidate开始向其他机器(尤其是Follower)拉票，当某一个Candidate的票数超过半数，它就成为leader。

常用选主机制的缺点

由于Kafka集群依赖zookeeper集群，所以最简单最直观的方案是，所有Follower都在ZooKeeper上设置一个Watch，一旦Leader宕机，其对应的ephemeral znode会自动删除，此时所有Follower都尝试创建该节点，而创建成功者（ZooKeeper保证只有一个能创建成功）即是新的Leader，其它Replica即为Follower。

前面的方案有以下缺点：

split-brain (脑裂): 这是由ZooKeeper的特性引起的，虽然ZooKeeper能保证所有Watch按顺序触发，但并不能保证同一时刻所有Replica“看”到的状态是一样的，这就可能造成不同Replica的响应不一致 ;

herd effect (羊群效应): 如果宕机的那个Broker上的Partition比较多，会造成多个Watch被触发，造成集群内大量的调整；

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

三、Kafka Partition选主机制

Kafka 的Leader Election方案解决了上述问题，它在所有broker中选出一个controller，所有Partition的Leader选举都由controller决定。controller会将Leader的改变直接通过RPC的方式（比ZooKeeper Queue的方式更高效）通知需为此作为响应的Broker。

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一次之后即失效，所以需要重新注册。

Kafka partition leader的选举过程如下 (由controller执行)：

从Zookeeper中读取当前分区的所有ISR(in-sync replicas)集合

调用配置的分区选择算法选择分区的leader