BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Roshan Kumar 关注 0 他的粉丝 ,译者 张兰月 关注 0 他的粉丝 发布于 2018年7月23日. 估计阅读时间: 13 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

关键要点

  • 现代分布式应用程序推动正促使我们对分布式双活、多主机数据库的需求不断增长。
  • 多主机支持的方法包括两阶段提交、基于仲裁的多主机、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 EnterpriseAzure 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 KumarRedis实验室的高级产品营销经理。他在技术领域的软件开发和营销方面拥有丰富的经验。Roshan曾在惠普和许多成功的硅谷创业公司—如ZillionTV、Salorix、Alopa和ActiveVideo等工作。作为一名狂热的程序员,他设计和开发了mindzeal.com,一个为年轻学生提供计算机编程课程的在线平台。Roshan拥有美国加州圣克拉拉大学的计算机科学学士学位和MBA学位。

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

感谢冬雨对本文的审校。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT