目录
Basic Paxos
三个角色
达成共识的方法
对于Basic Paxos的总结
Multi-Paxos
领导者
优化 Basic Paxos 执行
reference

Paxos 算法包含 2 个部分：
1、Basic Paxos ：描述多节点之间如何就某个值达成共识
2、Multi-Paxos ：描述执行多个Basic Paxos实例，对一系列值达成共识

Basic Paxos

三个角色

该算法中存在三个角色：提议者、接受者、学习者，关系如下：
在这里插入图片描述
提议者：提议一个值，用于投票表决。在大多数场景中，往往是集群中收到客户端请求的节点时提议者。这样对于业务代码就没有侵入性，不需要再业务代码中实现算法逻辑。
接受者：对每个提议的值进行投票，并存储接受的值。一般来说，集群中的所有节点都是接受者，参与共识协商，并接受和存储数据
注意：一个节点可以担任多个角色，如下：
在这里插入图片描述

学习者：被告知投票的结果，接受达成共识的值，存储保存，不参与投票的过程。一般来说，学习者是数据备份节点，比如“Master - Slave”模型中的Slave，被动接受数据，容灾备份。
三个角色代表三种功能：

1、提议者代表接入和协调功能，收到客户端请求后，发起二阶段提交，进行共识协商
2、接受者代表协商和存储数据，对提议的值进行投票，并接受达成共识的值，存储保存
3、学习者代表存储数据，不参与共识协商，只接受达成共识的值，存储保存

达成共识的方法

分为准备阶段和接受阶段。
这里假设两个客户端作为提议者和3个节点作为接受者，
客户端1的想要对节点中的Key为X的数据将Value设置为3，客户端2的想要对节点中的Key为X的数据将Value设置为5。
提议者发送给接受者的信息我们称为提案，结构为[n,v]，n为提案编号（相当于事务ID，后发起的提案编号越大），v为提议值（写入db的值）
准备阶段
在准备阶段，两个提议者分别向所三个接受者发送包含提案编号的准备请求，准备请求中只包含提案编号。并假设接受者节点收到准备请求的时序图如下：
在这里插入图片描述
接下来是各个接受者节点对于先收到的准备请求的响应。由于之前没有通过任何提案，A,B,C都会返回“尚无提案”的响应。
但是有所不同的是，A,B会告诉提议者，不再响应提案编号 <= 1的准备请求，C会告诉提议者，不再响应提案编号 <= 5的准备请求.
也就是说每个节点之后接受比当前提案编号大的请求。
在这里插入图片描述
接下来是各个接受者第二次收到准备请求的响应。
A,B收到的请求，编号为5 >= 1 ，并且此时两个节点没有通过任何提案，所以返回“尚无提案”响应，并不再响应提案编号 <= 5的准备请求.
C收到的请求，编号为1 < 5 ,所以丢弃该准备请求，不做响应。
在这里插入图片描述
接受阶段
两个提议者节点在收到大多数节点的准备响应之后，会分别发送接受请求。
对于客户端1来说，根据响应中提案编号最大的提案的值，设置接受请求中的值。（客户端1只有来自A,B的准备响应），因为响应均为”尚无提案“，所以客户端1会将自己的提议值：3，作为提案值，然后发送接受请求[n, v] : [1,3];
对于客户端2来说，根据响应中提案编号最大的提案的值，设置接受请求中的值。（客户端2来自A,B,C的准备响应），因为响应均为”尚无提案“，所以客户端1会将自己的提议值：7，作为提案值，然后发送接受请求[n, v] : [5,7];
在这里插入图片描述
三个接受者节点收到两个提议者的接受请求，会进行处理：
对于A,B,C节点来说，它们对于请求[1,3]，都不会接受，因为提案编号 < 5（最小提案编号）。
它们对于请求[5,7]都会接受，因为提案编号 >= 5,通过提案之后，将提案值：7作为X的Value。
在这里插入图片描述

对于Basic Paxos的总结

根据提案编号的大小，接受者保证三个承诺，具体来说：

如果准备请求的提案编号，小于等于接受者已经响应的准备请求的提案编号，那么接受者将承诺不响应这个准备请求；
如果接受请求的提案编号，小于接受者已经响应的准备请求的提案编号，那么接受者将承诺不通过这个提案；
如果接受者之前有通过提案，那么接受者将承诺，会在准备请求的响应中，包含已经通过的最大编号的提案信息。

Multi-Paxos

Basic Paxos 只能就单个值（Value）达成共识，一旦遇到为一系列的值实现共识的时候，它就不管用了。
它具有两个缺点：
1、如果多个提议者同时提交提案，可能出现因为提案编号冲突，在准备阶段没有提议者接收到大多数准备响应，协商失败，需要重新协商
2、2 轮 RPC 通讯（准备阶段和接受阶段）往返消息多、耗性能、延迟大。

可以通过通过引入领导者和优化 Basic Paxos 执行来解决这两个问题。

领导者

领导者节点作为唯一提议者，就不会存在多个提议者同时提交提案的情况，也就不存在提案冲突了。
模型结构如下：
在这里插入图片描述
如何选举领导者需要我们在Multi-Paxos自己实现。
在Chubby中，主节点是通过执行 Basic Paxos 算法，进行投票选举产生的，并且在运行过程中，主节点会通过不断续租的方式来延长租期（Lease）。比如在实际场景中，几天内都是同一个节点作为主节点。如果主节点故障了，那么其他的节点又会投票选举出新的主节点，也就是说主节点是一直存在的，而且是唯一的。
所有的读请求和写请求都由主节点来处理。当主节点从客户端接收到写请求后，作为提议者，执行 Basic Paxos 实例，将数据发送给所有的节点，并且在大多数的服务器接受了这个写请求之后，再响应给客户端成功：
在这里插入图片描述
当主节点接收到读请求后，处理就比较简单了，主节点只需要查询本地数据，然后返回给客户端就可以了：

缺点就是所有写请求都在主节点处理，限制了集群处理写请求的并发能力，约等于单机。

优化 Basic Paxos 执行

下面两个图是 Basic Paxos 以及有领导者的优化执行。

图1 Basic Paxos

图2 优化之后

可以看到，当领导者处于稳定状态时，省掉准备阶段，直接进入接受阶段。这是因为领导者节点上的命令时最新的，不需要通过准备请求来发现之前被大多数节点通过的提案，领导者可以独立指定提案中的值。如何理解领导者处于稳定状态？领导者节点上，序列中的命令是最新的，不再需要通过准备请求来发现之前被大多数节点通过的提案，领导者可以独立指定提案中的值。准备阶段的意义，是发现接受者节点上，已经通过的提案的值。如果在所有接受者节点上，都没有已经通过的提案了，这时，领导者就可以自己指定提案的值了，那么，准备阶段就没有意义了，也就是可以省掉了。

本质上而言，“当领导者处于稳定状态时，省掉准备阶段，直接进入接受阶段”这个优化机制，是通过减少非必须的协商步骤来提升性能的。这种方法非常常用，也很有效。比如，Google 设计的 QUIC 协议，是通过减少 TCP、TLS 的协商步骤，优化 HTTPS 性能。