快速理清Paxos、Zab、Raft协议

前言

Paxos、Zab、Raft都属于在分布式环境保持数据一致性的相关算法。

对于这三个算法，初次接触的时候有很多疑惑的地方：

1. 这3个算法的实现是什么，复杂么

2. 为什么要存在这么多算法，一个不能解决么，都用在什么场景。

算法本身不太复杂，但是应用在实际场景中解决问题，开发起来还是比较复杂的。

下面尽可能简单易懂的进行描述。

Paxos

paxos算法是在不会出现拜占庭错误的环境下达成一致性协议的解决方案。

p.s. 分布式环境都是通过网络通讯，系统中的成员可能出错而发送错误的信息，用于传递信息的通讯网络也可能导致信息损坏，传输或响应的信息有误算是拜占庭错误，而非拜占庭错误就是说信息不会在传输过程中遭到篡改。

详细了解，查看：拜占庭将军问题

角色

paxos在分布式环境中存在多个节点，节点的角色如下：

• Client    在分布式系统中发送一个请求并等待响应，比如写一条数据的请求
• Proposer  发送prepare和accept请求，对于client发送的请求希望Acceptor能同意
• Acceptor   处理prepare和accept请求，就是对发送的请求进行投票
• Learner     对于上面的请求，获取paxos算法的结果
• Leader    Paxos集群中选出唯一一个节点作为leader处理提议

Acceptor是对请求进行投票的，那在分布式环境中作为Acceptor的大部分节点都应当是存活的，来保证多票当选（同zab或raft的投票选举来理解）。

并不是一个节点只能作为一个角色，paxos实现的集群，每一个节点应该包含Proposer、Acceptor、Learner三种角色，可以处理Client请求并进行投票最终响应。

Paxos的实现也是不同的，比如Basic Paxos和Multi-Paxos，本文主要以基本实现进行说明。

算法

paxos算法实现分为两个阶段，通信过程中数据结构可以简化为(n, v)表示。

n表示一个提案号，v是与该提案号对应的值。

e.g. client要写入一条数据，Proposer提出一个提案号给集群中其它的Acceptor，如果有Quorum（可以认为是半数以上）的Acceptor同意这个提案，那么这个提案号对应的数据v就可以被写入。

这两个阶段如下：

阶段1a：Proposer发出一条“Prepare"消息，带着提案号n，发给Acceptor（包括它自身）

阶段1b：Acceptor收到Proposer的Prapare消息后，看一下这个提案号和之前收到的提案号相比，如果比之前的都大就同意（发一条Propose消息给Proposer），不是就忽略或表示拒绝

阶段2a：Proposer收到Qururm数量的Acceptor的Propose消息，说明都同意这个提案，就发送一个Accept(n,v)消息给这些Acceptor（带着提案号和该提案号对应的数据）

阶段2b：收到Proposer的Accept消息的Acceptor就把这个数据写入。

这样就算达成一个共识，如果上面提案最终失败，其实会重新开始新一轮提案。

下面这个流程图来自Paxos的wiki，可以看一下帮助理解下这个过程：

图片来源

注意，上面这个基本的paxos实现包括两个阶段会涉及很多消息交换，Multi-Paxos 实现会选举一个leader，只需要第2阶段即可确定一个值。

Paxos的实现案例 chubby：