摘要：本文介绍了一种在移动计算云中扩展分布式数据缓存服务以实现跨区域多活复制的方案。

本文分享自华为云社区《移动计算云分布式数据缓存服务，实现快速可靠的跨区域多活复制》，作者： 敏捷的小智。

本文翻译自华为加拿大研所论文，英文原文链接：

https://www.sciencedirect.com/science/article/pii/S1877050921014101

第 18 届国际移动系统和普适计算大会（MobiSPC）

2021 年 8 月 9 日至 12 日，比利时鲁汶

移动计算云分布式数据缓存服务

实现快速可靠的跨区域多活复制

Daniel House, Heng Kuang*, Kajaruban Surendran, Paul Chen

加拿大安大略省万锦市 华为加拿大研究院

摘要

本文介绍了一种在移动计算云中扩展分布式数据缓存服务以实现跨区域多活复制的方案。阐述如何保证网络脑裂恢复后区域间数据的一致性，提出了一种跨区域副本数据同步的方法，能够克服在严重网络脑裂下，缓存数据操作的复制无法保证因果关系顺序的情况。本文使用的是最流行的移动计算云分布式数据缓存服务——Redis 内存数据库，所述方案以插件的形式进行应用（最大程度减少对缓存服务端和客户端的影响）。Redis 开放了强大的扩展 API，允许新的抽象数据类型与 key 关联，但 Redis 并未对增加和管理全局字典元数据提供直接支持，这在本方案得以实现。本方案使用该扩展 API 来增加 CRDT（无冲突复制数据类型），解决来自多个区域的写入冲突。

© 2021 The Authors. Published by Elsevier B.V.

This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/)

Peer-review under responsibility of the Conference Program Chairs.

关键词：云数据缓存；跨区域多活；无冲突复制数据类型 CRDT；可用性

1. 引言

移动计算云应用要求即便在高峰时段也要保证最短响应时间。因此，使用分布式数据缓存服务来增强性能就显得尤为重要。实际上，数据缓存已几乎成为一项必备移动计算云服务，其中，AWS ElastiCache 缓存服务、Azure Redis 缓存服务、阿里云云数据库 Redis 版、华为分布式缓存服务（DCS），都使用 Redis 作为缓存引擎。

* Heng Kuang. Tel.:

E-mail address:

移动计算云中，分布式数据缓存服务依赖跨区域多活来保证全球各地的最终用户都能够使用到可靠、高性能的移动云应用。随着移动计算云中的应用数量不断增加，如今的应用需要快速响应来自各大洲的数据读写请求，响应时间可能需要比跨洋短信送达的时间还快。不管网络和组件出现什么问题，应用必须始终保持可用，始终追求快速解决一致性问题，几乎要冲破 CAP 定理 [10] 的束缚。这种需求场景可能出现在世界不同地区的用户需要编辑共享数据（如多人文档协同）时，需要同时点击网页、订机票时，或者某个用户需要在不同设备间保持数据统一时。还有一些场景，用户虽然感知不到数据共享或复制本身，但却能感知时延和可靠性，比如购物车应用。

单向缓存复制中，所有写请求都发送到缓存的中心实例，这个中心实例是所有副本的主节点。当主节点发生故障时，其余副本中的一个被选举为新的主节点。一旦网络脑裂发生，与主节点位于同一分区中的客户端和副本不受影响，能够继续运行，但其他分区中的客户端和副本只有两种选择：被阻塞，或是在其所在分区中选举新的主节点。如果是购物类应用，阻塞会直接影响销量，因此绝不允许阻塞发生。如果每个分区都选举出自己的主节点，则该分区中所有的主节点需要同步数据，形成单主节点的格局。但在多活复制中，没有主节点，数据统一持续进行，脑裂后恢复也并不需要额外处理。当世界各地的用户对应用数据同时进行操作（比如订机票时），如果只有单主节点处理写入请求，对于距离该节点很远的用户来说时延太大，体验很差。此时，就可以使用多活复制，实现全体用户的时延差不多。

要想设计出好的多活复制系统，就需要转变思维，因为冲突解决的结果可能并不直观。设计人员可以选择发现冲突、上报冲突然后人工解决，也可以选择自动解决冲突。即便在单向复制中依照 last-writer-wins，给 key 赋一个简单的值，对设计人员来说也可能有新颖独特的选项，例如可以采取一键多值[5]，如果多个请求需要同时对一个值进行更改或删除，可以选择哪个请求中的操作获胜。采用 [7] 中所实现的多活队列，就能对同一条数据进行多次出队。开发人员必须知晓这些选项，充分理解这种新思维，才能写出有效的代码。新思维利用得当，单向复制中处理并发的思路就能够简化。必须要保持机动灵活的思维。

与单向复制相比，多活复制需要存储和传输用于检测和解决数据冲突的元数据，所以缓存大小和复制期间的数据发送量都会增加。保证最终一致性的算法比单向复制中简单的 last-writer-wins 规则复杂得多，实现过程更容易出错，复制也更慢。跨区域多活要求在不同区域间快速可靠地双向同步数据，原因如下：

• 即便跨地域的网络速度慢或不稳定，复制速度也必须能赶上不同区域的并发写入速度。

• 必须保证所有区域数据的最终一致性。

• 数据写入冲突的识别和解决都必须快速完成且保证一致性。现有的冲突解决机制中，Consensus / Quorum 机制的吞吐量低，Multi-Version Concurrency Control 机制的系统开销大，last-writer-wins 机制会造成应用间的不一致性。

• 使用元数据来解决数据变更所导致的冲突，不应影响数据在缓存实例之间的可迁移性。

• 不管是对缓存客户端还是服务端，解决以上问题的同时，性能、应用以及缓存服务的实现不能受到显著影响。

为了在实现跨区域多活的同时满足以上这些严苛的要求，越来越多的人开始关注到无冲突复制数据类型（下称 CRDT）。CRDT 又分为基于操作的 Commutative Replicated Data Types（CmRDT），和基于状态的 Convergent Replicated Data Type（CvRDT）。Redis 是一种基于 key 与数据结构映射的开源内存数据库，可以提供跨任意距离的单向复制，是业内最受欢迎的应用于移动计算云的分布式数据缓存服务之一。本文以 Redis 为例，提供了一种可用于在移动计算云中构建跨区域分布式应用的关键架构。它结合 CRDT 和 Module API（Redis 用于扩展的插件机制），在尽可能减少对 Redis 实现及其客户端进行变更的基础上，利用 Redis 实现双向复制。

下文将介绍我们是如何在移动计算云中通过扩展 Redis 缓存服务来支持跨区域多活复制。内容将聚焦如何使用 Redis 及其扩展机制 Redis Module，利用 CRDT 保证网络脑裂恢复后跨区域数据的一致性。后文结构如下：第 2 章节介绍 CRDT 在学界的理论研究和在业界的应用；第 3 章节概要介绍了我们提供的复制与冲突解决方案；第 4 章节探讨如何使用 CRDT 实现最终一致性；第 5 章节比较了本方案与业界其他方案；第 6 章节对本文中的方法和经验进行总结，并指出今后的工作方向。

2. 背景及相关工作

据我们所知，目前尚无移动计算云厂商提供基于 CRDT 跨区域多活复制的数据缓存服务。Redis 公司的 Redis Enterprise 产品是唯一可以通过基于操作的 Commutative Replicated Data Types（CmRDT）来支持该功能的内存数据库软件 [12]，但也没有官方文档描述 Redis Enterprise 是如何、由哪个组件（proxy、syncer 还是 Redis Module）来处理 CRDT 中的数据删除部分。Roshi [13] 提供时间序列事件存储，通过 LWW 元素集 CRDT 实现，使用有限的 inline garbage collection。Roshi 是基于 Redis 的分布式无状态层，在互不通信的集群上复制数据。Roshi 项目已超过 5 年未更新。

AntidoteDB [15] 是一个跨区域复制的 key-value 数据库，操作执行使用 CRDT，免于同步。其跨区域复制基于 ZeroMQ，支持的数据类型包括 Register、Flag、Map、Set、Counter。Riak KV [16] 是一个分布式 key-value 数据库，它使用基于状态的 Convergent Replicated Data Type（CvRDT），支持的数据类型包括 Register、Flag、Map、Set、Counter、HyperLogLog。Riak KV 不跟踪物理时钟，而是跟踪逻辑时钟（dotted version vectors），以识别和解决区域之间的冲突。Azure Cosmos DB 是一种 NoSQL 数据库，其数据库引擎的核心类型系统天生支持 CRDT [17]，但也没有公开文档描述它支持哪些数据类型，以及是如何支持这些数据类型的。相反，Cosmos DB 的文档解释了什么是 last-writer-wins 冲突解决策略和自定义冲突解决策略，以及如何配置这两种策略。Cosmos DB 使用反熵通道将试探性写入从一个资源分区复制到同一个分区组中的其他资源分区。

多活复制和 CRDT 算法有着丰富悠久的历史，可以追溯到 1975 年 [8]，比逻辑时钟还要早 [1]。目前，已经出现了许多种类的 CRDT。它们的主要共同点在于，数据的远程副本可以同时更新，冲突解决可以使用本地数据，所有副本数据最终都会保持一致。要实现有效的缓存复制，就必须有丰富的 CRDT 支持。本文讨论的数据类型仅限于单值 register 和 map。其他有用的 CRDT 还有多值 register、counter、list 和 set。

register 是一个对象，我们可以为其分配不透明数据，并从中读取数据。[9] 提到了多值 register，本文仅讨论单值 register。首个 CRDT 算法 [8] 使用物理时间戳来实现值是单值 register 的 map。[8] 提供的算法能够满足标准增删改查操作，同时确保了强最终一致性。

单值 register 是基于状态的 CRDT，这种 CRDT 非常可靠，只要消息最终能够送达，即便消息无序或多次投递也没关系。register 通常通过 version vector 来实现。当两个 version vector 无法比较，就使用物理时间戳；当物理时间戳相同时，就使用更新 register 的节点 ID。

不同 CRDT 需要不同的全局数据。 -state CRDT 需要因果关系的上下文，Replicated Hash Tables （RHTs）[2] 要求每个 key 都有一个向量时钟来解决冲突和识别垃圾数据，Replicated Growable Array（RGA）[2] 则需要消息队列和 last-vector-clock-processed，以确保消息投递符合因果关系顺序并识别垃圾数据。 -CRDT map 非常可靠。与 Roh [2]和 Wuu [3] 提到的 map 不同， -CRDT map 不依赖于向量时钟或基于因果关系的投递，也不受消息重排和多次投递的影响。在本文中，我们使用一种 -CRDT 算法来处理单值 register。

3. 系统架构

我们针对移动计算云中分布式数据缓存服务的跨区域多活复制方案由四个逻辑组件组成：数据缓存服务 Redis 的 CRDT 模块、Replicator、Replayer、以及 Replicator 和 Replayer 的操作日志，如图 1 和 2 所示。Replicator 和 Replayer 的实现机制相同，但作为两种模式运行。

图 1 系统构成

图 2 CRDT 模块

CRDT 模块负责：

• 从缓存服务客户端或 Replayer（从其他区域复制）接收缓存操作。

• 对于读操作，从缓存服务数据库获取值，并将其返回给缓存服务客户端。

• 对于写操作，生成解决潜在值冲突所需的元数据。

• 存储写操作生成的元数据。

• 通过元数据确定写操作是否与缓存服务数据库中的对应数据冲突。

• 如果不存在冲突，并且其 version vector 是最新的，则将值写入缓存服务数据库，然后将其复制到 Replicator。

• 如果存在冲突，则根据 CRDT 冲突解决规则将值写入数据库。

Replicator 负责：

• 作为其所在区域中缓存服务端的副本，通过沿用数据缓存服务中的主从复制机制，接收 CRDT 模块复制过来的成功的写操作。

• 为这些操作生成 ID，作为额外的元数据，并将这些操作推送到其复制管道。

• 将操作记录在自己的操作日志中。

• 当达到触发条件（例如，每隔 1 秒或当复制队列的大小达到 1KB），将复制队列中的操作发送给其他区域的 Replayer。

• 如果区域之间存在网络脑裂，则通过比较 Replayer 记录的操作 ID，识别操作日志中发送失败的操作，重试发送这些操作。

Replayer 负责：

• 作为其他区域 Replicator 的副本，通过沿用数据缓存服务中的主从复制机制，接收 Replicator 复制过来的写操作。

• 将操作记录在自己的操作日志中。

• 作为缓存服务客户端，将操作回放到对应的缓存服务端。

• 如果 Replayer 与其缓存服务端之间存在网络脑裂，则利用操作 ID 和操作日志查找并重试尚未到达缓存服务端的操作。

Replicator 的操作日志负责记录同区域 CRDT 模块复制过来的成功的写操作，然后在区域间网络脑裂恢复后，恢复这些操作。Replayer 的操作日志负责记录其他区域 Replicator 复制过来的写操作，然后在它与缓存服务端间的网络脑裂恢复后，恢复这些操作。

4. 实现最终一致性

CRDT 模块作为一种可动态加/卸载的共享库加载到缓存服务端，并可以直接开始拦截来自缓存服务客户端的请求，以对内部数据库执行本地操作。CRDT 模块更新数据库，然后向其他区域发送请求，对那些区域的数据库进行远程操作。图 2 中的 Replicator 和 Replayer 相互协调，确保在没有重大故障的情况下，所有远程操作都能准确按顺序投递一次，但无法保证基于因果关系的投递。当发生重大故障时，内部数据库的全量数据将在区域之间交换。

4.1. 系统模型

通过 Replicator 和 Replayer 的协作，我们可以得到一种抽象系统模型，其中有 n 个节点（节点间不共享任何内存），。每个节点都有一个 key-value 存储和一个控制存储。每对节点（和），都有一个单向通信管道，延迟很大（[10] 中的报告显示，洲际延迟可能高达 0.25 秒。）通信管道可能处于活跃状态或中断状态。处于活跃状态时，消息能够按顺序可靠地传递，不会重复。当管道中断，其间发送的消息永远不会送达。每当管道从中断转变到活跃时，节点就会使用该管道，将其数据库的全量副本传递到，之后管道将恢复发送远程操作。本地客户端生成查询（使用本地数据库进行应答，没有副作用，不会触发节点之间的任何通信，因此本文不会进一步讨论），并请求将本地操作加入本地数据库内容中。

每个节点都有一个物理时钟，用于生成物理时间戳。时钟之间不进行同步。我们假设，在时刻，观察到了包含个事件的有限序列 Ei = {ei0, … einit}，且当 j < k，则 eij 发生在 eik 之前。对于，我们假设对于从 Ni 发送到 Nk 的每一个消息 M，在 Ei 中都有一个发送事件，在中都有一个接收事件，那么发生在之前，写入顺序为。假设副本 1（R1）的日志 L1 包含操作 o1，副本 2（R2）的日志 L2 包含操作 o2。当 o1 ∉ L2 且 o2 ∉ L1 时可以确定 o1 和 o2 是并发的，表示为 o1 ∥ o2，如果在任一日志中 o1 出现在 o2 之前，则 o1 发生在 o2 之前，表示为 o1 < o2。

我们首先重新定义与字符串的 key 相关联的数据，因为它是 CRDT 单值 register。Redis 协议允许客户端将 key 设置为任何二进制 BLOB。基于对象的强最终一致性 [6] 可以在 register 删除或列表移除后回收空间。删除 key 时，我们需要 SWOR Map（Set-Wins, Observed-Remove）语义。由于 Redis 协议仅允许存在单值字符串，因此我们使用单值 register。RGA 中 key 的 SWOR Map 语义可以理解为：当 RGA 上所有条目都已删除并且最后一个 tombstone 已被 GC 进程回收，该 key 将被隐式删除。如果在此之前删除该 key，可能会导致并发的 list-add-right 操作出现问题。RGA 中的本地 key 删除操作可以简单扩展为一组列表移除操作。一个 map 可以在不同的时间包含不同的 key。我们的目标是让 key 表示 CRDT 值。随着 map 的演进，key 可以被删除，可能很久之后 key 再重新创建出来。你可以为 CRDT 值设置一个基础值或重置值，这种方法简单、可用，但其弊端在于 key 必须持续存在才能表示基础值。

4.2. 简单的 CRDT register

基于向量时钟的 register 依赖全局向量时钟。每当 register 创建时，都会获得新的向量时钟。如果 register 每次都以“基础”向量时钟重新开始，则可能导致错误的值获胜。基于 dots 的 register 依赖全局因果关系。如果并发集足够少（与节点数量相比），空间占用就能比基于向量时钟的方法更少。

每个副本都有自己的严格有序的事件历史。为保障最终一致性，整个事件历史都将随每一条消息一起发送。接收消息时，副本必须合并两份事件历史，才能获得一份新的严格有序的事件历史。要确保一致性，这种合并操作必须具备可结合及可交换性。获得全序后，register 的值来自最后一次操作。我们用⊥来表示无值，这个值是当历史为空且全序中最后一个操作为时 register 的值。我们可以定义不同的合并操作来获得不同的语义，如 last-writer-wins 或 set-wins。发送整个事件历史的代价很大，因此需要想办法减少发送的数据量。

5. 其他方案的比较

本节我们将评估和对比其他声称能够在内存数据库云服务或软件中实现跨区域多活复制的方案。

5.1. 阿里云 ApsaraDB for Redis

阿里云的 ApsaraDB for Redis 不支持 CRDT，而是要求用户的应用程序在使用跨区域多活复制功能时自行保障数据一致性 [11]。因此，用户的应用程序在实现时必须保证以下几点：

• 避免从不同区域同时写入相同 key（这很难控制）。

• 对 Redis 数据库进行分区，使不同区域的用户的应用程序只能写入分配给该区域的可写分区，同时从其他区域复制只读分区（这将影响用户的应用程序使用此功能的透明性，并使应用程序的实现更加复杂）。

如果无法做到以上几点，相关区域中的数据就将变得不一致。例如，当一个 key 的 value 变更在两个区域间同步后，可能导致两个区域间的 key value 互换 [11]；如果两个区域中，一个 key 变更为不同的数据类型，也可能导致同步失败 [11]。

5.2. KeyDB

KeyDB 是 Redis 的分支，已经成为 Redis 的一个直接替代方案，支持多活副本和其他高级功能。当启用多活复制时，KeyDB 允许两个主节点之间的循环连接，因此它还可以沿用 Redis 的主从复制机制。KeyDB 使用 last-writer-wins 来解决主节点之间的冲突 [18]。每个写操作都有时间戳，最新的写操作获胜。

但是，仅使用时间戳并不是一种可靠的冲突解决方案，因为可能会导致数据丢失，并且对许多数据类型（例如用于全球统计点赞数或关注数的计数器）还不够用。“最后写入”并不能得到保障，因为即使不同区域的服务端系统时钟可以在一定的间隔内与全局原子时钟同步，但时间还是会漂移，每个服务端还是根据自己的系统时钟来判断写操作的顺序。此外，将系统时钟回拨将导致意外的冲突解决。

5.3. Redis Enterprise

Redis Enterprise 是开源 Redis 之上的增强版，提供了许多企业级功能，跨区域多活复制就是最重要的功能之一。Redis Enterprise 中的 CRDB（无冲突复制数据库）是跨区域的多个 Redis 集群的数据库。每个集群中的数据库都是一个 CRDB 实例，使用 Syncer 将 Redis 操作复制到其他 CRDB 实例。Syncer 没有沿用 Redis 的复制机制，而是使用一种新的复制机制（从远程主节点请求复制）。一个 Redis Enterprise 集群包含 Redis Shard（分片）、Proxy（代理）、Cluster Manager（集群管理器）和 REST API。

Redis Enterprise 使用基于操作的 CRDT，需要通过 Syncer 和 Proxy 复制额外的“effect”数据到所有 CRDB 实例。这些“effect”数据由使用 Redis 模块数据类型 API [12] 构建的 CRDT 模块生成。但是，Redis Enterprise 没有明确说明“effect”数据中究竟包含什么信息，由谁（Syncer、Proxy 还是 Redis Module）以及如何将其应用于冲突解决。每个 CRDB 实例为每个数据库条目和子条目维护一个向量时钟，才能识别和解决区域之间的数据冲突 [12]。

5.4. 我们的方案

我们对单值 register map 实现了跨区域多活复制，使用向量时钟来识别并发的数据更改，并对非并发更改进行正确排序。

Redis Enterprise 是唯一可以使用基于操作的 CRDT 来支持跨区域多活复制的内存数据库软件，与之相比，我们的方案具有以下优势：

• 结合基于状态的 CRDT 和 Redis 模块数据类型 API，避免将“effect”数据与数据库条目分开存储和复制，从而使这些条目的迁移更安全、更方便。

• 无需等待外部组件（Syncer 或 Proxy），能够在 CRDT 模块中直接解决数据冲突，使冲突解决速度更快。

• 不需要代理（减少一次跳转），从而对缓存服务端和跨区域复制的性能影响降至最低。

• 沿用 Redis 数据缓存服务的主从复制机制，可最大限度地提高区域内和跨区域复制的性能。

为证明本方案（基于华为 DCS）的优势，我们做了一个实验，并在性能和 CPU 利用率维度与 Redis Enterprise 进行了比较，见以下步骤和图 3。

1. 在 3 台主机上启动 3 个华为 DCS 集群（每个集群中有 3 个 Redis server，每个 Redis server 都加载 CRDT 模块），模拟 3 个区域中的 3 个多活 Redis 集群。

2. 在每台主机上启动一组 Replicator 和 Replayer（将它们连接到该主机上的 3 个 Redis server）。

3. 运行 3 个 memtier-benchmark，分别向这 3 个集群发送具有相同 key 范围的写请求，模拟对多活集群的并发写操作。使用工具断开/重连不同主机上的 Replicator 与 Replayer，模拟不同区域之间的网络脑裂。

4. 收集实验数据，再对 Redis Enterprise 进行相同的实验。以下是观察结果：

1) 本方案即使在网络脑裂情况下，也实现了 3 个多活集群之间的最终一致性。

2) 本方案比 Redis Enterprise 性能更好（写/读请求比为 1:0 时，性能是 Redis Enterprise 的 200%），CPU 利用率更低（写/读请求比为 0:1 时是 Redis Enterprise 的 20%）。

图 3 与 Redis Enterprise 的性能和 CPU 利用率对比

6. 结论和今后方向

通过扩展缓存服务的实现，我们学到了一些重要的经验教训。首先，在任何实际的 CRDT 应用中，如果 CRDT 实例能被删除，都必须同时设计顶层 map 和 map 中的 CRDT 对象。map 和对象必须共享某些信息。比如，我们的单值 register 就需要访问 map 中的因果关系。我们还发现，实现 CRDT 算法需要仔细对比实际的消息传送环境与制定 CRDT 算法时做出的理论假设。由于两个区域之间的通信管道时而中断，我们的 CRDT 算法需要能够在区域之间执行全量同步，因此完全基于操作的 CRDT 算法就不合适。

本次概念验证将 CRDT map 与单值 register 相结合，用于移动计算云中的分布式数据缓存服务。我们希望进一步延展本次概念验证，将 Younes [4] 的可重置计数器和 Almeida [5] 的集合也包含进来。如果要将 Roh [2] 的 RGA 与 CRDT map 相结合，需要符合因果顺序的消息投递。我们还希望通过基于因果关系的广播协议 [6] 探索如何能实现数据缓存服务中可行的 RGA 故障模式。

冲突解决要求每个 key 最终在每个节点中的类型相同。数据类型的单向优先顺序虽然可以工作，但它只能是无规则的，而且我们到目前为止调研的类型晋级模式只能做到覆盖与一个 key 关联的所有先前的数据。完整的类型晋级网格可能并不存在，但仍然有可能存在一种类型冲突解决方案，既直观，又能在冲突解决过程中保留尽可能多的数据。

参考文献

[1] Leslie Lamport. 1978. Time, clocks, and the ordering ofevents in a distributed system. Communications of the ACM. 21,7 (July 1978), 558-565. DOI: https://doi.org/10.1145/359545.359563

[2] Hyun-Gul Roh, Myeongjae Jeon, Jin-Soo Kim, and JoonwonLee. 2011. Replicated abstract data types: Building blocks for collaborativeapplications. Journal of Parallel and Distributed Computing. 71,3 (March 2011), 354-368. DOI: https://doi.org/10.1016/j.jpdc.2010.12.006

[3] Gene T.J. Wuu and Arthur J. Bernstein. 1984. EfficientSolutions to the Replicated Log and Dictionary Problems. In Proceedingsof the third annual ACM symposium on Principles of distributed computing(PODC’84). ACM Press, New York, NY, USA, 233-242.DOI: https://doi.org/10.1145/800222.806750

[4] Georges Younes, Paulo Sérgio Almeida, and CarlosBaquero. 2017. Compact Resettable Counters through Causal Stability. InProceedings of the 3rd International Workshop on Principles and Practice ofConsistency for Distributed Data (PaPoC’17). ACM Press, New York, NY, USA, 1-3.DOI: https://doi.org/10.1145/3064889.3064892

[5] Paulo Sergio Almeida, Ali Shoker, and Carlos Baquero.2018. Delta State Replicated Data Types. Journal of Parallel andDistributed Computing. 111 (January 2018), 162-173.DOI: https://doi.org/10.1016/j.jpdc.2017.08.003

[6] Kenneth Birman, Andre Schiper, and Pat Stephenson.1991. Lightweight causal and atomic group multicast. ACM Transactionson Computer Systems. 9, 3 (August 1991), 272-314.DOI: https://doi.org/10.1145/128738.128742

[7] Redis Labs. 2020. Developing with Lists in anActive-Active Database. Redis Labs. Retrieved November 1, 2020from: https://docs.redislabs.com/latest/rs/references/developing-for-active-active/developing-lists-active-active/

[8] Paul R. Johnson and Robert H. Thomas. 1976. Themaintenance of duplicate databases. Internet Request for Comments RFC677. (January 1976) Information Sciences Institute

[9] Giuseppe DeCandia, Deniz Hastorun, Madan Jampani,Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, SwaminathanSivasubramanian, Peter Vosshall, and Werner Vogels. 2007. Dynamo: Amazon’shighly available key-value store. ACM SIGOPS Operating Systems Review.41, 6 (October 2007), 205-220.DOI: https://doi.org/10.1145/1323293.1294281

[10] Seth Gilbert and Nancy Lynch. 2002. Brewer’sconjecture and the feasibility of consistent, available, partition-tolerant webservices. ACM SIGACT News. 33, 2 (June 2002), 51-59.DOI: https://doi.org/10.1145/564585.564601

[11] Alibaba 2020. Constraints on using theactive-active geo-replication of ApsaraDB for Redis. Alibaba. RetrievedNovember 1, 2020from: https://help.aliyun.com/document_detail/71883.html?spm=a2c4g.11186623.2.15.240c4c07jsXWWr#concept-cbs-dfk-zdb

[12] Redis Labs. 2020. Active-ActiveGeo-Distribution (CRDTs-Based). Redis Labs. Retrieved November 1, 2020from: https://redislabs.com/redis-enterprise/technology/active-active-geo-distribution/

[13] SoundCloud 2020. Roshi. SoundCloud.Retrieved November 1, 2020 from: https://github.com/soundcloud/roshi

[14] Marc Shapiro, Nuno Preguica, Carlos Baquero, MarekZawir ski. 2011. A comprehensive study of convergent and commutative replicateddata types. Technical Report. (January 2011)

[15] AntidotDB 2020. AntidotDB. AntidotDB.Retrieved November 1, 2020 from: https://github.com/AntidoteDB/antidote

[16] Riak 2020. Riak KV. Riak. RetrievedNovember 1, 2020 from: https://riak.com/products/riak-kv/index.html

[17] Microsoft 2020. Azure Cosmos DB: Pushing thefrontier of globally distributed databases. Microsoft. Retrieved November1, 2020 from: https://azure.microsoft.com/en-us/blog/azure-cosmos-db-pushing-the-frontier-of-globally-distributed-databases/

[18] EQ Alpha 2020. Active Replica Setup. EQAlpha. Retrieved November 1, 2020from: https://docs.keydb.dev/docs/active-rep/

[19] Redis Labs. 2020. Redis Enterprise ClusterArchitecture. Redis Labs. Retrieved November 1, 2020from: https://redislabs.com/redis-enterprise/technology/redis-enterprise-cluster-architecture/

点击关注，第一时间了解华为云新鲜技术~