强一致性算法

分布式系统对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