上一篇 <<<CAP理论和Base理论
下一篇 >>>为什么Zookeeper集群节点一定要是奇数
选举原则
leader选举
要求 可用节点数量 > 总节点数量/2 。注意 是 > , 不是 ≥。
选举概念
Myid:服务节点上的id
Zxid：服务器事务id（事务写的请求保存的id），数据越新，zxid越来大
epoch：逻辑时钟，在服务端是一个自增序列，每次进入下一轮投票后，就会加1；
选举步骤
1、系统刚启动，或者leader宕机，则所有Follower节点状态都会变更为Looking（选举状态），Observing（观察者状态）的节点不参与选举
2、每个节点都会有myid和zxid，myid是配置项，zxid默认为0，如果运行了一段时间，则每个节点的zxid值是由老leader产生分发的，zxid越大说明数据越新
3、先检查zxid，谁最大说明数据是最新的，就被选举为leader
4、如果zxid都一样，就判断myid谁最大就是leader
5、如果有过半选出了leader，则之后的节点不会加入选举
总结：优先比较zxid、其次比较myid；
选举示例
(1,100) , (2,100) ,(3,100) -----2为leader，具体选举策略查看下面表格
Zxid相等，取决于优先启动顺序比较myid
(1,103) ，(2,102)，(3,101) -----1为leader
优先比较zxid，1>2
Demo：总结点数：3，最后选举节点2为master。
| 节点1票数 | 节点2票数 | 节点3票数 | |
|---|---|---|---|
| 启动节点1 myid=1 | 1[没有其他节点只能投给自己] | ||
| 启动节点2 myid=2 | 0[节点2的myid比当前大，则票数投给节点2] | 2启动了两个节点，自身节点myid更大，所以投给自己，加上节点1投的1票 | |
| 启动节点3 myid=3 | 0 | 3 | 0节点2已经达到了两票，满足投票过半原则，所以不需要重新选举，直接把票给了myid=2 |
推荐阅读：
<<<Zookeeper基础知识及应用场景
<<<Zookeeper如何实现分布式锁
<<<CAP理论和Base理论
<<<为什么Zookeeper集群节点一定要是奇数
<<<Zookeeper在后期新增zk节点时如何提高选举效率问题
<<<Zookeeper如何保证节点一致性问题
<<<Zookeeper的Zab一致性协议原理
<<<Zookeeper实现哨兵选举机制
<<<Zookeeper示例之访问权限控制
<<<Zookeeper示例之服务发现与治理
<<<Zookeeper示例之分布式锁
<<<Zookeeper示例之节点事件监听
<<<Zookeeper示例之集群请求
<<<Linux环境安装Zookeeper
<<<Zookeeper配置文件介绍
<<<Zookeeper常见问题
<<<Eureka与Zookeeper有啥区别？
<<<Zookeeper常用命令
