Kafka Partition Leader选主机制

Kafka Partition Leader选主机制
更多干货
分布式实战（干货）
spring cloud 实战（干货）
mybatis 实战（干货）
spring boot 实战（干货）
React 入门实战（干货）
构建中小型互联网企业架构（干货）
python 学习持续更新
ElasticSearch 笔记
kafka storm 实战 (干货)
1、概述
大数据经常使用的选主机制
经常使用选主机制的缺点
Kafka Partition选主机制
2、大数据经常使用的选主机制
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负载会太重

3、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