1. leader选举流程解剖
leaderElection/AuthFastLeaderElection/FastLeaderEletion(默认)
FastLeaderElection
- serverId:在配置server集群的时候，给定服务器的标识id(myid)
- zxid:服务器在运行时产生的数据ID，zxid的值越大，表示数据越新
- Epoch：选举轮数
- server的状态：Looking、Following、Observering、Leading
第一次初始化启动的时候：Looking
- 所有在集群中的server都会推荐自己为leader，然后把（myid、zxid、epoch)作为广播信息，广播给集群中的其他server,然后等待其他服务器返回
- 每个服务器都会接受来自集群中的其他服务器的投票。集群中的每个服务器在接受投票后，开始判断投票的有效性
- 判断逻辑时钟（Epoch）,如果Epoch大于自己当前的Epoch，说明自己保存的Epoch是过期。更新Epoch，同时clear其他服务器发送过来的选举数据。判断是否需要更新当前的选举情况
- 如果Epoch小于目前的Epoch，说明对方的epoch过期，也就意味着对方服务器的选举轮数是过期的。这个时候，只需要将自己的信息发送给对方
-
流程图
2. ZAB协议
拜占庭问题: 在古代，一些拜占庭的将军率领他们的部队要攻占敌人的一个城池, 每个将军只能控制他们自己的部队并且通过信使传递消息给其他的将军(这条消息只有参与的两个将军知道，其他的将军可以打听，但是不能验证消息的正确性)。如果这些将军中有些是来自敌方的奸细，那么如何使忠诚的将军仍然可以达成行动协议而不受奸细的挑拨，就是拜占庭将军问题
paxos协议主要就是如何保证分布式网络环境下,各个服务器如何达成一致，最终保证数据一致性问题
ZAB协议是基于paxos的一个改进
- ZAB协议为分布式协调服务zookeeper专门设计的一种支持崩溃恢复的原子广播协议
- zookeeper并没有完全采用paxos算法，而是采用ZAB Zookeeper Atomic Broadcast
ZAB协议的工作原理
- 在zookeeper的主备模式下，通过zab协议来保证集群中各个副本数据的一致性
- zookeeper使用的是单一的主进程来接受并处理所有的事务请求，并采用zab协议把数据状态变更以事务请求的形式广播到其他的节点
- zab协议在主备模型的架构中，保证了同一时刻只能有一个主进程来广播服务器的状态变更
- 所有的事务请求必须由全局唯一的服务器来协调处理，这个服务器叫leader，其他的叫follower,leader节点主要负责把客户端的事务请求转化为一个事务提议（proposal)，并分发给集群中的所有follower节点，在等待所有follower节点的反馈。一旦超过半数服务器进行了正确的反馈，那么leader就会commit这条消息
zab协议的工作原理
- 什么情况下zab协议会进入崩溃恢复模式
- 当服务器启动时
- 当leader服务器出现网络中断、崩溃或者重启的情况
- 急群众已经不存在过半的服务器与该leader保持正常通信
- zab协议进入崩溃恢复模式会做什么
- 当leader出现问题，zab协议进入崩溃恢复模式，并且选举出新的leader。当新的leader选举出来以后，如果集群中已经有过半的机器完成了leader服务器的状态同（数据同步），退出崩溃恢复，进入消息广播模式
当新的机器加入到集群中的时候，如果已经存在leader服务器，那么新加入的服务器就会自觉进入数据恢复模式，找到leader进行数据同步
mark
FAQ：
假设一个事务在leader服务器被提交了，并且已经有过半的follower返回了ack.在leader节把commit消息发送给follower机器之前leader服务器挂了怎么办
- zab协议，一定需要保证已经被leader提交的事务也能够被所有follower提交
- zab协议需要保证在崩溃恢复过程中跳过那些已经被丢弃的事务
