如何选择地理分布式双活策略：合并复制和 CRDT 之对比

关键要点

• 现代分布式应用程序推动正促使我们对分布式双活、多主机数据库的需求不断增长。
• 多主机支持的方法包括两阶段提交、基于仲裁的多主机、LWW（最后一个写入器赢得冲突）、MVCC（多版本并发控制）、合并复制、基于一致性的无冲突复制数据类型（CRDT）
• LWW、MVCC、合并复制和 CRDT 能确保最终的一致性，提供具有本地延迟的读写访问，并在网络分区期间保持可用
• 基于 CRDT 的冲突解决方案实施经数学验证的规则，确保一致的正确数据视图，而不牺牲响应时间。
• 与传统的冲突解决方法不同，CRDT 在分布式数据库中提供了因果一致性和强大的最终一致性。该技术非常适用于需要亚毫秒级数据访问延迟的实时和极具吸引力的应用程序。

随着世界成为一个地球村，企业越来越多地关注多个数据中心，以实现高可用性、更大的覆盖范围和最佳的用户体验。对应用程序的重新设想推动了对分布式双活数据库不断增长的需求。虽然大多数流行的数据库支持多主机部署，但不同的数据库仍采用不同的技术。

多主机支持的方法包括两阶段提交、基于仲裁的多主机、LWW（最后一个写入器赢得冲突）、MVCC（多版本并发控制）、合并复制、基于无冲突复制数据类型（CRDT）的一致性，等等。按照 CAP 定理，两阶段提交和基于仲裁的多主机模型提供了强大的一致性。但是，依赖于这些技术的系统通常在网络分区期间不可用。另外，这些技术很琐碎，并且会给数据库操作增加很大的延迟。其他技术，即上面提到的 LWW、MVCC、合并复制和 CRDT，则能提供最终的一致性、具有本地延迟的读写访问，并在网络分区期间保持可用。

在本文中，我们将研究基于最终一致性的两种多主机数据复制技术之间的基本区别 – 1.合并复制，一种通过关系数据库提供最终一致性的传统技术，以及2. CRDT，一种更新的突破性技术，它为智能冲突解决奠定了基础，具有很强的最终一致性和因果一致性。CRDT 数据库提供了经数学验证的模型，用于解决冲突，确保所有数据集收敛到相同的正确状态。

合并复制

合并复制是关系数据库使用的常用技术。此技术允许你部署分布式数据库解决方案，其中每个数据库服务器都有自己的数据副本。然后，外部代理会收集对本地副本的变更并将其合并，以强制所有数据库服务器均包含相同的数据副本。

工作原理

典型合并复制的拓扑在多个区域中均部署有数据库服务器，并采用发布者 / 订阅者模型。其中一台服务器被标识为主服务器或发布者，而其余服务器则是订阅者。在正常流程中，发布者的所有变更都会流向订阅者。但是，在合并复制中，订阅者也可以进行数据库变更，并将所有本地变更与发布者合并。这些变更最终将被发送到所有订阅者服务器。假设在合并期间没有发生冲突，对发布者或订阅者所做的所有变更最终都将收敛为同一副本。



图 1 站点 A、B、C 处的合并复制拓扑示例

“合并代理”是一种外部服务，它负责收集对本地数据库服务器的所有变更并将它们合并为单个数据集。发生冲突时，合并代理遵循一组预定义的规则来解决冲突。如果默认的冲突解决方法与你的解决方案不一致，那么你可以通过设置自己的“冲突解决程序”来覆盖它。但是，这种灵活性会以性能和延迟为代价。同时，你的自定义冲突解决程序也可能会破坏你的发布者和订阅者之间的一致性。

冲突解决是合并复制的核心，它采用分层模型。每个数据库服务器均被分配一个优先级编号，发布者为最高优先级。如果两个数据库服务器修改了相同的数据副本，则合并代理会根据优先级编号决定谁输谁赢。代理则保存一个单独的冲突表，记录所有输家的变更，而管理员可以手动解决冲突。

基于 CRDT 的复制

在基于 CRDT 的分布式数据库平台中，拓扑可以在每个区域中包括两个或多个数据库节点，而每个区域中均有本地数据副本。CRDT 规则强制使本地数据的任何变更在所有其它区域被合并，以保证这些数据最终高度一致。开发人员构建应用程序以遵循预设的数据类型规则，而CRDT 数据库中的冲突解决技术则针对特定数据类型进行了优化，因此它们比合并复制快许多倍。 Redis Enterprise和 Azure Cosmos DB支持基于 CRDT 的多主机分布式数据库，但此拓扑中只有 Redis Enterprise 支持复杂数据类型。



图 2. 站点 A、B、C 处的基于 CRDT 的 Redis Enterprise 拓扑示例

工作原理

除了交换数据之外，CRDT 技术还交换操作，包括它们的顺序和因果关系。因此，合并技术不仅仅合并数据，而且它们遵循预设的数学规则来合并每种数据类型的数据操作。系统没有内置任何层次结构（这与合并复制不同），因此所有节点都具有相同的优先级。CRDT 数据库也不需要区域之间基于仲裁的共识。你可浏览 Redis Enterprise 的技术站点更详细地了解 CRDT 如何工作。

对比合并复制和基于 CRDT 的分布式数据库

合并复制和基于 CRDT 的分布式数据库是用于数据复制和冲突解决的两种截然不同的技术。它们的差异列于下表：

	合并复制	基于 CRDT
吞吐量	由于纵向扩展数据库的特性和缓慢的自定义冲突解决性能，通常它只能提供有限的吞吐量	具有根据数据类型优化的内置高效冲突解决方案，较合并复制具有更高的吞吐量
复制滞后	通常较高且不可预测，因为复制的滞后取决于合并过程的复杂性，并受到纵向扩展数据库的性能特征的限制	数据同步的延迟低，主要取决于网络延迟；数据连续同步，且分布式数据库并行复制（在 Redis Enterprise 中）
CAP 中的一致性	仅支持最终一致性，自定义冲突解决可能会破坏一致性	支持强大的最终一致性和因果一致性
CAP 中的可用性	在网络分区中可用	在网络分区中可用
操作复杂性	在典型的实现中，由于纵向扩展模式，合并代理可能成为复制的单点故障和瓶颈；自定义冲突解决带来了灵活性，但也带来了维护开销	分布式数据库体系结构允许线性扩展（在 Redis Enterprise 中）；复制过程没有单点故障
灵活地覆盖默认规则	合并复制非常灵活，允许数据管理员覆盖默认的冲突解决方法	冲突解决基于根据数据类型预设的数学模型
从异构数据库合并	可以在不同表和不同关系数据库（甚至是来自不同供应商的数据库）之间合并数据	参与基于 CRDT 的冲突解决的所有数据库实例必须具有相同的数据库和数据集

示例：合并复制和基于 CRDT 的冲突解决方案如何处理计数器

在此示例中，我们使用了某社交媒体应用程序，该应用程序从部署其数据库服务器的三个不同数据中心收集了图像上的点赞数量。让我们看看与基于 CRDT 的 Redis Enterprise 相比，计数器如何在支持合并复制的分布式数据库中工作。

合并复制

如下图所示，站点 A 将计数器更新为 30，站点 B 将计数器更新为 40，站点 C 将计数器更新为 50。站点 A、B 和 C 分配的优先级为 100、75 和 50。



图 3. 使用合并复制的计数器示例

当合并代理从 A、B 和 C 接收更新时，它会检测冲突，并调用其冲突解决程序来解决冲突。如果你使用默认冲突解决程序，具有最高优先级的数据将被选择为获胜者，并且来自其它两个节点的数据将被转到冲突表中。正如你所看到的，默认的冲突解决程序会导致计数器的错误实现，因此你需要实施自己的冲突解决程序来覆盖默认方法。

基于 CRDT 的冲突解决方案

使用 Redis Enterprise 的计数器是 CRDT，并具有合并变更的内置逻辑。如下所示，站点 A 将计数器递增 30，站点 B 将计数器递增 40，站点 C 将计数器递增 50。



图 4. 使用 CRDT 的计数器示例

由于 CRDT 规则，每个节点使用它在计数器上执行的操作来更新另一个节点，并且它们都收敛于最终值 120。

用例

合并复制

合并复制已在市场上存在多年。它已经发展成为在分布式关系数据库中复制数据的标准技术。一些常见的合并复制用例包括：

• 灾难恢复：在网络断开或自然灾害的情况下，合并复制可以使用关系数据库提高应用程序的业务连续性。
• 地理分布式数据仓库：采用及时数据同步的解决方案使用此技术来解决冲突。
• 实现无缝增长：当企业在其产品组合中添加更多应用程序时，数据库管理解决方案面临着每秒支持更多操作的压力。通过合并复制，企业可以通过复制数据并将副本保存在更靠近应用程序的位置来克服物理限制。

基于 CRDT 的分布式数据库

由于其支持本地延迟查询和事务处理，基于 CRDT 的分布式数据库提供了极具吸引力的应用程序。他们的一些常见用例包括：

• 投票、排行榜和计量解决方案的全局计数器：CRDT 计数器是一种特殊的数据类型，仅支持递增或递减相关值。换句话说，此数据类型不允许你设置值。拥有基于 CRDT 的计数器的分布式数据库易于实现，并且所有视图都将收敛到相同的最终值，数据类型通过基于规则的方法自动处理冲突以实现正确的最终值。
• 用于地理分布式应用程序的会话存储：CRDT 允许应用程序在数据中心之间无缝切换。例如，假设你在电子商务网站上购物并将商品添加到购物车。如果应用程序的本地数据库失败，它可以切换到其中一个远程数据库，其中购物车中的所有项目都保持不变。你可以继续添加项目，并在没有覆盖它们的情况下进行故障恢复，因为 CRDT 能够正确处理每个区域中的更新。
• 跨微服务的数据整合：在微服务架构中，每个微服务都有自己的数据库本地副本。假设多个微服务共享相同的数据，你可以在应用程序层同步数据，或让数据库为你同步数据。后一种技术确保了微服务之间的数据完整性。基于 CRDT 的数据库使数据整合变得快速、简单、方便和高效。
• 协作：提供因果一致性的能力使基于 CRDT 的数据库成为开发协作、游戏和社交类应用程序的理想选择。因果一致性保证你能始终以正确的顺序合并数据，从而为所有协作者提供一致的视图。例如，聊天应用程序可以确保消息得到正确排序，以最大限度地减少误解！

结论

总之，合并复制是一种老技术，它具有关系数据库的内置冲突解决方案。该技术支持自定义冲突解决方案，因此具有灵活性。但是，你应该特别注意确保冲突解决不会破坏管理数据一致性的任何规则。从操作层面来看，合并复制性能较慢，并且合并代理为单点故障。

基于 CRDT 的冲突解决方案实现了经数学验证的规则，以确保一致的正确的数据视图，而不会牺牲响应时间。与传统的冲突解决方法不同，CRDT 在分布式数据库中提供了因果一致性和强大的最终一致性。该技术非常适用于需要亚毫秒级数据访问延迟的实时和应用程序。

作者简介

Roshan Kumar 是 Redis 实验室的高级产品营销经理。他在技术领域的软件开发和营销方面拥有丰富的经验。Roshan 曾在惠普和许多成功的硅谷创业公司—如 ZillionTV、Salorix、Alopa 和 ActiveVideo 等工作。作为一名狂热的程序员，他设计和开发了 mindzeal.com，一个为年轻学生提供计算机编程课程的在线平台。Roshan 拥有美国加州圣克拉拉大学的计算机科学学士学位和 MBA 学位。

查看英文原文： Picking an Active-Active Geo Distribution Strategy: Comparing Merge Replication and CRDT

感谢冬雨对本文的审校。