分布式系统对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
失败地行为 分区行为
场景测试：
Raft场景测试
ZAB
raft为了保证日志连续性，心跳方向为leader至follower。ZAB则相反。
分布式锁
实际应用中，主要使用Zookeeper和Etcd
Zookeeper
内部使用ZAB
etcd
内部使用Raft
---------------------
作者：SeuLJ
来源：CSDN
原文：https://blog.csdn.net/yaotai8135/article/details/83050138
版权声明：本文为博主原创文章，转载请附上博文链接！