参考链接: B站视频
什么是一致性CAP理论：
对于一个分布式系统，不能同时满足以下三点：
一致性（Consistency）
可用性（Availability）
分区容错性（Partition Tolerance）
一致性模型弱一致性
最终一致性(不保证即时读取一致)
DNSGossip 强一致性
同步PaxosRaft(multi-paxos)ZAB(multi-paxos)
强一致性算法之主从同步：
Master接受写请求
Master复制日志至slave
Master等待，直到所有从库返回
**问题：**一个节点失败，Master阻塞,导致整个集群不可用,保证了一致性,可用性却大大降低
强一致性算法之多数派：
基本思想：每次写都保证写人大于N/2个节点,每次读保证从大于N/2个节点中读
问题：在并发环境下，无法保证系统的准确性，顺序是非常重要的。
Paxos为描述Paxos算法,Lamport（Latex的发明者）虚拟了一个叫做Paxos的希腊城邦,这个岛按照议会民主制的政治模式制订法律，但是没有人愿意将自己的全部时间和精力放在这种事。所以无论是议员,议长或者传递纸条的服务员都不能承诺别人需要时一定会出现,也无法承诺批准决议或者传递消息的时间。
Basic PaxosMulti PaxosFast Paxos
Basic Paxos
Client： 系统外部角色，请求发起者，像民众
Proposer ：接收Client请求，像集群提出议题（proposal），并在冲突发生时，起到冲突调节的作用，像议员
Acceptor：提议的投票者和决策者，只有在形成法定人数（一般是majority多数派）时，提议才会被最终接受，像国会
Learner：最终提议的接收者，backup，对集群的一致性没有什么影响，像记录员
四个阶段：
- Phase la: Prepare
proposer提出一个提案,编号为N,此N大于这个proposer之前提出提案编号。请求acceptors的quorum接受。Phase 1b: Promise
如果N大于此acceptor之前接受的任何提案编号则接受、否则拒绝。Phase 2a: Accept
如果达到了多数派,proposer会发出accept请求,此请求包含提案编号N,以及提案内容。Phase 2b: Accepted
如果此acceptor在此期间没有收到任何编号大于N的提案,则接受此提案内容，否则忽略。
流程图
Acceptor不关心提议的内容
潜在的问题-活锁（liveness）或dueling
一个完整的事务，需要两次RPC远程调用，分别是Prepare阶段和Accpet阶段。效率不高因为是多个proposer可以都提交提案，因此会出现活锁问题，Proposer1提出了M1的提案，并完成的Prepare阶段。与此同时，Proposer2提出了一个新的提案M2(M2>M1)，同样也完成了Prepare阶段，于是Acceptor承诺不再批准编号小于M2的提案。当P1进入Accept阶段时，其发出的Accept请求将被Acceptor忽略。于是Proposer1再次进入Prepare阶段并提出一个编号为M3(M3>M2)的提案，而这又会让Proposer2的M2在第二阶段的Accept请求被忽略，如此陷入死循环。
Multi Paxos
只有一个Leader Proposer，只有Leader Proposer可以提出提案，Leader Proposer通过选举产生。
Raft
划分为三个子问题
Leader ElectionLog ReplicationSafety
重新定义角色
LeaderFollowerCandidate
原理动画解释
http://thesecretlivesofdata.com/raft/
场景测试
https://raft.github.io/
一致性并不一定代表完全正确的，需要Client的一些操作。
三个结果可能是：成功、失败和Unknown
Example（5 nodes）
Client写请求, leader向followers同步日志，此时集群中有3个节点失败,2个节点存活,结果是？
使用场景测试模拟
ZAB基本与raft相同。
在一些名词的叫法上有些区别:如ZAB将某一个leader的周期称为epoch,而raft则称之为term。
实现上也有些许不同:如raft保证日志连续性,心跳方向为leader至follower。ZAB则相反。
