什么是Raft?
Raft一种用来管理日志复制的一致性算法
分为三个角色：leader(集群主节点)、follower(跟随节点)、candidate(无leader情况下会有follower升级为这个)
升级顺序：follower->candidate->leader （不能跨级别晋升）
选举过程：
- 服务刚启动全部都是follower角色，并经过一段时间才会有follower成为candidate（避免出现多个candidate分散选票），另外raft会把日志写入子节点磁盘中，允许日志落后，但是日志落后的节点无法成为leader，举个例子：
-- 比如有A、B、C、D、E 五个节点，其中AB节点挂了，CD节点是新进来的，那这种E节点的日志是最完善的，所以E会升级为candidate然后发起投票，最后获取半数赞成后成为leader。E成为leader之后就会把日志同步到CD节点（如果大家的日志都一样，那就看节点的命名顺序）
什么是paxos？
paxos分为basic-paxos和multi-paxos，basic更复杂并且效率低，所以现在都在用multi-paxos
basic-paxos流程是怎么样？
* 第一阶段a（发送prepare），proposer向acceptor提出一个协议，这里的协议可以理解为client发送过来期望多节点一起保存的一致性内容，举例：一句日志，某个配置等
* 第一阶段b（计算协议vn），根据半数以上acceptor的返回，选择 max{va,vb,vc} = vn，这里的vx理解为这个acceptor已知的最大协议号，acceptor一旦返回了vx后，则表明：
* acceptor在接下来的prepare请求中，会返回的vx自增1
* acceptor不会accept任何小于vx的协议请求，只会accept大于vx的协议请求
* 第二阶段a（发送决议好的vn），把vn发送给acceptor
* 第二阶段b，在半数acceptor返回了成功后，再返回client成功通过协议
坑爹的地方：basic-paxos的第一阶段，接收者之后只会接收最大的vn，这样如果存在多个proposer提议者，那vn就会被频繁刷新，不同proposer就会相互锁住对应的提交
multi-paxos的优化？
multi-paxos相对于basic，最大的优化点是仅有一个proposer，这样不会导致多个proposer相互锁锁住提交，我们称这个提议者为leader。省去basic-paxos的prepare阶段。
- 其选主leader的方式如下：
-- 最简单的选举方法是拿Server ID最大的当leader（每个leader每隔T时间向其他Server发心跳，如果2T时间内没收到更高ID心跳，那就成为leader）
paxos与raft区别？
1 raft仅允许日志最多的当leader，而multi-paxos任意节点都可当选leader
2 raft不允许日志空洞，multi-paxos允许
- 什么是日志空洞？就是日志中间有些信息断开了，比如假设写入了 A->B->C 数据，那日志应该是 A日志->B日志->C日志，但是multi-paxos的leader允许"A日志->缺了B->C日志"，B日志它可以异步从其他节点拉取回来，而raft就不允许这种情况，比如是完整的日志
什么是ZAB?
ZAB集群角色划分为leader、follower, 只有leader可以写，leader、follower都可以读。
客户端给zk发送一个写请求的时候，会有leader节点把proposal提议发送给所有follower，如果超过半数（比如5台3ack，3台2ack）给leader返回ack，（leader在发送提议前 以及 follower在返回ack前 都会把数据写入日盘日志文件）， 如果leader收到超过半数ack，就会把日志文件的proposal(提议)数据加载到内存znode中，并且commit通知所有follower节点也加载磁盘日志到内存znode中。
总结：角色划分（leader+follower）、2PC、过半写机制
还有一个ZAB协议？这个与Paxos又有什么区别？
ZAB是专门为zk设计的一种崩溃可恢复原子广播协议，他与paxos的区别在于
- ZAB额外加了一个同步阶段，新的leader会确保所有进程都已经完成之前事务proposal的提交
各自用途
ZAB协议：构建一个高可用的分布式数据主备系统，例如ZooKeeper
Paxos：则构建一个分布式的一致性状态机系统
