一致性协议（Paxos、Raft、ZAB）简单了解

参考链接: B站视频

什么是一致性

CAP理论：

对于一个分布式系统，不能同时满足以下三点：

一致性（Consistency）

可用性（Availability）

分区容错性（Partition Tolerance）

一致性模型

• 弱一致性
  • 最终一致性(不保证即时读取一致)
    • DNS
    • Gossip
• 强一致性
  • 同步
  • Paxos
  • Raft(multi-paxos)
  • ZAB(multi-paxos)

强一致性算法之主从同步：

1. Master接受写请求

2. Master复制日志至slave

3. Master等待，直到所有从库返回

**问题：**一个节点失败，Master阻塞,导致整个集群不可用,保证了一致性,可用性却大大降低

强一致性算法之多数派：

基本思想：每次写都保证写人大于N/2个节点,每次读保证从大于N/2个节点中读

问题：在并发环境下，无法保证系统的准确性，顺序是非常重要的。

Paxos

为描述Paxos算法,Lamport（Latex的发明者）虚拟了一个叫做Paxos的希腊城邦,这个岛按照议会民主制的政治模式制订法律，但是没有人愿意将自己的全部时间和精力放在这种事。所以无论是议员,议长或者传递纸条的服务员都不能承诺别人需要时一定会出现,也无法承诺批准决议或者传递消息的时间。

• Basic Paxos
• Multi Paxos
• Fast Paxos

Basic Paxos

Client： 系统外部角色，请求发起者，像民众
Proposer ：接收Client请求，像集群提出议题（proposal），并在冲突发生时，起到冲突调节的作用，像议员
Acceptor：提议的投票者和决策者，只有在形成法定人数（一般是majority多数派）时，提议才会被最终接受，像国会
Learner：最终提议的接收者，backup，对集群的一致性没有什么影响，像记录员

四个阶段：

1. Phase la: Prepare
   proposer提出一个提案,编号为N,此N大于这个proposer之前提出提案编号。请求acceptors的quorum接受。
2. Phase 1b: Promise
   如果N大于此acceptor之前接受的任何提案编号则接受、否则拒绝。
3. Phase 2a: Accept
   如果达到了多数派,proposer会发出accept请求,此请求包含提案编号N,以及提案内容。
4. 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 Election
  • Log Replication
  • Safety

• 重新定义角色

  • Leader
  • Follower
  • Candidate

• 原理动画解释

  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则相反。