深度解读Paxos在MGR中的工程实践

Posted 2021-04-17 数据库技术汇

1. 背景

mysql Group Replication的理论基础是Database State Machine。更新事务的开始和执行是不需要和其它节点进行通讯协调的，直到事务提交的时候，当前事务涉及的改动会发送到其它节点，保证所有节点上事务的顺序是全局相同的。之后，一个检测进程会来进行验证，验证并发执行的多个事务之间是否存在冲突：确认是否有其它事务也在尝试更新相同的记录。如果没有发现冲突，则当前事务在所有节点上完成提交，否则终止当前事务。

具体的事务提交流程，可以参考这篇文章：MySQL Group Replication – Transaction life cycle explained。

这个方案的核心是一个组通讯系统，它管理组中的成员、保障事务消息在所有的节点上是全局有序的。成员管理和全局有序的消息分发，是分布式系统中的基础概念，通常称为“共识”的达成：

共识问题要求一组进程就某一个值达成一致。

在MySQL Group Replication中，“共识”包含：MySQL实例之间就一个新实例是否可以加入集群，一个旧实例是否应该移除，以及如何确定下一个即将分发的事务等。

Paxos几乎是分布式系统领域最出名的一致性协议了，它分为Prepare和Accept两个阶段，如下图所示：

基础Paxos算法是面向leader的算法，第一个阶段叫做Prepare或者Leader选举阶段，这个阶段中，发起节点发送一个带着ballot编号的消息给其它所有节点，其实意味着发起节点希望成为leader。如果其它节点没有收到过请求，或者当前发起节点发送的ballot编号是接收节点见到的最大ballot，那么接收节点回复发起节点。如果接收节点已经接受了某个不大于发起节点的ballot的提案，则返回这个提案给发起节点。最终，如果发起节点收到多数派节点的回复，它就变成了新的leader。如果在一个timeout间隔内发起节点尝试选举成leader失败，发起节点会以一个更大的ballot编号，尝试重新选择成leader。

值得注意的是，第一个阶段只有当前leader故障时才需要。否则，只需要运行协议的第二阶段（accept阶段）。可以参考：Good Leaders are game changes: Paxos & Raft，其中包含了leader选举、ballot编号等问题的讨论。

在第二个阶段中，leader提议一个提案，只要接收节点没有收到大于当前leader提案中的ballot编号的请求，接收节点就会回应leader。如果收到来自多数派节点的回应，就认为这个提案被选定了。

当leader发现一个提案已经被接受后，它向其它所有成员发送一个learn消息，告诉其它成员当前提案已经被选定，可以在组通讯系统中分发，最终这个消息会分发到MySQL Group Replication组件中。通常，learn消息会附带在下一次Prepare的消息中，或者和其它消息组成一个batch。

工程中，对一个序列数值达成一致的协议叫做Multi-Paxos。

注意，在基础或标准Multi-Paxos中，所有的成员需要把事务的改动发送给leader，以此来保证消息的全局有序分发。如果事务是在leader节点发起的，这是没问题的；否则，需要一次额外的通讯，所以通常leader也很容易成为瓶颈。

这类协议的扩展性较差，因为随着系统中副本数目或者负载的增加，leader副本会首先遭遇瓶颈。

2. XCOM

MySQL Group Replication是多主集群，任何一个节点都可以发起事务更新请求。在基于leader的协议中，由于所有的更新都需要路由到leader节点上，所以基于leader的协议不利于扩展。因此，我们的首要目标就是解决单leader方案中潜在的瓶颈，我们设计了一种多leader（更准确地说是多proposer）的方案。这个方案和Mencius非常类似，例如都使用noop来跳过某些消息的slot，但总体上这个设计还是更接近于原始的Paxos。

在我们设计的协议中，每一个节点都有一个唯一的节点编号，在全局有序的消息序列中，每一个节点都有属于自身保留的slot。例如，有3个节点：

• 节点0持有slots:  0, 3, 6, … 3 * n + 0

• 节点1持有slots:  1, 4, 7, … 3 * n + 1

• 节点2持有slots:  2, 5, 8, … 3 * n + 2

在一个包含’g’个节点的集群中，每一个节点的下一个slot按照这个公式计算产生：g * n + 节点编号。’n’是一个单调递增的计数，每一个节点自己维护，在一个新proposal发送之后递增。

因此，这个协议中没有leader选举，每一个节点是它所属slots的leader，是协议约定的。对于自己所属的slots，节点不用等待其它节点而发起提案，尽管不同节点间的gaps（差距）上有一些限制（具体我们在下一节中描述）。

2.1 Handling Gaps

如果允许节点在不需要协调的条件下发起提案，那么很有可能在整个消息序列中会存在gaps（空洞）。例如，节点1和节点2可能已经就“消息1”和“消息2”达成一致，但是节点0还没有就“消息0”达成一致，无论“消息0”未达成一致的原因是什么。（“消息0”对应slot0，“消息1”对应slot1，“消息2”对应slot2）

在这种情况下，节点在“消息0”尚未达成一致并分发的情况下，是无法分发“消息1”和“消息2”到MySQL Group Replication层的。否则，全局有序的消息分发这个约束就会被破坏。因此，节点必须learn到slot 0的选定消息并分发之后，才可以依次处理消息1，2，3…

显而易见，消息序列中的gaps，是会影响性能的，同时系统也必须非常小心地处理这些gaps。节点0没有就slot 0的消息达成一致，原因有很多种：它可能本身就没有新提案到来，也可能是节点宕机了，也可能仅仅是因为网络延迟或者处理比较慢。

如果节点0没有新的提案需要提议，它发送一个跳过消息给其它成员，告诉他们它没有新提案，可以把对应的slot以“noop”填充。“noop”消息会在slot owner没有新提案，或者发现已经有其它节点在等待它所属的slot达成一致，才能继续整个进度的时候，发送出去。通常，当一个节点learn到一个大于自身slot的消息已经达成一致的时候，就会触发“noop”消息的发送。

这个跳过的“noop”消息，不需要走完整的paoxs流程（例如：prepare、accept和learn）。这是一个learn类型的消息，告诉其它节点他们应该就某个slot以“noop”填充。针对slot的owner，这个优化是可行的。但是对于非slot的owner节点，他们必须运行完整的paoxs流程来填充“noop’”到某个slot中。换句话说，如果节点1想往slot 0提交一个提案，它必须跑完paxos的prepare和accept两个阶段。

值得注意的是，prepare阶段的目的，是为了找出一个slot是否有其它消息已经被选定或提议。所以在上面这种情况下，其它节点会代表slot owner来发起prepare消息。通过运行Paxos协议中完整的两个阶段，来确保不会产生不一致的问题。为了避免多个节点同时尝试代表其它某个节点发起“noop”消息提案，存活节点中拥有最小节点编号的节点来完成这个操作，这个约束的主要目的是尽量保证整个系统达成一致的高效性。但是，这个过程中没有严格的leader选举，因为发起“noop”消息提案的节点，并不会变成其它节点所属slot的owner，它只是为了让整个系统可以继续得以往前推进。

2.2 Implemented Optimizations

多个消息可以batch在一起，填充到同一个slot中，以此来减少系统中消息通讯的开销。另外，节点也可以在前序提案尚未达成一致的情况下，开启新提案的执行。batch和pipeline是MySQL Group Replication提升性能的两个主要手段，但是：

这两个手段的有效性，依赖系统特性，主要包含网络延时和带宽，其次也依赖CPU处理能力和应用的特性。

可以参考：Tuning Paxos for high-throughput with batching and pipelining，了解关于这个话题的更多细节。

这个设计中，事务数据只会在accept阶段传输一次，避免了大量事务数据在proposer和acceptor之间来回传输。根据Vitor，仅这个优化，就可以带来大约20%左右的性能提升。

3. Current Limitations

截止MySQL 5.7.17，目前还不支持用户调整batch和pipeline的size。目前的实现中，还不支持定义一个节点在Paxos协议中的角色：proposer、acceptor和learner。这也意味中，所有的节点都是proposer，所以也很容易理解：一个慢节点会拖慢整个系统。慢的原因可能是因为网络延迟、机器硬件问题、机器过载等。