主动主动地理分布（基于CRDTS）

通过实施实现主动主动地理分布式拓扑CRDTs(无冲突复制数据类型)在Redis Enterprise中使用跨多个集群的全局数据万博体育彩库。这被称为“无冲突复制数据库”或“CRDB”。

CRDB在其他地理分布式解决方案中提供了三种基本好处：

它提供了读写操作的本地延迟，而不管地理复制区域的数量和它们彼此之间的距离。
它可以实现无缝冲突解决（“不冲突”），简单，以及redis核心的复杂数据类型。
即使CRDB中的大多数GEO复制区域（例如，5）下降，剩余的地理复制区域也不间断，可以继续处理读写操作。

部署和拓扑

CRDB是跨多个RediS企业集群创建的数据库，该集群通常驻留在世界各地的不同数据中心。万博体育彩每个参与群集中的数据库称为“CRDB实例”。只要CRDB数据集适合CRDB实例内存，就可以使用不同数量的分片来配置每个CRDB实例，并在不同的数量或类型的群集节点上运行。

此外，一个CRDB实例可能运行在启用了高可用性和数据持久性的多可用分区集群配置上，而第二个CRDB实例可能运行在没有高可用性和数据持久性的单可用分区集群配置上。这种高水平的灵活性允许您针对特定的用例优化基础设施成本和数据库性能。

使用CRDB的应用程序连接到本地CRDB实例端点。在网状拓扑中的所有CRDB实例之间使用双向复制，即应用程序对本地实例的所有写操作都被复制到所有其他实例，如下所示:

主动CRDB部署图 — 注意：未来的Redis Enterprise版本将万博体育彩具有额外的拓扑，例如环。

高级体系结构

CRDT层

CRDB架构基于大多数Redis命令和数据类型的替代实现(称为CRDTs，如上所述)。在Re万博体育彩dis Enterprise中，我们的CRDB实现是基于一个专有的Redis模块，它是用Redis模块数据类型API构建的。

读命令使用本地CRDB实例在本地处理。CRDT层固有的无共识机制不需要其他有源-有源实现共同的“读修复”。

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

在准备步骤，使用本地CRDB实例处理用户的请求和生成的效果被创建。
在效果一步,效果上面生成的数据被分发到所有实例(包括本地实例)并应用。

行动,CRDTs需要效果更新将被交付给所有CRDB实例，并保证在源FIFO一致性中只交付一次。为了实现这些保证，CRDB通常依赖于Redis复制机制，只做了一些修改。

对等复制

CRDB复制是由同步器实现的，同步器联系远程主机和请求同行复制(如下所示)，专门为此目的引入了一种新的复制机制。对等复制的工作方式类似于标准的Redis复制:

PSYNC和复制偏移用于恢复断开的链接
回退到全同步始终是可能的

一旦对等端建立了复制链路，就只传播由CRDT模块生成的CRDT效应。根据拓扑结构的不同，可以应用额外的筛选，以便只包含特定的更新。当使用网格拓扑时，对等复制只会对本地CRDB实例产生影响。

CRDB实例可以将不同的复制流推送到不同的对等体，因此对等体复制机制可以管理许多不同的复制积压。

自动GZIP压缩和SSL加密

当识别到远程公共IP时，将自动对对等复制应用GZIP压缩，以更好地利用WAN链路。此外，如果在连接建立期间确认了SSL握手，则会自动设置加密。

这里演示了对等复制操作:

高可用性和灾难恢复

在一个或多个CRDB实例失败的情况下，全局CRDB下的其他实例继续读写。即使大多数CRDB实例(例如5个中的3个)都关闭了，其余的CRDB实例仍然是不间断的，可以继续进行读写操作。在这些类型的区域性故障中，无法连接到本地CRDB实例的用户通常被转移到指向某个可用CRDB实例的其他数据中心。这为应用程序的读写提供了不间断的可用性，甚至当用户的本地CRDB实例关闭时也是如此。

在极少数情况下，CRDB实例可能会经历完整的数据丢失，需要从头复制。这种情况需要特殊处理，因为正在恢复的CRDB实例可能已经向它的一些对等节点发送了更新。由于没有进一步的更新，我们不能假设所有的对等点最终会收敛(一些效果消息可能已经被一些对等点接收到，而不是其他的)。在这个场景中，Redis Enter万博体育彩prise实现了一个涉及所有相关CRDB实例的协调机制。一旦协调，恢复实例可以简单地从任何其他副本进行完全同步。

一致性模型

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

对于本地CRDB实例操作，当等待命令实现;否则，操作被归类为具有弱一致性。
对于全局的CRDB操作，强最终一致性(SEC)特征确保任何两个收到相同(无序)更新集的CRDB实例将处于相同的状态，而不需要协商一致的协议。不像最终一致性系统只提供活性保证(即更新最终会被观察到)，证券交易委员会添加一个安全保证。

冲突(免费)决议

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

并发写的结果是可预测的，并且基于一组规则。
应用程序不需要做任何关于并发写的事情(但必须与CRDB“方言”兼容)。
数据集最终会收敛到一个单一的、一致的状态。

如何解决冲突的作品

每个CRDB实例都单独维护一个向量时钟每个数据集对象/子对象。这个矢量时钟在实例级的任何更新操作时被更新，或者当来自另一个CRDB实例的相同对象的另一个更新操作到达时被更新。

在从另一个实例接收更新操作（和向量时钟）时，在每个CRDB实例上单独执行以下过程：

阶段1：分类更新操作

一个接收到的更新操作可以表示(1)一个新更新，(2)一个旧更新，或(3)一个并发更新。

分类算法的工作原理如下:

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

如果:x_vc[b] > x_vc[a] -这是“新”更新
if：x_vc [b]
if：x_vc [b]≸x_vc [a] - 这是一个“并发”更新

其中x_vc [a]是实例a和x_vc [b]的对象x的向量时钟是实例b的对象x的矢量时钟。

阶段2:局部更新对象

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

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

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

在许多并发更新状态案例中，可以根据适用数据类型的属性完全无序地处理更新。这里有一些例子：

当数据类型是Counter(映射到CRDT的Counter)时，所有操作都是换诗和无冲突。例子:柜台跟踪各地区的文章人气，股票或转发。
设置数据类型（映射到已删除的CRDT的Add-Win）并且并发更新是添加操作的，所有操作要么associa t 我有或Idempotent.并且是无冲突的。例子:在欺诈检测中，当应用程序正在跟踪与ID或信用卡相关的可疑事件时。如果达到阈值，则使用与ID或信用卡相关联的Redis集基主触发警报。
当数据类型是哈希（映射到CRDT的地图）并且并发更新在散列的不同字段上时，所有操作都存在冲突，就像它们在不同的对象上实现。例子:多个用户共享的企业账户，使用不同地点或不同费率的计划。每个帐户的HASH对象可以包含每个用户无数的字段，并且单个用户的使用可以在没有冲突的情况下更新，即使在并发时也是如此。

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

流程2：使用最后写入胜利（LWW）机制冲突解决

在非冲突无数据类型并发更新的情况下，如Redis String(映射到CRDT的寄存器)，应该应用冲突解决算法。我们选择使用LWW方法来解决这种情况，利用操作时间戳作为平局的决胜因素。

请注意，我们的解决方案以强的最终一致方式工作，即使区域之间存在时间戳倾斜。例如，假设实例A的时间戳总是领先于其他实例的时间戳(例如，在平局的情况下，实例A总是赢)。这确保了行为最终是一致的。例子:对于由多个地理上分布式实体访问的用户帐户更改了密码。在这种情况下，更改将导致日志记录其他用户，这可能是许可证实施方案的正确行为。