双活地理分布（基于 CRDTs）| Redis Enterprise

双活架构是一种数据弹性架构，它通过独立且地理上分散的集群和节点将数据库信息分布在多个数据中心。它是由独立的处理节点组成的网络，每个节点都可以访问一个共同的复制数据库，这样所有节点都可以参与一个共同的应用，确保本地低延迟，并且每个区域都可以独立运行。

通过在 Redis Enterprise 中使用跨多个集群的全局数据库来实现双活架构或双活地理分布拓扑。这通过实现 CRDTs（无冲突复制数据类型）来达成。这种数据库被称为“无冲突复制数据库”或“CRDB”。

CRDB 提供了优于其他地理分布式解决方案的三大基本优势

无论地理复制区域的数量和它们之间的距离如何，它都能提供本地读写操作的低延迟。
它能够为简单和复杂的数据类型（如 Redis 核心数据类型）实现无缝的冲突解决（即“无冲突”）。
即使 CRDB 中的大多数地理复制区域（例如，5 个中有 3 个）发生故障，其余的地理复制区域也不会中断，并且可以继续处理读写操作，确保业务连续性。

部署和拓扑

CRDB 是一种跨多个 Redis Enterprise 集群创建的数据库，这些集群通常位于世界各地不同的数据中心。每个参与集群中的数据库称为一个“CRDB 实例”。只要 CRDB 数据集能够容纳在 CRDB 实例内存中，每个 CRDB 实例就可以进行不同的配置——由不同数量的分片组成，并在不同数量或类型的集群节点上运行

此外，一个 CRDB 实例可以运行在启用了高可用性和数据持久性的多可用区 (AZ) 集群配置上。第二个 CRDB 实例可以运行在没有高可用性或数据持久性的单可用区集群配置上。这些 CRDBs 可以在任何云环境中同时运行，包括 Google Cloud、Azure 和 AWS。这种增加的灵活性优化了您的特定用例的基础架构成本和数据库性能。

使用 CRDB 的应用连接到本地 CRDB 实例端点。所有 CRDB 实例之间使用双向数据库复制，形成网状拓扑结构，也就是说，应用对本地实例的所有写入都会复制到所有其他实例，如下所示

注意：未来版本的 Redis Enterprise 将提供额外的拓扑结构，例如环状拓扑。

高级架构

无冲突复制数据类型层

CRDB 架构基于大多数 Redis 命令和数据类型（如前所述称为无冲突复制数据类型）的另一种实现。在 Redis Enterprise 中，我们的 CRDB 实现基于使用 Redis 模块数据类型 API 构建的专有 Redis 模块。

读取命令使用本地 CRDB 实例在本地处理。CRDT 层固有的无共识机制不需要其他双活实现中常见的“读取修复”。

写入命令遵循基于操作的 CRDT 原则，分两个步骤处理

在准备阶段，使用本地 CRDB 实例处理用户的请求，并创建一个产生的效果。
在效果阶段，上面生成的效果数据会分发给所有实例（包括本地实例）并应用。

基于操作的 CRDT 要求将效果更新以源端 FIFO 一致性的方式精确地投递到所有 CRDB 实例。CRDB 通常依赖 Redis 复制机制，并进行了一些修改以满足这些保证。

对等复制

CRDB 复制由 syncer（同步器）实现，它们联系远程主节点并请求对等复制（如下图所示），并为此目的引入了一种新的数据库复制机制。对等复制的工作方式与标准 Redis 复制类似

PSYNC 和复制偏移量用于恢复中断的链接
总是可以回退到完全同步 (full SYNC)

一旦对等节点建立复制链接，只有由 CRDT 模块生成的 CRDT 效果会被传播。根据拓扑结构，可能会应用额外的过滤以仅包含特定更新。使用网状拓扑时，对等复制将仅携带在本地 CRDB 实例上生成的效果。

CRDB 实例可以将不同的复制流推送到其他对等节点，以便对等复制机制可以管理许多不同的复制积压。

自动 GZIP 压缩和 SSL 加密

当识别到远程公网 IP 时，会自动对对等复制应用 GZIP 压缩，以便更好地利用广域网链接。此外，如果在连接建立过程中识别到 SSL 握手，加密将自动启用。

对等复制操作如下所示

高可用性和灾难恢复

如果一个或多个 CRDB 实例发生故障，全局 CRDB 下的其他实例将继续读写，提供持续的可用性和灾难恢复。即使大多数 CRDB 实例（例如，5 个中有 3 个）停机，剩余的 CRDB 实例也不会中断，并且可以继续处理读写请求。在此类区域性故障中，无法连接到本地 CRDB 实例的用户通常会被导向到指向可用 CRDB 实例之一的其他数据中心。这即使在用户的本地 CRDB 实例停机时，也能为应用读写提供持续的可用性。

在极少数情况下，CRDB 实例可能会经历完全的数据丢失，需要从头开始进行数据库复制。这种情况需要特殊处理，因为恢复中的 CRDB 实例可能已经向其部分对等节点发送了更新。由于无法再期待进一步的更新，我们不能假定所有对等节点最终都会收敛（某些效果消息可能已被部分对等节点收到，但未被其他对等节点收到）。在此场景下，Redis Enterprise 实现了一种涉及所有相关 CRDB 实例的协调机制。协调完成后，恢复中的实例可以简单地从任何其他副本进行完全同步。

一致性模型

在 CRDB 部署中应用了多种一致性特性

对于本地 CRDB 实例操作，在实现 WAIT 命令时，可达到近乎强一致性；否则，操作被归类为弱一致性。
对于全局 CRDB 操作，强最终一致性 (SEC) 特性确保任何两个接收到相同（无序）更新集的 CRDB 实例将在不需要共识协议的情况下处于相同状态。与仅提供活性保证（即更新最终会被观察到）的最终一致性系统不同，强最终一致性增加了安全性保证。

冲突（无冲突）解决

CRDB 冲突解决基于 CRDT 的三个原则

并发写入的结果是可预测的，并且基于一套规则。
应用无需对并发写入做任何处理（但必须与 CRDB “方言”兼容）。
数据集最终将收敛到一个单一的、一致的状态。

冲突解决的工作原理

每个 CRDB 实例分别为每个数据集对象/子对象维护一个向量时钟。此向量时钟在实例级别的任何更新操作发生时，或当另一个 CRDB 实例传来针对同一对象的更新操作时进行更新。

当从另一个实例收到更新操作（及向量时钟）时，以下过程会在每个 CRDB 实例中单独执行

阶段 1： 分类更新操作

收到的更新操作可能代表 (1) 新更新，(2) 旧更新，或 (3) 并发更新。

分类算法工作如下

当实例 A 从实例 B 接收到关于对象 X 的更新时

如果: x_vc[b] > x_vc[a] – 这是“新”更新
如果: x_vc[b] < x_vc[a] – 这是“旧”更新
如果: x_vc[b] ≸ x_vc[a] – 这是“并发”更新

其中 x_vc[a] 是实例 A 中对象 X 的向量时钟，x_vc[b] 是实例 B 中对象 X 的向量时钟。

阶段 2： 在本地更新对象

如果更新被归类为“新”，则在本地 CRDB 实例中更新对象值
如果更新被归类为“旧”，则不在本地 CRDB 实例中更新对象值
如果更新被归类为“并发”，则执行冲突解决以确定是否以及如何更新此 CRDB 实例中的对象值

CRDB 冲突解决算法基于两个主要过程

过程 1： 无冲突数据类型/操作的冲突解决

在许多并发更新状态下，可以根据适用数据类型的属性完全无冲突地处理更新。以下是一些示例

当数据类型是 Counter（映射到 CRDT 的 Counter）时，所有操作都是可交换且无冲突的。示例： 跟踪跨区域文章人气、分享或转发的计数器。
当数据类型是 Set（映射到 CRDT 的 Add-Wins Observed-Removed Set）且并发更新是 ADD 操作时，所有操作都是关联的或幂等的且无冲突。示例： 在欺诈检测中，应用跟踪与 ID 或信用卡相关的可疑事件。如果达到阈值，则使用与 ID 或信用卡关联的 Redis Set 基数来触发警报。
当数据类型是 Hash（映射到 CRDT 的 map）且并发更新作用于不同的 Hash 字段时，所有操作都是无冲突的，就像它们在不同对象上实现一样。 示例： 一个具有多个用户的共享企业账户，在不同地点或不同费率下使用某个计划。每个账户的 HASH 对象可以包含每个用户的无数字段，并且即使在并发时，单个用户的使用情况也可以无冲突地更新。

在所有这些情况下，此实例中的对象值根据数据类型策略进行更新。

过程 2： 使用最后写入获胜 (LWW) 机制的冲突解决

在非无冲突数据类型（例如 Redis String，映射到 CRDT 的 register）的并发更新情况下，应应用冲突解决算法。我们使用了 LWW 方法，通过利用操作时间戳作为决胜点来解决此类情况。

请注意，即使区域之间存在时间戳偏差，我们的解决方案也能以强最终一致性的方式工作。例如，假设实例 A 的时间戳始终领先于其他实例的时间戳（即在决胜点的情况下，实例 A 始终获胜）。这确保了最终一致的行为。 示例： 对于由多个地理分布实体访问的用户账户，密码被更改。在这种情况下，更改会强制其他用户注销，这可能是许可证强制执行场景下的正确行为。