PDF不要满足于最终一致性
低延迟地理复制存储的更强属性
Wyatt Lloyd，Facebook；Michael J. Freedman，普林斯顿大学；Michael Kaminsky，英特尔实验室；David G. Andersen，卡内基梅隆大学
地理复制存储在多个地理位置不同的位置提供相同数据的副本。例如，Facebook将其数据（个人资料、好友列表、点赞等）地理复制到美国东海岸和西海岸以及欧洲的数据中心。在每个数据中心，一个由独立 Web 服务器组成的层级接受浏览器请求，然后通过从存储系统读取和写入数据来处理这些请求，如图 1 所示。
地理复制为 Web 服务带来两个关键优势：容错能力和低延迟。它通过冗余提供容错能力：如果一个数据中心发生故障，其他数据中心可以继续提供服务。它通过邻近性提供低延迟：可以将客户端定向到附近的数据中心并由其提供服务，以避免与跨国或环球通信相关的光速延迟。
然而，地理复制也带来挑战。著名的 CAP 定理，由 Brewer1 提出猜想，由 Gilbert 和 Lynch7 证明，表明不可能创建一个系统，该系统具有强一致性，始终可用于读取和写入，并且能够在网络分区期间继续运行。这些属性中的每一个都是非常理想的。强一致性——更正式地称为线性一致性——使编程更容易。可用性确保前端 Web 服务器始终可以响应客户端请求。分区容错性确保系统即使在数据中心无法相互通信时也能继续运行。面对最多选择这两个属性的选择，许多系统5,8,16 已选择牺牲强一致性以确保可用性和分区容错性。其他系统——例如，处理资金的系统——牺牲可用性和/或分区容错性以实现构建在其之上的应用程序所需的强一致性。4,15
然而，前一种选择可用性和分区容错性并不令人惊讶，因为它还使存储系统能够提供低延迟——定义为读取和写入的延迟小于两个最远数据中心之间光速延迟的一半。一个早于 CAP 定理 14 年的证明10 表明，不可能同时保证低延迟和提供强一致性。前端 Web 服务器可能多次从存储系统读取或写入数据以响应单个请求；因此，存储系统中的低延迟对于实现快速页面加载时间至关重要，而快速页面加载时间与用户对服务的参与度以及收入相关。始终可用且分区容错的系统可以通过在本地数据中心服务所有操作来提供毫秒级的低延迟。强一致性系统必须联系远程数据中心进行读取和/或写入，这需要数百毫秒。
因此，牺牲强一致性的系统获得了丰厚的回报。它们可以始终可用，保证低延迟的响应，并提供分区容错性。在 COPS（顺序保持服务器集群）11 中，为我们关于该主题的原始工作而开发，我们创造了术语 ALPS 来表示提供这四个属性的系统——始终可用、低延迟和分区容错性——以及另一个属性：可扩展性。可扩展性意味着向每个数据中心添加存储服务器会成比例地增加存储容量和吞吐量。可扩展性对于现代系统至关重要，因为数据增长得太大了，无法由单台机器存储或服务。
问题仍然是 ALPS 系统可以提供什么一致性属性。在回答这个问题之前，让我们考虑现有 ALPS 系统提供的一致性。对于 Amazon 的 Dynamo、LinkedIn 的 Project Voldemort 和 Facebook/Apache 的 Cassandra 等系统，答案是最终一致性。
最终一致性
最终一致性是一个被广泛使用的术语，可以有很多含义。在这里，它被定义为所有声称提供它的系统提供的最强属性：即，对一个数据中心的写入最终将出现在其他数据中心，并且如果所有数据中心都收到了相同的写入集，它们将对所有数据具有相同的值。
将其与强一致性（线性一致性）定义的一部分进行对比：系统中所有操作都存在总顺序。这使得强一致性存储系统的编程变得简单，或者至少更简单：它的行为像一个单一实体。最终一致性没有说明操作的顺序。这意味着不同的数据中心可以反映任意不同的操作集。例如，如果连接到西海岸数据中心的人设置 A=1、B=2 和 C=3，那么连接到东海岸数据中心的其他人可能只看到 B=2（看不到 A=1 或 C=3），而连接到欧洲数据中心的其他人可能只看到 C=3（看不到 A=1 或 B=2）。这使得最终一致性存储的编程变得复杂：操作可能乱序出现。
乱序到达会导致最终一致性系统中出现许多潜在的异常。以下是社交网络的一些示例
图 2 显示，在西海岸数据中心，Alice 发帖，她评论，然后 Bob 评论。然而，在东海岸数据中心，Alice 的评论尚未出现，这使 Bob 看起来不太友善。图 3 显示，在西海岸数据中心，一位研究生在接受导师作为朋友之前仔细删除了不雅照片。不幸的是，在东海岸数据中心，好友接受出现在照片删除之前，从而使导师能够看到这些照片。3
图 4 显示，在西海岸数据中心，Alice 上传照片，创建相册，然后将照片添加到相册，但在东海岸数据中心，操作乱序出现，她的照片最终没有出现在相册中。最后，在图 5 中，Cindy 和 Dave 在他们的联合银行账户中拥有 1,000 美元。同时，Dave 从东海岸数据中心提取了 1,000 美元，Cindy 从西海岸数据中心提取了 1,000 美元。一旦两个提款传播到每个数据中心，他们的账户就处于一致状态（-1,000 美元），但为时已晚，无法阻止这对淘气夫妇带着他们不义之财逃之夭夭。
最终一致性是唯一的选择吗？
鉴于理论结果表明 ALPS 属性与强一致性不兼容，我们是否必须满足于最终一致性？我们是否会被最终一致性带来的所有异常所困扰？不！
我们的研究系统 COPS11 和 Eiger12 推动了 ALPS 系统可以提供的属性。特别是，它们提供因果一致性而不是最终一致性，这可以防止前三个异常。（图 5 中的第四个异常在接受每个位置的写入并保证低延迟的系统中是不可避免的。）此外，它们还提供有限形式的只读和只写事务，允许程序员一致地读取或写入分布在数据中心中许多不同机器上的数据。
因果一致性
因果一致性确保操作按照用户直观期望的顺序出现。更准确地说，它强制执行与潜在因果关系概念一致的操作的部分顺序。如果操作 A 在操作 B 之前发生，那么任何看到操作 B 的数据中心都必须首先看到操作 A。
三个规则定义了潜在的因果关系：9
1. 执行线程。 如果 a 和 b 是单个执行线程中的两个操作，则如果操作 a 在操作 b 之前发生，则 a -> b。
2. 读取自。 如果 a 是写入操作，b 是读取操作，返回由 a 写入的值，则 a -> b。
3. 传递性。 对于操作 a、b 和 c，如果 a -> b 且 b -> c，则 a -> c。因此，操作之间的因果关系是前两条规则的传递闭包。
因果一致性确保操作以与这些规则一致的顺序出现。这让用户感到高兴，因为他们的操作以他们预期的顺序应用于所有地方。这让程序员感到高兴，因为他们不再需要考虑乱序操作。
因果一致性防止了我们前三个异常中的每一个，将它们变成了规律性。
规律性 1：没有遗漏的评论。
在西海岸数据中心，Alice 发帖，然后她和 Bob 评论
Op1 Alice：我把结婚戒指弄丢了。
Op2 Alice：唷，楼上找到了。
Op3 [Bob 读取 Alice 的帖子和评论。]
Op4 Bob：我很高兴听到这个。
根据执行线程规则，Op1 -> Op2；根据读取自规则，Op2 -> Op3；根据执行线程规则，Op3 -> Op4。
写入操作仅传播并应用于其他数据中心，因此强制执行的完整因果顺序是 Op1 -> Op2 -> Op4。
现在，在东海岸数据中心，操作只能以与因果关系一致的顺序出现。因此
Op1 Alice：我把结婚戒指弄丢了。
然后
Op1 Alice：我把结婚戒指弄丢了。
Op2 Alice：唷，楼上找到了。
然后
Op1 Alice：我把结婚戒指弄丢了。
Op2 Alice：唷，楼上找到了。
Op4 Bob：我很高兴听到这个。
但绝不会出现使 Bob 看起来不友善的异常。
规律性 2：没有泄露的照片
在西海岸数据中心，一位研究生在接受导师作为朋友之前仔细删除了不雅照片
Op1 [学生删除不雅照片。]
Op2 [学生接受导师作为朋友。]
根据执行线程规则，Op1 -> Op2。
现在，在东海岸数据中心，操作只能以与因果关系一致的顺序出现，即
[学生删除不雅照片。]
然后
[学生删除不雅照片。]
[学生接受导师作为朋友。]
但绝不会出现将照片泄露给学生导师的异常。
规律性 3：正常的相册
在西海岸数据中心，Alice 上传照片，然后将它们添加到她的 2013 年夏季相册
Op1 [Alice 上传照片。]
Op2 [Alice 创建相册。]
Op3 [Alice 将照片添加到相册。]
根据执行线程规则，Op1 -> Op2 -> Op3。
现在，在东海岸数据中心，操作只能以与因果关系一致的顺序出现
Op1 [Alice 上传照片。]
然后
Op1 [Alice 上传照片。]
Op2 [Alice 创建相册。]
然后
Op1 [Alice 上传照片。]
Op2 [Alice 创建相册。]
Op3 [Alice 将照片添加到相册。]
但绝不会以导致空相册或使程序员必须考虑的事情复杂化的不同顺序出现。
因果一致性不能做什么
异常 4 代表了因果一致性的主要限制：它无法强制执行全局不变性。异常 4 具有一个隐式的全局不变性——银行账户不能低于 0 美元——这被违反了。此不变性无法在 ALPS 系统中强制执行。可用性决定了操作必须完成，而低延迟确保它们比数据中心之间通信所需的时间更快。因此，操作必须在数据中心可以通信并发现并发提款之前返回。
然而，真正的全局不变性非常罕见。电子商务网站，看起来库存不能低于 0，但实际上有缺货订单系统来处理这种情况。即使是一些银行也不强制执行全局 0 美元不变性，最近发生在 ATM 上的并发提款攻击从仅 12 个账号中提取了 4000 万美元，就证明了这一点。14
因果一致性的另一个限制也源于并发操作的可能性。程序员必须决定如何处理对不同数据中心中相同数据的并发写入操作。一种常见的策略是后写胜出规则，其中一个并发更新会覆盖另一个。例如，社交网络用户只能有一个生日。然而，某些情况需要更谨慎的方法。考虑这样一种情况，Alice 有两个待处理的好友请求在不同的数据中心并发接受。每个接受的好友请求都应将 Alice 的好友计数增加一。然而，使用后写胜出规则，其中一个增量将覆盖另一个。相反，必须合并这两个增量才能将 Alice 的好友总数增加两个。对于因果一致性存储（与最终一致性存储一样），程序员必须确定后写胜出规则是否足够，或者他们是否必须编写一个特殊的函数来合并并发更新。
因果一致性的最终限制是它无法看到或强制执行系统外部的因果关系。经典的例子是跨国电话。如果西海岸的 Alice 更新了她的个人资料，给东海岸的 Bob 打电话，然后 Bob 更新了他的个人资料，系统将看不到这两个更新之间的因果关系，也不会强制执行它们之间的任何顺序。
提供因果一致性
在较高层次上，我们的系统 COPS 和 Eiger 通过客户端库捕获因果关系，然后在将写入复制到其他数据中心时强制执行观察到的顺序。通过延迟写入的应用直到所有因果关系之前的操作都已应用，来强制执行顺序。此延迟仅在远程数据中心是必要的；所有因果关系之前的操作都已在接受写入的数据中心应用。跟踪因果关系的客户端库位于每个数据中心中的 Web 服务器和存储层之间。（在当前的实现中，它位于 Web 服务器上。）通过客户端库 API 中的特殊 actor_id 字段来识别各个客户端，该字段允许区分同一 Web 服务器上不同用户的操作。例如，在社交网络中，唯一的用户名 ID 可以用作 actor_id。
让我们首先描述一个提供因果关系的低效系统，然后解释如何改进它以使其高效。
我们的系统通过仅跟踪和强制执行写入操作之间的顺序来运行。读取操作在不同客户端的写入操作之间建立因果链接，但它们不会复制到其他数据中心，因此不需要在其上强制执行顺序。例如，在异常/规律性 1 中，Bob 读取（Op3）Alice 的帖子（Op1）和评论（Op2）创建了因果链接，该链接将 Bob 后来的评论（Op4）排序在 Alice 的帖子和评论之后。两个写入操作之间的因果链接称为依赖关系——后面的操作依赖于前面的操作。
图 6 显示了因果关系图和依赖关系图之间的关系。依赖关系是一小段元数据，唯一标识一个写入操作。它有两个字段：一个键，它是写入更新的数据位置；以及一个时间戳，它是最初写入它的数据中心中服务器的逻辑时钟分配的全局唯一逻辑时间戳。图 6 说明了 (a) 一组示例操作；(b) 它们之间的因果关系图；(c) 相应的依赖关系图；以及 (d) 列出依赖关系的表，其中单跳依赖关系以粗体显示。
在最初的设计中，客户端库跟踪每个客户端的完整依赖关系集。跟踪客户端的所有依赖关系需要跟踪三组写入操作
1. 客户端的所有先前写入操作，因为执行线程规则。
2. 所有写入客户端读取的值的操作，因为读取自规则。
3. 1 和 2 中的操作所依赖的所有操作，因为传递性规则。
跟踪第一组操作很简单：服务器将分配给每个写入的唯一时间戳返回给客户端库，然后客户端库添加对该写入的依赖关系。跟踪第二组操作也很简单：服务器在响应读取时返回写入值的写入的时间戳，然后客户端库添加对该写入的依赖关系。第三组操作有点棘手：它要求每个写入都带有其所有依赖关系，并且这些依赖关系与值一起存储，在读取该值时返回，然后由客户端库添加到读取器的依赖关系集中。
由于每个客户端的完整依赖关系集都存储在其客户端库中，因此所有这些依赖关系都可以附加到客户端发出的每个写入操作。现在，当远程数据中心中的服务器收到带有其完整依赖关系集的写入时，它会阻止写入并验证每个依赖关系是否得到满足。阻止这些复制的写入操作是可以接受的，因为它们不是面向客户端的，并且不会阻止读取它们更新的任何数据。在这里，我们明确选择延迟这些写入操作，直到它们可以以正确的顺序出现，如图 7 所示。Bglad 的依赖关系检查不会返回，直到 Afound 应用于东海岸之后，这确保了 Bob 永远不会被误解。
到目前为止描述的系统提供了因果一致性和所有 ALPS 属性。因果一致性通过使用客户端库跟踪因果关系并在复制的写入上使用依赖关系检查来强制执行因果顺序来提供。可用性和分区容错性通过将所有操作保持在本地数据中心内部来确保。低延迟通过保持所有操作本地、非阻塞和无锁来保证。最后，完全分散的设计确保了系统具有可扩展性。
然而，当前的系统效率低下。它有大量的依赖关系元数据随写入操作一起传输，并且有大量的依赖关系检查要在应用它们之前执行。这两个因素都会从面向用户的操作中窃取吞吐量并降低系统的实用性。幸运的是，我们的系统可以利用因果关系图中固有的传递性来大幅减少必须跟踪和强制执行的依赖关系。正在跟踪的依赖关系子集是单跳依赖关系，它们在因果关系图中具有指向当前操作的弧。（请注意，用图论术语来说，单跳依赖关系子集是操作的直接前驱集。）在图 6 中，单跳依赖关系以粗体显示。它们传递性地捕获了对操作的所有排序约束。特别是，因为所有其他依赖关系都至少被一个单跳依赖关系所依赖（根据定义），如果当前操作发生在单跳依赖关系之后，那么根据传递性，它也将发生在所有其他依赖关系之后。
有限事务
除了因果一致性之外，我们的系统还提供有限形式的事务。这些包括只读事务，它事务性地读取分布在数据中心中许多服务器上的数据，以及只写事务，它事务性地更新分布在数据中心中许多服务器上的数据。
这些有限事务是数据当前规模所必需的，并且变得复杂。许多服务的数据现在太大，无法放在单台机器上，而必须分布在许多机器上。由于数据驻留在许多机器上，因此提取数据的一致视图变得棘手。即使数据存储本身可能始终是一致的，客户端也可能提取不一致的视图，因为客户端的读取将由不同的服务器在不同的时间提供服务。不幸的是，这可能会重新引入最终一致性中固有的许多异常。例如，在图 8 中，在西海岸数据中心，一位研究生从导师那里删除了照片查看权限并上传了不雅照片。导师同时尝试查看学生的照片，但错误地看到了不雅照片。为了避免这些异常，必须将因果一致性从存储系统扩展到 Web 服务器，然后再扩展到服务用户。这可以使用只读事务来完成。
只读事务允许程序员事务性地读取分布在许多服务器上的数据，从而产生数据的一致视图。只读事务的接口很简单：数据位置列表。程序员不是为不同的数据位置发出许多单独的读取，而是为所有这些位置发出单个读取。这类似于批量处理这些操作，这样做通常是为了使调度读取更有效——除了它还确保结果是隔离的。
使用只读事务，异常 5 现在也可以转换为规律性。图 9 显示，使用只读事务，权限和照片被事务性地一起读取，产生如图所示的三个有效状态中的任何一个，但绝不会出现将不雅照片泄露给学生导师的异常。
提供只读事务
有许多技术可以确保对分布在许多机器上的数据位置进行隔离访问。其中最流行的包括 2PL（两阶段锁）、使用 TM（事务管理器）来安排读取应用的时间，以及使用 MVCC（多版本并发控制）维护数据的多个版本。前两种方法与 ALPS 属性相悖。所有形式的锁定，尤其是 2PL，都可能遇到已获取的锁，然后要么使操作失败（放弃可用性），要么阻止操作直到它可以获取锁（放弃低延迟）。TM 是一个集中式实体，将所有读取定向到它是一个抑制可扩展性的瓶颈。这留下了 MVCC，我们的方法可以被视为其特别激进的变体，这在我们的事务受到限制的情况下是可能的。
我们的只读事务算法背后的基本思想是，我们希望在单个逻辑时间读取整个分布式数据存储。（对于逻辑时间，系统中的每个节点都维护一个逻辑时钟，该时钟在每次事件发生时更新（例如，写入值或接收消息）。发送消息时，节点包括设置为其逻辑时钟 c 的时间戳 t；接收消息时，节点设置
您可以通过使用逻辑时间注释值来确定集合中的值是否彼此一致，逻辑时间是它们变为可见并被覆盖的时间。例如，在图 10 中，一致的集合包括 {A,J,X}、{B,K,X}、{B,K,Y}、{B,L,Y}，不一致的集合包括 {A,K,X}、{B,J,Y} 和 {C,L,X} 等。我们的服务器以这种方式注释值，并在将结果返回到客户端库时包含它们，以便它可以确定值是否相互一致。
我们的只读事务算法由客户端库运行，最多需要两轮并行读取。在第一轮中，客户端库并行发送对所有请求数据的请求。服务器响应其当前可见值和有效间隔，即写入该值的逻辑时间和服务器的当前逻辑时间。该值可能在未来的逻辑时间也有效，但保守地我们知道它至少在此间隔内有效。一旦客户端收到所有响应，它将通过检查其有效间隔中是否存在交集来确定所有值是否相互一致。如果存在交集——除非某些值与只读事务并发覆盖，否则几乎总是这种情况——那么客户端库知道这些值是一致的，并将它们返回给客户端。
如果有效间隔并非全部相交，则该过程将进入算法的第二轮。第二轮首先计算读取值的单个逻辑时间，称为有效时间。它的计算方法是选择一个时间，以确保数据的最新视图，而不是停留在旧的一致切片上，并且允许使用在第一轮中检索到的许多值。然后，客户端库为所有在有效时间没有有效值的数据发出第二轮并行读取。这些第二轮读取请求有效时间的数据值，服务器通过遍历值的旧版本来响应这些读取，直到找到在有效时间有效的版本。图 11 显示了第二轮的运行情况。图 11a 是在单轮中完成的只读事务，而图 11b 是需要第二轮的只读事务，并在有效时间 15 请求数据位置 1，并收到值 B 作为响应。
此只读事务算法专门设计用于维护所有 ALPS 属性并提供高性能。它是可用的，因为所有读取都请求当前值或旧值。它是低延迟的，因为它最多需要两轮非阻塞并行读取。它是分区容错的，因为所有读取都在本地数据中心内（假设分区仅发生在广域网中，而不是在本地数据中心中）。它是可扩展的，因为它是完全分散的。最后，它的性能很高，因为它通常只需要一轮并行读取，而在最坏的情况下只需要两轮读取。
我们之前关于 Eiger12 的工作更详细地介绍了如何选择有效时间、如何限制服务器端旧版本的存储以及也维护所有 ALPS 属性的只写事务算法。
因果一致性和有限事务的成本
在深入评估 Eiger 后，我们在此重现了我们最重要的两个结论性结果：Eiger 的吞吐量与最终一致性系统相比具有竞争力；并且它可以扩展到大型集群。
对于 Eiger 开销的一个实际观点，我们根据 Facebook 的生产 TAO（关联和对象）系统2 参数化了合成工作负载。然后，在华盛顿州和加利福尼亚州各拥有八台服务器的集群的实验中，我们将 Eiger 的吞吐量与最终一致性 Cassandra（Eiger 从其分叉而来）的吞吐量进行了比较。Cassandra 设置平均每秒实现了 23,657 次操作，触及 498,239 个数据位置。Eiger 设置，具有因果一致性并且所有不一致的批量操作都转换为读取或写入事务，平均每秒实现了 22,891 次操作，触及 480,904 个数据位置。此实验表明，对于这种真实世界的工作负载，Eiger 的因果一致性和更强的语义不会带来显着的开销。
为了证明 Eiger 的可扩展性，我们在 N 台客户端机器上运行了 Facebook TAO 工作负载，这些机器完全加载了一个 N 服务器集群，该集群正在将写入复制到另一个 N 服务器集群（即，N=128 实验涉及 384 台机器）。此实验在 PRObE 的 Kodiak 测试平台上运行6，该平台为 Emulab 提供了对数百台机器的独占访问权。图 12 显示了 Eiger 的吞吐量，其中 N 从 8 个服务器/集群扩展到 128 个服务器/集群。条形图显示了相对于八服务器集群吞吐量归一化的吞吐量。Eiger 随着服务器数量的增加而扩展；服务器数量每增加一倍，集群吞吐量平均增加 96%。
更多信息
更多信息可在我们关于 COPS11 和 Eiger12 的论文以及 Wyatt Lloyd 的论文13 中找到。Eiger 的代码可从 https://github.com/wlloyd/eiger 获取。
致谢
这项工作得到了美国国家科学基金会奖项 CSR-0953197 (CAREER)、CCF-0964474、CNS-1042537 (PRObE) 和 CNS-1042543 (PRObE) 以及英特尔公司通过英特尔云计算科学技术中心 (ISTC-CC) 的资助支持。
参考文献
1. Brewer, E. 2000. Towards robust distributed systems. In Proceedings of the 19th Annual Symposium on Principles of Distributed Computing.
2. Bronson, N., et al. 2013. TAO: Facebook's distributed data store for the social graph. In Proceedings of the Usenix Annual Technical Conference.
3. Cham, J. 2013. PhD Comics (June); http://www.phdcomics.com/comics.php?f=1592.
4. Corbett, J. C., Dean, J., Epstein, M., Fikes, A., Frost, C., Furman, J., Ghemawat, S., Gubarev, A., Heiser, C., Hochschild, P., Hsieh, W., Kanthak, S., Kogan, E., Li, H., Lloyd, A., Melnik, S., Mwaura, D., Nagle, D., Quinlan, S., Rao, R., Rolig, L., Saito, Y., Szymaniak, M., Taylor, C., Wang, R., Woodford, D. 2013. Spanner: Google's globally distributed database. Transactions on Computer Systems 31(3).
5. DeCandia, G., et al. 2007. Dynamo: Amazon's highly available key-value store. In Proceedings of the 21st Symposium on Operating Systems Principles: 205-220.
6. Gibson, G., Grider, G., Jacobson, A., Lloyd, W. 2013. PRObE: A thousand-node experimental cluster for computer systems research. Usenix ;login: 38(3).
7. Gilbert, S., Lynch, N. 2002. Brewer's conjecture and the feasibility of consistent, available, partition-tolerant Web services. SIGACT News 33(2): 51-59.
8. Lakshman, A., Malik, P. 2009. Cassandra—a decentralized structured storage system. In the 3rd SIGOPS International Workshop on Large-scale Distributed Systems and Middleware.
9. Lamport, L. 1978. 时间、时钟和分布式系统中事件的排序。 通讯 21(7): 558-565。
10. Lipton, R. J., Sandberg, J. S. 1988. PRAM：可扩展的共享内存。技术报告 TR-180-88。普林斯顿大学，计算机科学系。
11. Lloyd, W., Freedman, M. J., Kaminsky, M., Andersen, D. G. 2011. 不要满足于最终一致性：使用 COPS 为广域存储实现可扩展的因果一致性。在第 23 届操作系统原理研讨会会议记录中：401-416。
12. Lloyd, W., Freedman, M. J., Kaminsky, M., Andersen, D.G. 2013. 用于低延迟地理复制存储的更强语义。在第 10 届 Usenix 网络系统设计与实现会议会议记录中：313-328。
13. Lloyd, W. 2013. 用于低延迟地理复制存储的更强一致性和语义。博士论文，普林斯顿大学。
14. Santora, M. 2013. 数小时内，盗贼在 ATM 计划中盗取了 4500 万美元。纽约时报（5 月 9 日）。
15. Sovran, Y., Power, R., Aguilera, M. K., Li, J. 2011. 用于地理复制系统的事务存储。在第 23 届操作系统原理研讨会会议记录中：385-400。
16. Voldemort。2013; http://project-voldemort.com。
喜欢还是讨厌？请告诉我们
Wyatt Lloyd 是 Facebook 的博士后研究员，并将于 2014 年开始在南加州大学担任助理教授。他的研究兴趣包括大型网站、云计算和大数据架构背后的分布式系统和网络问题。他于 2013 年在普林斯顿大学获得博士学位，并于 2007 年在宾夕法尼亚州立大学获得计算机科学理学学士学位。
Michael J. Freedman 是普林斯顿大学计算机科学副教授，研究重点是分布式系统、网络和安全。最近的荣誉包括总统早期职业奖，以及通过国家科学基金会和海军研究办公室颁发的早期研究员奖、斯隆奖学金和 DARPA 计算机科学研究小组会员资格。
Michael Kaminsky 是英特尔实验室的资深研究科学家，也是卡内基梅隆大学计算机科学系的兼职教师。他是位于宾夕法尼亚州匹兹堡的英特尔云计算科学与技术中心的一员。他的研究兴趣包括分布式系统、操作系统和网络。
David G. Andersen 是卡内基梅隆大学计算机科学副教授。他在麻省理工学院完成了 S.M. 和博士学位，并拥有犹他大学的生物学和计算机科学理学学士学位。1995 年，他在犹他州盐湖城共同创立了一家互联网服务提供商。
© 2014 1542-7730/14/0300 $10.00
最初发表于 Queue vol. 12, no. 3—
在 数字图书馆 中评论本文
更多相关文章
Qian Li, Peter Kraft - 事务和无服务器天生一对
数据库支持的应用程序是无服务器计算令人兴奋的新领域。通过紧密集成应用程序执行和数据管理，事务性无服务器平台实现了许多在现有无服务器平台或基于服务器的部署中不可能实现的新功能。
Pat Helland - 任何其他的名称的身份
新兴的系统和协议既收紧又放松了我们对身份的概念，这很好！它们使完成工作变得更容易。REST、物联网、大数据和机器学习都围绕着有意保持灵活有时模糊的身份概念。身份概念是我们分布式系统的基本机制的基础，包括互换性、幂等性和不变性。
Raymond Blum, Betsy Beyer - 实现数字永恒
当今的信息时代正在为世界依赖的数据创造新的用途和新的管理方式。世界正在远离熟悉的物理人工制品，转向更接近其本质信息的新表示方式。我们需要流程来确保知识的完整性和可访问性，以保证历史将被了解和真实。
Graham Cormode - 数据草图
您是否曾经感到被无休止的信息流淹没？似乎源源不断的新电子邮件和短信需要持续关注，还有电话要接听、文章要阅读、敲门声要回应。将这些碎片拼凑在一起以跟踪重要的事情可能是一个真正的挑战。为了应对这一挑战，流数据处理模型越来越受欢迎。目标不再是捕获、存储和索引每一分钟的事件，而是快速处理每个观察结果，以便创建当前状态的摘要。
© 保留所有权利。