basic paxos

multi paxos

Basic Paxos的问题：难实现、效率低（每次选举都有prepare的过程）、活锁，每次提交事务都要有议案议案通过之后在进行2pc提交

Multi Paxos: 只有在第一次事务提交没有leader的时候会找选举leader的过程在leader选举的时候会有议案过程以后得事务提交因为leader已经存在了所以就没有议案的过程了直接进行2pc提交；

Raft zab

这个两种一致性算法是从Multi Paxos衍生而来。

Raft

划分出了三个问题
　　leader选举
　　日志记录
　　安全（数据恢复）
1 每个节点有三个角色
　　leader 主节点
　　follow 从节点
　　candidate 当节点要竞选为leader时候的角色是个瞬间角色
2 两个阶段
　　2.1 选择leader阶段
　　2.2 提交数据
只能提交给leader 然后由leader向follow节点同步过半节点接受即可
3 leader和follow节点心跳监控
　　由leader节点固定时间给follow发心跳包 follow自身会维护一个定时器在定时的时间内如果没有收到leader的心跳包就认为leader挂了然后发送选举自己为leader

zab

基本同raft一直不同点
1 节点的角色类型不一样没有candidate这个角色多了一个observe的角色
　　leader
　　follow
　　looking. 和raft的candidate差不多
　　observe 用来做读不参与选举leader
2 提交数据不一样
　　leader和follow数据可以提交给follow 但是follow会将请求转给leader 由leader写然后向follow同步过半即可
3 节点心跳监控原理不一样
　　由follow定时给leader发送心跳如果心跳失败 follow就认为leader挂掉选举自己为leader

raft和zab相对于Multi Paxos来说，在选举leader的过程中阉割吊了议案的过程，只有一个2pc提交。