Kafka--Leader选举过程的理解

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

提示：这里可以添加本文要记录的大概内容：

一，早期版本

kafka早期的版本就是直接采用了Zookeeper来完成选举的，kafka利用了Zookeeper的Watch机制（节点不允许重复写入以及临时节点的特性）

补充问题： watch机制是什么玩意儿？
可以理解为某个Znode接地那上的监听器。当这个 Znode 发⽣改变，也就是调⽤了 create ， delete ， setData ⽅法的时候，将会触发 Znode 上注册的对应事件，请求 Watch 的客户端会接收到异步通知。

但是，zookeeper的 watch有一个缺点，就是这个watch只能被触发一次，一旦发出了通知，如果还想对这个节点继续watch，用户需要重新设置watch。

存在的弊端：
分区和副本数量过多的时候，所有的副本都要直接参与选举的话，一旦某个节点出现增减，将会造成大量的watch事件被触发，zookeeper就会负载过重。

补充问题： 为什么某个节点出现增减，就会造成大量watch事件被触发？
如果某个节点增减，都需要告知其它节点，进而让其它节点发生了什么事情；（惊群效应）
对于每个 watch 请求，zookeeper 都会打开一个新的 socket 连接，这样 zookeeper 就需要实时管理很多 socket 连接，比较复杂；

二，新版本

旧版本中的问题就是：在参与选举的副本太多的情况下，而导致选举成本大幅度增加；
因此，在新版本中，它不是所有的副本都会参与leader的选举；

选举原理

第一步：选出选举委员会主席
而是由其中一个Broker(某个节点)来统一指挥，这个Broker的角色就叫做Controller控制器，kafka首先要从所有的Broker中，选出一个唯一的Controller（选举委员会的主席，有点像redis里面的哨兵机制中兵王）

Controller的职能：
a. 监听Broker变化；
b. 监听Topic变化；
c. 监听Partition变化；
d. 获取和管理Broker,Topic,Partition的信息
c. 管理Partition的主从关系信息

补充问题：

1. kafka是如何从Broker中选出唯一的Controller?
   答： 选举时，所有的Broker会尝试在Zookeeper中创建临时节点/controller,谁先创建成功，谁就是Controller.

2. 如果Controller挂掉了或是网络出现异常时，kafka将会如何处理？
   答： 如果Controller挂掉了或是网络出现异常时，这个Controller临时节点就会消失，其它的Broker节点就会由于Watch机制，监听到Controller下线的通知，然后继续按照先到先得的原则，选举一个新的Controller节点；

第二步：定下候选人员

老版本中，由于参加选举的Broker节点过多，而存在的性能成本；
所以在新版本中，并不是所有的节点都是有竞选资格的；

候选资格：
只有在ISR中，保持心跳同步的副本，才有资格参与竞选；

补充问题

1. 什么是ISR？
   答： 一个分区所有的副本，叫做Assigned-Replicas(AR) 。所有的皇太子。
   这些所有的副本中，跟leader数据保持一定程度同步的，叫做In-Sync Replicas(ISR) 。
   跟leader同步滞后过多的副本，叫做Out-Sync-Replicas(OSR) 。
   AR=ISR+OSR。正常情况下OSR是空的，大家都正常同步，AR=ISR。
   谁能够参加选举呢?肯定不是AR，也不是OSR，而是ISR。而且这个ISR不是固定不变的，还是一个动态的列表。
   前面我们说过，如果同步延迟超过30秒，就踢出ISR，进入OSR； 如果赶上来了，就加入ISR。

第二步：Leader选举开始

从候选人名单中，挑选出Leader;
分布式选举中，有很多选举协议：ZAB（zookeeper）, Raft（redis）等等 （先到先得，少数服从多数原则）
kafka新版选举算法 和 微软的 PacificA算法类似；

默认是让ISR中的第一个副本变成Leader。即：如果ISR中的链表顺序为：1-5-9，那么节点1将会成为Leader;

---

参考视频：
Kafka副本Leader选举原理的理解

浅谈kafka存储原理