论文地址：SwiftCloud：容错地理复制集成到客户机-Zawirski等人。2013年

    数据存储在云中，演示在移动设备上，应用程序处理越来越分散在两者之间。随着移动设备的能力越来越强，我们希望利用越来越多的这种能力。在许多情况下，这两种方式都提供了更好的用户体验，而且在云资源方面的成本更低，您需要租用云资源来支持您的应用程序。

    将mbaas数据存储放在一起似乎相当简单：将REST API放在分布式键值存储或文档存储前面，就完成了！尤其是如果每个密钥属于一个用户（即用户对数据进行分区，而每个用户只访问自己的数据）。你会很快发现有更多的考虑因素需要考虑，例如：

    • 我们希望支持断开连接的使用，因此我们添加了设备上存储或缓存
    • 设备上的更新（可能在脱机时进行）需要同步返回到服务器
    • 我们正在从多用户计算设备转移到多设备用户，这将强制将服务器端更改复制回客户端，即使在“按用户存储”的情况下也是如此
    • 这意味着我们必须有一个处理并发更新和冲突的机制
    • 我们希望设备和云之间的通信尽可能节电
    • 我们可能需要使用透明的推送通知来更新设备状态

    今天的论文选择描述了一个名为SwiftCloud的系统，它提供了一种跨设备和云管理数据的事务性、地理复制和容错方法，使您可以在设备上做更多的事情。另外两件事你可能想知道就在前面：

    • 他们使用CRDTs，本文对CRDTs在移动应用程序设计中的应用做了很好的总结。（过去的经验表明，任何提到CRDTs的东西似乎都引起了#报纸读者的高度兴趣；）
    • 他们声称，与传统的地理复制技术相比，吞吐量和延迟都有一个数量级的提高。
    • 我们提出了一种集成客户端和服务器端存储的原则性方法。我们支持以客户机或服务器副本为目标的可合并且强一致的事务，并有效地提供对因果一致快照的访问。在存在基础结构故障时，客户机辅助的故障切换解决方案允许客户机执行立即恢复并无缝地访问一致的快照，而无需等待。我们在SwiftCloud中实现了这种方法，SwiftCloud是第一个将地理复制带到客户机的事务系统。

    SwiftCloud提供了一个事务性的“关键对象”API。SwiftCloud系统由一组复制每个对象的SwiftCloud数据中心（DC）组成。客户端节点缓存（并操作）对象的子集。客户端可以执行由事务划分的本地读取和更新操作序列，也可以请求执行服务器端事务。

    我们期望常见的操作将在客户机缓存中异步执行，并且存储（服务器端）事务和强一致性事务将很少见。

    事务模型被描述为“事务因果+一致性”：

    它提供了以下保证：每个事务读取一个因果一致的快照；事务的更新是原子的（全部或没有）和隔离的（没有并发事务观察到中间状态）；并发提交的更新不冲突。

    将因果一致性一直带到客户端是一个有趣的挑战，因为典型的方法是使用向量时钟，其大小与副本的数量成正比。如果每个客户端设备都有一个副本，那就不太好了…

    尽管将地理复制扩展到客户机似乎很自然，但它带来了两大挑战。第一种方法是为运行在客户机上的应用程序提供编程保证，以合理的成本在规模和变动下运行。最新的以DC为中心的存储系统提供事务，并结合对可合并对象因果一致性的支持。将这些保证扩展到客户机是有问题的，原因有很多：支持客户机节点因果关系的标准方法需要与副本数量成比例的向量时钟条目；对客户机和服务器副本的无缝访问需要仔细维护对象版本；客户端中的快速执行需要异步提交。我们开发的协议，有效地解决这些问题，尽管失败，通过结合一套新的技术…

    系统区分了两种不同类型的事务：可合并事务和经典事务。

    可合并事务只能用可交换操作更新对象并始终提交；经典的、不可合并事务可以执行非可交换操作，但在具有冲突更新的并发事务中，最多可以成功提交一个。

    本文的重点是对可合并事务的高效和容错支持，即具有与所有其他更新相互转换的更新的事务。可合并事务之间以及与不可合并事务之间相互转换，这允许在缓存中立即执行它们，在后台异步提交，并在失败情况下保持可用。

    可合并事务在可合并对象上操作：最后写入程序wins寄存器、多值寄存器、计数集（C集）和无冲突复制数据类型（CRDTs）。

    CRDTs封装了常见的并发性和复制复杂性，并允许在系统级一次性解决它们。但是，实际应用程序需要复杂的自定义对象或使用多个对象。前者是不切实际的，后者则提出了新的问题，缺乏跨对象的保障。我们的事务模型引入了简单的跨对象排序保证，并允许在应用程序中组合多个对象。第5节中的示例表明，对于许多应用程序，可合并事务可以表示工作负载的主要部分。为了获得更有力的保证，可以使用不可合并的事务。

    事务最终有两个标识符：orgin（在设备上）事务标识符（OTID）和全局事务标识符（GTID）。此机制用于帮助保持矢量时钟较小：

    全局提交的可合并事务（以及它生成的对象版本）可以通过其OTID和GTID进行标识。OTID确保惟一性，GTID允许在依赖向量中有效地引用事务。在某些失败的情况下，一个事务可能被分配多个gtid，但是正如下一节所解释的，它们被同等对待。我们的协议用矢量时钟编码整个节点（DC或scout）的因果状态。scout-DC拓扑结构、DC的小数量和静态数量以及DC中事务处理是可线性化的假设都有助于保持这些向量的小。这个非常紧凑的数据结构总结了整个过去的历史，即当前事务依赖的传递闭包。

    （对于上面引用的scout，请阅读“设备或服务器端代理”。）

    接下来，我们将很好地讨论客户机切换其连接的数据中心时的因果一致性考虑。Space使我无法在这里捕获它，但解决方案最终涉及到客户机和DC之间的协作，以恢复任何丢失的因果依赖关系。

    该团队构建了三个应用程序来评估他们的方法——一个社交网络应用程序、一个协作文档编辑应用程序和一个模拟在线书店的TPC-W基准测试的实现。这些配置部署有三个DCs，客户机分布在这些DCs附近的96台机器上。应用程序在FT、geo复制模式和非容错版本中进行了测试，同步更新到单个DC，并从那里异步传播到其他DC。

    我们对我们的协议进行了实验评估，并与经典的地理复制方法进行了比较。实验涉及两大洲的三个数据中心和数百个远程客户端。在足够的访问局部性下，与经典方法相比，SwiftCloud在响应时间和吞吐量方面都有了数量级的改进。这是因为，不仅读取（如果它们在缓存中命中），而且更新会毫不延迟地在客户端提交；服务器只需要异步存储和转发更新。虽然我们的容错方法延迟了传播，但过时读取的比例仍然低于1%。

    值得注意的是，CRDTs能够对这些应用程序的大部分进行建模，只有少数函数需要不可合并的事务。

    SwiftCloud方法设计为适合具有足够局部性的最佳应用程序，即使数据库的总大小很大，也可以在小缓存中运行，而且这些应用程序主要使用可合并事务。我们通过实现一系列满足这些特性的应用程序来证明我们的应用程序和一致性模型的适用性。

    用作者自己的话说，本文的贡献如下：

    • 一种云存储系统的设计，它向客户端节点提供地理复制。
    • 在一个包括客户端节点和服务器中的副本的系统中，实现事务因果+一致性模型的可伸缩、高效协议的设计。
    • 容错技术，确保事务因果+一致性保证，而不增加操作延迟。
    • 一项应用研究表明，该方法在实践中是有用的，并揭示了它的不足之处。
    • 对系统的实验性评估，有不同的应用和场景。

    一个有前途的方向，有很多明显的好处。作为一个应用程序设计师，探索将工作拆分为可合并事务和不可合并事务的概念也很有趣——这是一个可以独立于解决方案的其他部分应用的想法。