灾难恢复架构

灾难恢复复制组的组成方式:由谁声明链接、数据流向哪个方向,以及在每种 Redis 拓扑中代理位于何处。有关复制引擎本身——Oplog、全量和增量同步、端口以及 Service ID——请参阅简介。

单向声明的链接

灾难恢复模式中的成员关系是声明的,而不是发现的。每条链接都是一个 ActiveRedisConnection,在下游数据中心创建,并指定上游的代理地址。不会推断任何信息:实例只会从明确告知它的上游进行复制,不会从其他实例复制。

  • 下游发起连接。下游连接上游的代理,然后拉取上游的 Oplog 并在本地应用。上游从不向外拨号,这也是为什么设置时公开的是上游代理,而不是下游代理。
  • 一个实例最多持有一个上游连接。相比之下,一个上游可以向多个下游扩展连接,从而形成星型拓扑。
  • 扇出上限由 Service ID 范围决定:当 service_id 位于 [0-15] 中时,一个复制组最多包含 16 个成员,因此单个上游最多可以为 15 个下游提供数据。

由于链接是声明的,故障后提升下游同样是一个声明的操作——删除指向故障上游的连接,该实例就会变为独立实例。不会有任何实例自行提升。请参阅故障转移。

部署架构

以下示意图展示了一个生成变更的上游实例,以及两个接收这些变更的示例下游实例。紫色箭头表示从上游流向下游的复制数据;下游发起连接到上游代理。每个实例都部署了一个复制代理,但在此拓扑中,下游的本地代理不在其传入数据路径上。

在每个数据中心内,Primary 和 Replica 描述本地 Redis 角色。下游主节点接收跨数据中心的变更,并将这些变更复制到其本地从节点;在图示拓扑中,应用写入仍在上游执行。复制模块在 Redis 进程内部运行。RDB 表示本地快照,Oplog 表示模块的操作日志。故障转移中所述的本地自动故障转移和手动灾难恢复切换是相互独立的操作。

Redis 哨兵模式部署架构

对于哨兵模式,代理将传入的复制请求路由到当前主节点。Sentinel 为主节点-从节点组提供监控和本地故障转移功能。此图省略了 Sentinel 监控链接;有关本地拓扑,请参阅哨兵模式。

一个上游代理向两个下游主节点提供数据的哨兵灾难恢复架构,每个下游主节点都配有本地从节点和复制模块

Redis 集群模式部署架构

对于集群模式,代理将每个复制连接路由到请求分片的当前主节点。上游和下游实例必须具有匹配的分片数量和槽位布局。在示例中,分片 A 复制到每个下游的分片 A,B 和 C 也同样如此。共享的紫色路径表示按分片分别建立的连接;上游代理与其主节点之间的普通连线表示后端连接。

每个数据中心包含三个匹配分片、通过上游代理进行复制并执行本地主节点-从节点复制的集群灾难恢复架构

共享的节点详细信息适用于每个主节点和从节点。槽位范围和从节点数量仅用于示例;匹配的布局会在设置期间进行检查。

本地故障转移不会影响的内容

代理负责在本地角色发生变化时保持已声明链接的稳定。跨数据中心链接指向对等实例,而不是某个特定的 pod:代理会将其解析为当前时刻的主节点;在集群模式下,则解析为所请求分片的当前主节点。

因此,一个数据中心内的 Sentinel 或集群故障转移属于本地事件。新主节点开始提供服务后,复制链接会通过同一个代理地址重新建立,并且 ActiveRedisConnection 不会发生变化。这与跨数据中心故障转移不同,后者是对整个下游实例执行手动提升。