分布式数据库中基于共识的复制如何工作？

产品高级副总裁

2018年8月2日

编者按：这篇文章最初发表于2018年8月2日，并于2020年5月26日更新

无论是WordPress网站的MySQL后端还是Dropbox的multi-exabyte存储系统，数据复制是在出现硬件故障（如机器崩溃、磁盘故障、网络分区和时钟偏移）时使数据持久可用的核心。复制背后的基本思想非常简单：在物理隔离的硬件上保留多个数据副本，以便一个硬件故障不会影响其他硬件；因此，系统不会丢失任何数据，并保持高度可用。复制的其他好处是，复制副本可以用于服务更多的客户端请求，并更快地服务它们，从而提高吞吐量和降低延迟。

数据复制实战（来源）

然而，复制协议的实现远非简单。本文重点介绍基于共识的复制，以及它如何在分布式数据库中实现。

理解和共识

协商一致（又称分布式共识）涉及多个服务器就值达成一致。这是容错分布式系统中的一个基本问题。一旦服务器就某个值达成一致，该协议即为最终协议。典型的共识算法在其服务器的任何多数（即仲裁）可用时接受写请求；例如，一个由5台服务器组成的集群可以继续接受写入，即使2台服务器出现故障。如果更多服务器失败，它们将停止接受任何新的写请求。这也意味着剩余可用服务器中的值不会更改，并且读取请求将继续使用正确的值。最终结果是一个高度一致的系统。协商一致的应用示例包括是否将事务提交到数据库，同意领导者的身份，状态机复制和原子广播。

共识协议可以大致分为两类：基于领导者和无领导者。Paxos和Raft是两种最常用的基于领导者的共识协议，其中数据更新和复制任务由“领导者”处理。多年来，强一致性分布式数据库已经标准化到这些协议之一。无领导者共识协议较难实现，但比基于领导者的协议具有更高的可用性。无领导者协议的应用可以在区块链分布式账本中找到。鉴于本文的重点是一致性的分布式数据库，这些数据库通常依赖于基于领导者的协议，我们将从这里开始深入回顾Paxos和Raft。

Paxos

paxos

Paxos算法首先由图灵奖获得者莱斯利·兰波特 Leslie Lamport 1990年以古希腊帕克斯岛议会为例描述。给定希腊神话背景和印第安纳·琼斯风格的主角，一开始没有认真对待。然而，它最终于1998年发表。人们继续感到难以理解，这促使兰波特在2001发表了Paxos变得简单，从那时以来它一直被认为是分布式系统的开创性论文之一。

Paxos的核心是一个三阶段提交协议，允许参与者在一段时间后放弃其他停滞的参与者。它通过参与者在协议中的角色描述参与者的行为：客户、接受者、提议者、学习者和领导者（又称杰出提议者）。许多参与者可能认为他们是领导者，但协议只有在其中一人当选的情况下才能保证进展。这基本上成为协议的第一阶段，如下图所示。

Paxos作为3PC协议（来源）

谷歌的Chubby分布式锁服务是被引用最多的Paxos实现之一，因为它在Google内部的广泛使用。使用Paxos复制的分布式数据库的例子有谷歌的Spanner和苹果的FoundationDB。

Paxos的一个最大问题是，即使在这么多年的实践之后，仍然很难理解和正确实现。事实上，Paxos已经发展成为一系列协议，因此可以引入新的权衡，简化实现。谷歌2006年的论文Paxos实现——工程视角揭示了这个问题。

“尽管该领域已有文献，但建立这样一个数据库（基于Paxos）并不简单。”

Raft

Raft由斯坦福大学研究人员于2013年首次提出，是一种共识算法，专门设计用于替代Paxos。通过逻辑分离，它比Paxos更容易理解，也形式上证明是安全的。逻辑分离源于这样一个事实，即Raft使领导者选举成为领导者可以复制数据之前的一个独立和强制性步骤，而Paxos实现是使领导者选举过程成为通过数据复制达成一致的隐含结果。

分离领导人选举允许轻松地动态更改成员资格-由于公共云，服务器的添加和删除现在比以往任何时候都更重要，只需重新运行领导人选举即可。此外，在没有任何计划外故障或计划成员更改的情况下，可以完全跳过领导人选举步骤。请注意，只要发生此类更改，即使没有新的写入进入系统，领导者选举步骤也是自动的。最后，Raft施加了限制，即只有拥有最新数据的服务器才能成为领导者。这些优化从根本上简化了一系列领导层变化可能导致数据差异的边缘情况，但折衷是，Raft中的领导层选举可能比Paxos中的领导选举更复杂。

实战Raft（来源）

Raft目前大约有100个开源实现(而且还在继续增加)，是当今在现代分布式系统中实现一致性的事实标准。流行的实现包括etcd和 consul。下一代分布式数据库，如YugabyteDB、CockroachDB和TiDB，使用Raft进行领导人选举和数据复制。其他数据库，如MongoDB和InfluxDB，部分使用Raft。MongoDB在副本集中的领导者选举从v3.4开始基于Raft，但数据复制仍然是异步的（辅助成员定期从副本集中的主成员中提取）。InfluxDB使用Raft实现其元数据节点的高可用性，同时对实际数据节点使用简单的非一致复制（见下一节）。

Paxos/Raft与非共识复制协议

分布式数据库中的一个设计最佳实践是，Paxos和Raft应用于单个分片级别，而不是数据库中的所有数据。这意味着（不同的分片）领导者不在单个服务器上，而是分布在所有服务器上。Paxos/Raft的一个常见替代方案是非共识（又称点对点）复制协议，如第一代NoSQL数据库使用的协议，如Amazon DynamoDB、Apache Cassandra、Couchbase和InfluxDB。在这种情况下，分片的每个副本都被同等对待，因此可以接受写请求。根据配置的一致性级别，进行写入的复制副本将决定是同步还是异步更新其他复制副本。这种方法的挑战在于，在两个不同副本上对同一记录的并发写入被认为是完全有效的，并且最终值必须使用启发式非确定性的方法（如最后写胜出(LWW)和无冲突复制数据类型（CRDT）决定。此类系统被认为是最终一致的（因为副本可能不同意最终值），并且容易在发生故障时丢失数据。

总结

基于共识的复制已成为构建弹性强、一致性强的分布式系统的关键。虽然Paxos多年来已经发展成为一系列具有各种权衡的协议，但它的实现仍然很复杂。Raft已经成为Paxos的主要替代品，因为它专注于可理解性而不牺牲性能和正确性。分布式数据库越来越依赖Raft共识协议来满足其基本复制需求。在将来的一篇博文中，我们将回顾YugabyteDB如何使用Raft进行领导者选举和数据复制。