分布式系统对fault tolorence的一般解决方案是state machine replication
主从同步复制
Master接受写请求
Master复制日志到Slave
Master等待，直到所有从库返回
问题：一个节点失败，Master阻塞，导致整个集群不可用，保证了一致性，可用性大大降低。
多数派
每次写入保证写入大于N/2个节点 每次读保证从大于N/2个节点读
问题：
在并发环境下，无法保证系统的正确性，顺序很重要。
Paxos
1. Basic Paxos
Client : 系统外部角色，请求发起者。像民众
Propser ：接受Client的请求，向集群提出提议（propose）。并在冲突发生时，起到冲突协调的作用。像议员，替民众提出议案。
Accepetor(Vector):提议投票和接收者，只有在形成法定人数时(Quorum,为多数派)，提议才会最终被接受，像国会。
Learner：提议接受者，backup，备份，对集群的一致性没有影响。像记录员。
步骤，阶段
基本流程：
部分节点失败，到达到了Quoroms。
Proposer失败
一个proposer失败，会启用另外一个proposer
活锁问题（dueling）
问题：难以实现，效率低（要经过2轮RPC），活锁
2. Multi Paxos
只有一个proposer,不存在活锁问题。
只有再最开始的时候需要2轮RPC。以后只需要一轮RPC.
减少角色，进一步简化
3. Raft
划分为3个子问题：
Leader Election
Log Replication
Safety
重定义角色：
Leader
Fellower
Candidate(候选人)
动画解释：
Raft动画演示
- 选Leader
设置timeout - 同步log
Leader不断地向fellow发送心跳包，数据也夹杂在心跳包中。 - 保证safty
失败地行为 分区行为
场景测试：
ZAB
raft为了保证日志连续性，心跳方向为leader至follower。ZAB则相反。
分布式锁
实际应用中，主要使用Zookeeper和Etcd
Zookeeper
内部使用ZAB
etcd
内部使用Raft