开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第21天，点击查看活动详情

[论文阅读]一致性现代分布式数据库系统设计中的权衡因素（三）

在一致性、可用性和延迟之间存在着一个基本的权衡，为了实现最高级别的可用性，DDBS必须在广域网上复制数据。也即是说，为了可用性，必须得复制数据，一旦我们有复制的行为，就产生了一致性vs延迟的权衡了。CAP并没有讨论这一权衡，所以这也是本文的意义所在，我们必须知道在复制系统中，我们得到了什么，失去了什么。

本文继续研究当我们讨论复制时，我们在关注什么？

数据复制有很多策略：

同时向所有副本发送数据更新

首先将数据更新发送到一个商定的地点，如master，而后同步到其他副本｛同步地、异步地复制｝

若在广域网上复制数据，当我们想得到一致性，那么我们将付出延迟的代价。

本文接着介绍了Dynamo、Cassandra和Riak如何复制数据，妥协、权衡。他们都使用WRN可调一致性。先写到master，然后同步传播到W个节点，而读的时候，读取R个节点，R+W通常<N。

PACELC是本文最终引出的一个新定理，通过将CAP改写为PACELC（发音为 "pass-elk"），可以更完整地描绘DDBS的潜在一致性权衡空间：如果有分区（P），系统如何权衡可用性和一致性（A和C）；否则（E），当系统在没有分区时正常运行，系统如何权衡延迟（L）和一致性（C）？请注意，延迟/一致性权衡（ELC）只适用于复制数据的系统。否则，系统在任何类型的故障或过载节点时都会出现可用性问题。因为这种问题只是极端延迟的实例，ELC权衡的延迟部分可以包括是否复制数据的选择。本文取材于耶鲁大学Abadi的一些博客和文章:www.cs.umd.edu/~abadi/pape…

数据复制

一旦DDBS进行数据复制，就会出现一致性和延迟之间的权衡。这是因为实现数据复制只有三种选择：系统同时向所有副本发送数据更新，先向商定的主节点发送，或者先向单个（任意的）节点发送。系统可以用不同的方式实现这些情况；但是，每一种实现方式都有一个一致性/延迟的权衡。

(1) 同时向所有副本发送数据更新

如果更新没有首先通过预处理层或其他协议，复制的分歧--明显的缺乏一致性--可能会随之而来（假设多个更新同时提交给系统，例如，来自不同的客户），因为每个复制可能选择不同的顺序来应用更新。(即使所有的更新都是互换的--这样每个副本最终都会变得一致，尽管副本有可能以不同的顺序应用更新--吉尔伯特和林奇对一致性的严格定义7仍然不成立。然而，广义的Paxos10可以在单次往返中提供一致的复制）。

另一方面，如果更新首先通过一个预处理层，或者所有参与写入的节点使用一个协议协议来决定操作的顺序，那么就有可能确保所有副本在处理更新的顺序上达成一致。然而，这导致了几个延迟增加的来源。在协议协议的情况下，协议本身就是延迟的额外来源。

在预处理器的情况下，有两个延迟的来源。首先，通过一个额外的系统组件（预处理器）路由更新会增加延迟。第二，预处理器由多台机器或一台机器组成。在前一种情况下，需要一个协议来决定各机器的操作顺序。在后一种情况下，系统强迫所有的更新，无论它们是在哪里启动的--可能是在世界的任何地方--都要全部路由到单一的预处理器，即使另一个数据副本离更新启动位置更近。

(2) 首先将数据更新发送到一个商定的地点 我将把这个商定的位置称为 "主节点"（不同的数据项可以有不同的主节点）。这个主节点解决所有更新数据项的请求，而它选择执行这些更新的顺序决定了所有副本执行更新的顺序。在主节点解决了更新后，它把它们复制到所有的副本位置。

一旦DDBS复制数据，就会出现一致性和延迟之间的权衡

有三种复制选项。

a. 复制是同步的：主节点等到所有的更新都到了副本中。这确保了副本保持一致，但独立实体之间的同步行动，特别是在广域网上的同步行动，会增加延迟，因为这些实体之间需要重新传递信息，而延迟是由最慢的实体限制。

b. 复制是异步的：系统将更新视为在其被复制之前已经完成。通常情况下，在更新的发起者知道它已经完成之前，更新至少已经到了稳定的存储位置（以防主节点发生故障），但不能保证系统已经传播了更新。在这种情况下，一致性/延迟的权衡取决于系统如何处理读取的问题。

i. 如果系统将所有的读数路由到主节点并从那里提供服务，那么一致性就不会降低。然而，这种方法有两个延迟问题。

即使在读取请求发起者附近有一个副本，系统仍然必须将请求路由到主节点，而主节点在物理上可能更远。
如果主节点因其他请求而超载或发生故障，则没有选择从不同的节点提供读取服务。相反，该请求必须等待主节点变得空闲或恢复。换句话说，缺乏负载平衡选项会增加延迟的可能性。

ii.如果系统可以从任何节点提供读取服务，那么读取延迟就会好很多，但这也会导致对同一数据项的读取不一致，因为当系统还在传播更新时，不同的位置有不同的数据项版本，它可以将读取发送到这些位置中的任何一个。尽管减少的一致性水平可以通过跟踪更新序列号并使用它们来实现顺序/时间线一致性或读你写的一致性来约束，但这些都是减少的一致性选项。此外，如果写操作的主节点在地理上远离写请求者，那么写延迟就会很高。

c.(a)和(b)的组合是可能的：系统以同步方式向某些子集的复制体发送更新，而其余的则以异步方式发送。

对于广域网上的数据复制，没有办法绕过一致性/延迟的权衡。

在这种情况下，延迟的权衡再次由系统处理读取的方式决定。

i. 如果它将读取路由到至少一个已经同步更新的节点--例如，当法定人数协议中的R+W>N时，其中R是参与同步读取的节点数，W是参与同步写入的节点数，N是复制的数量--那么一致性可以被保留。然而，(a)、(b)(i)(1)和(b)(i)(2)的延迟问题都存在，尽管程度较轻，因为参与同步的节点数量较少，而且不止一个节点有可能提供读取请求。

ii. 如果系统有可能从没有被同步更新的节点提供读取服务，例如，当R + W ≤ N时，那么不一致的读取是可能的，如(b)(ii)。

从技术上讲，仅仅使用一个法定人数协议并不足以保证吉尔伯特和林奇所定义的一致性水平。然而，为确保完全的一致性11所需的协议添加在这里并不重要。即使没有这些补充，延迟已经是法定人数协议中固有的了。

(3) 首先将数据更新发送到一个任意的位置

系统在该位置执行更新，然后将其传播到其他副本。区别在于这种情况和(2)之间的区别是，系统为一个特定的数据项发送更新的位置并不总是相同。例如，一个特定数据项的两个不同的更新可以同时在两个不同的地点启动。

一致性/延迟的权衡又取决于两个选项。

a. 如果复制是同步的，那么(2)(a)的延迟问题就存在。此外，系统可能会产生额外的延迟，以检测和解决在两个不同地点启动的对同一数据项的同时更新的情况。

b. 如果复制是异步的，那么就会出现类似于（1）和（2）（b）的一致性问题。

权衡的例子

无论DDBS如何复制数据，显然它必须在一致性和延迟之间进行权衡。对于精心控制的短距离复制，存在诸如(2)(a)这样的合理选择，因为本地数据中心的网络通信延迟很小；但是，对于广域网上的复制，没有办法绕过一致性/延迟的权衡。

为了更全面地理解这种权衡，考虑一下为极高可用性而设计的四个DDBS--ynamo、Cassandra、PNUTS和Riak--是如何复制数据的。由于这些系统是为与活跃的网络客户进行低延迟交互而设计的，因此每一个系统都牺牲了一致性来改善延迟。

Dynamo、Cassandra和Riak使用（2）（c）和（3）的组合。特别是，系统向同一节点发送更新，然后将这些更新同步传播到其他W个节点--即情况(2)(c)。系统向R个节点同步发送读数，R+W通常被设定为小于或等于N的数字，导致读数不一致的可能性。然而，系统并不总是为某一特定数据项向同一节点发送更新--例如，这可能发生在各种故障情况下，或由于负载均衡器的重新路由。这就导致了（3）中描述的情况和潜在的更大的一致性缺陷。PNUTS使用选项

(2)( b)(ii)，在降低一致性的情况下实现出色的延迟。

Jun Rao, Eugene Shekita, and Sandeep Tata12最近的一项研究为这些系统的基线实现中的一致性/延迟权衡提供了进一步的证据。研究人员通过实验评估了Cas- sandra的一致性/延迟权衡中的两个选项。第一个选项，"弱读"，允许系统从任何副本中读取数据，即使该副本没有收到一个数据项的所有突出更新。第二个选项，"法定人数读取"，要求系统在读取数据之前明确地检查多个副本的不一致性。这种情况下第二种方案明显增加了一致性，但相对于第一种方案来说，要付出额外的延迟。这两个选项之间的延迟差异可能是4倍或更多。

Hiroshi Wada及其同事的另一项研究13似乎与这个结果相矛盾。这些研究人员发现，相对于默认的（潜在的不一致的）读取选项，在SimpleDB中请求一致的读取并没有明显地增加延迟。然而，研究人员在单一的亚马逊地区（美西）进行了这些实验，他们推测SimpleDB使用了主从复制，如果复制发生在较短的距离内，就有可能以适度的延迟成本实现。特别是，Wada和他的同事得出结论，SimpleDB强制所有一致的读取都要到负责写相同数据的主站去。只要读取请求来自物理上接近主站的位置，只要主站没有过载，那么一致读取的额外延迟就不明显（这两个条件在他们的实验中都是真的)。

如果SimpleDB在亚马逊地区之间进行了数据复制，并且读取请求来自于与主站位置不同的地区，那么一致读取的延迟成本就会更加明显。即使没有跨区域复制（SimpleDB目前不支持跨区域复制），亚马逊官方文档也警告用户一致读取的延迟增加和吞吐量减少。

所有四个DDBS都允许用户改变默认参数，以增加一致性换取更差的延迟--例如，在法定人数型系统中，使R+W多于N。然而，即使在没有网络分区的情况下，在正常的系统运行中也会出现一致性/延迟的权衡。如果在广域网上有数据复制，这种权衡就会被放大。显而易见的结论是，一致性的降低可归因于运行时间的延迟，而不是CAP。

PNUTS提供了最清楚的证据，表明CAP不是这些系统中一致性水平降低的主要原因。在PNUTS中，一个主节点拥有每个数据项。系统将该项目的更新发送到主节点，然后通过广域网将这些更新异步传播给副本。PNUTS可以为任何副本的读取提供服务，这使得该系统属于(2)(b)(ii)类：它减少了一致性以达到更好的延迟。然而，在网络分区的情况下，主节点在少数分区内变得不可用，系统通过去错使数据项不可用，无法更新。换句话说，PNUTS的默认配置实际上是CP：在分区的情况下，系统选择一致性而不是可用性，以避免解决在不同主节点发起的冲突-ing更新的问题。

因此，选择减少基线情况下的一致性，更明显的是归因于连续的与CAP中的一致性/延迟权衡相比，只有在网络分区时才会出现一致性/可用性权衡。当然，PNUTS在基线情况下缺乏一致性，在网络分区情况下也是有帮助的，因为在不可用的分区中掌握的数据仍然可以被读取。可以说，CAP对其他三个系统的影响更大。Dynamo、Cassandra和Riak在网络分区的情况下会更全面地切换到数据复制选项（3），并使用特殊的调和代码处理由此产生的一致性问题，该代码在检测到复制分歧时运行。因此，我们有理由认为这些系统在设计时就考虑到了网络分裂的可能性。因为这些是AP系统，所以调和代码和能力

忽视复制系统的一致性*延迟权衡是一个重大疏忽，因为它在系统运行过程中一直存在。

从一开始，切换到(3)的灵活性就被植入了代码中。然而，一旦有了这些代码，再利用一些一致性的灵活性来选择基线一致性/延迟权衡中的某一点也是很方便的。这个论点比声称这些系统的设计者完全因为CAP而选择降低一致性（忽略了延迟因素）更符合逻辑。总之，CAP只是现代DDBS降低一致性的两个主要原因之一。忽视复制系统的一致性/延迟权衡是一个重大的疏忽，因为它在系统运行过程中一直存在，而CAP只在网络分区这种可以说是罕见的情况下相关。事实上，前者的权衡可能更有影响力，因为它对系统的基线操作有更直接的影响。

PACELC

通过将CAP改写为PACELC（发音为 "pass-elk"），可以更完整地描绘DDBS的潜在一致性权衡空间：如果有分区（P），系统如何权衡可用性和一致性（A和C）；否则（E），当系统在没有分区时正常运行，系统如何权衡延迟（L）和一致性（C）？请注意，延迟/一致性权衡（ELC）只适用于复制数据的系统。否则，系统在任何类型的故障或过载节点时都会出现可用性问题。因为这种问题只是极端延迟的实例，ELC权衡的延迟部分可以包括是否复制数据的选择。

Dynamo、Cassandra和Riak的默认版本是PA/EL系统：如果发生分区，它们会为了可用性而放弃一致性，在正常运行情况下，它们会为了降低延迟而放弃一致性。放弃PACELC中的两个C使设计更简单；一旦系统被配置为处理不一致，为了可用性和低延迟而放弃一致性是合理的。然而，这些系统有用户可调整的设置来改变ELC的权衡--例如，通过增加R + W，他们在牺牲延迟的情况下获得更多的一致性（尽管他们不能实现Gilbert和Lynch定义的完全一致性，即使R + W > N）。

VoltDB/H-Store和Mega-store等完全ACID系统是PC/EC：它们拒绝放弃一致性，并将支付可用性和延迟成本来实现它。BigTable以及HBase等相关系统也是PC/EC。

MongoDB可以被归类为一个PA/EC系统。在基线情况下，系统保证读和写是一致的。然而，MongoDB使用了数据复制选项（2），如果主节点发生故障或与系统的其他部分分区，它将所有已经发送到主节点但尚未复制的写内容存储在本地回滚目录中。同时，系统的其他部分会选出一个新的主节点，以保持对读和写的可用性。因此，旧主站的状态和新主站的状态变得不一致，直到系统修复故障并使用回滚目录来调和状态，这在今天是一个手动过程。(从技术上讲，当一个分区发生时，根据CAP对可用性的定义，MongoDB是不可用的，因为少数分区是不可用的。然而，在PACELC的背景下，由于分区引起的一致性问题多于可用性问题，MongoDB可以被归类为PA/EC系统）。

PNUTS是一个PC/EL系统。在正常操作中，它为了延迟而放弃了一致性；但是，如果发生了分区，它就用可用性来换取一致性。这确实有些令人困惑：根据PACELC，PNUTS在网络分区时似乎变得更加一致。然而，PC/EL不应该被这样解释。PC并不表明系统是完全一致的；相反，它表明当网络分区发生时，系统不会将一致性降低到超过基线一致性水平--相反，它会降低可用性。

构建分布式数据库系统所涉及的权衡是复杂的，无论是CAP还是PACELC都无法解释所有的问题。尽管如此，将一致性/延迟的权衡纳入现代DDBS的设计考虑中是非常重要的，足以让我们把这个权衡更多的放在架构的最前沿。