ZAB协议-高端面试-原理与算法

zookeeper成功的地方就是使用了zab协议。

ZAB协议(ZooKeeper Atomic Broadcast原子消息广播协议)
zab协议所有事务请求必须由leader协调，首先leader发起proposal消息，大多数server同意后，然后leader发送commit消息。
zxid编号
1、低32位为计数器，客户端每次请求+1
2、高32位为epochID，每次选举新leader+1
状态和阶段
1、Looking：系统刚启动时或者Leader崩溃后正处于选举状态
2、Following：Follower节点所处的状态，Follower与Leader处于数据同步阶段
3、Leading：Leader所处状态，当前集群中有一个Leader为主进程

zookeeper主要分为5个阶段，选举，发现，同步，广播
选举：Looking状态中选举出Leader节点，Leader的lastZXID总是最新的
发现： Follower节点向准Leader推送FOllOWERINFO，该信息中包含了上一周期的epoch，接受准Leader的NEWLEADER指令，检查newEpoch有效性，准Leader要确保Follower的epoch与ZXID小于或等于自身的
同步：将Follower与Leader的数据进行同步，由Leader发起同步指令，最终保持集群数据的一致性
广播：Leader广播Proposal与Commit，Follower接受Proposal与Commit；

选举

zab必须确保选举出来的leader具有最大的zxid(这和raft很像啊)。这里要注意一下，和raft一样，选举可能会出现两种结果：
1、上一轮的多数派(此时leader zxid可能不是最大的，需要同步的时候调用trunc)
2、上一轮的少数派，leader zxid真的是最大的(但是这个最大的zxid没有提交，在同步阶段提交？)
过程详解：
1、每个Follower都向其他节点发送选自身为Leader的Vote投票请求，等待回复；
2、Follower接受到的Vote如果比自己的ZXID更新时则投票，并更新自身的Vote，否则拒绝投票；
3、每个Follower中维护着一个投票记录表，当某个节点收到过半的投票时，结束投票并把该Follower选为Leader，投票结束；

恢复(发现和同步)

发现
leader生成新的zxid和epoch，接受follower发送来的FOllOWERINFO（含有当前节点的LastZXID）
leader向follower发送NEWLEADER；Leader根据follower发送过来的LastZXID根据数据更新策略向Follower发送更新指令；
同步
SNAP：如果follower数据太老，epoch还在上上一轮，leader将发送快照snap指令给follower同步
DIFF：正常同步阶段
TRUNC：如果Follower是上一轮的少数派(通过对比ztid)，发送TRUNC指令让follower丢弃这段数据
广播
进入正常leader提交阶段，产生递增的zxid，接受半数投票后，再提交。

数据一致性与paxos算法

据说Paxos算法的难理解与算法的知名度一样令人敬仰，所以我们先看如何保持数据的一致性，这里有个原则就是：
在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致的状态。
Paxos算法解决的什么问题呢，解决的就是保证每个节点执行相同的操作序列。好吧，这还不简单，master维护一个全局写队列，所有写操作都必
须放入这个队列编号，那么无论我们写多少个节点，只要写操作是按编号来的，就能保证一致性。没错，就是这样，可是如果master挂了呢。
Paxos算法通过投票来对写操作进行全局编号，同一时刻，只有一个写操作被批准，同时并发的写操作要去争取选票，只有获得过半数选票的写操作才会
被批准（所以永远只会有一个写操作得到批准），其他的写操作竞争失败只好再发起一轮投票，就这样，在日复一日年复一年的投票中，所有写操作都被严格编号排序。编号严格递增，当一个节点接受了一个编号为100的写操作，之后又接受到编号为99的写操作（因为网络延迟等很多不可预见原因），它马上能意识到自己
数据不一致了，自动停止对外服务并重启同步过程。任何一个节点挂掉都不会影响整个集群的数据一致性（总2n+1台，除非挂掉大于n台）。