我正在负责一套跨境用户系统，主业务部署在香港，但考虑到自然灾害、运营商链路故障等风险，团队决定同步部署新加坡容灾节点，实现 Redis Cluster 的跨地域冗余与数据延续性保障。挑战在于：Redis Cluster 本身并不天然支持异地高延迟环境，主从间复制机制也未设计为远距离容灾。
为此，我基于官方原生机制和网络层策略，设计了一套兼容 Redis Cluster 架构、适配跨境网络的主从链路复制机制：主 Region 在香港，新加坡作为异地只读副本，支持秒级故障接管与异地查询热备份。
以下是完整的实操部署、同步机制、故障切换与访问策略细节。
一、架构设计：异地容灾的核心思路
Redis Cluster 虽支持多主分片 + 主从复制，但所有主节点必须能彼此连通并快速响应 gossip 协议，对于香港与新加坡这种 30ms 以上 RTT 的链路极不友好。
为此，我们采取主集群 + 异地被动复制集群模式：
- 香港：部署完整 Redis Cluster（含主从）；
- 新加坡：部署等规模 Redis Cluster，作为被动只读备份节点；
- 数据同步：通过自研中间同步桥或定向复制通道完成；
- 读写策略：香港写入，新加坡只读，应用层负载隔离；
- 故障切换：通过自动脚本 + DNS 切换完成主备切换。
图示架构如下：
用户流量
|
DNS（主备感知）
/ \
香港Region 新加坡Region
[Cluster] [Cluster]
主+从节点 主+从节点（只读）
| |
Slot分片 Slot分片（同步副本）
| |
Redis-Sync桥接模块（或单向repl）
二、部署步骤：主集群 + 异地只读集群构建
2.1 香港主 Region 架构
按照标准 Redis Cluster 部署流程，配置如下：
10.0.0.11-13：主节点
10.0.0.14-16：从节点
端口：7000
每个节点均配置为：
cluster-enabled yes
appendonly yes
protected-mode no
cluster-node-timeout 5000
使用官方工具创建集群：
redis-cli --cluster create 10.0.0.11:7000 10.0.0.12:7000 ... --cluster-replicas 1
2.2 新加坡只读集群部署
我们不直接加入香港的 cluster 网络，而是独立部署等结构的 Redis 集群，节点如下：
172.16.0.11-13：主节点
172.16.0.14-16：从节点
配置与主集群一致，但我们人为阻止新加坡集群参与任何 Gossip 传播，将其作为独立可控的冗余环境。
三、数据同步机制：桥接式单向 Slot 同步方案
Redis Cluster 无法原生支持主从集群间的数据桥接，因此我设计了如下同步策略：
3.1 方式一：通过 redis-shake 同步工具
redis-shake 是支持 cluster-to-cluster 结构的桥接同步器，运行在中间层服务器，支持异步复制：
./redis-shake -type=sync \
-source.type=cluster -source.address=10.0.0.11:7000 \
-target.type=cluster -target.address=172.16.0.11:7000 \
-conf.path=./conf/redis-shake.conf
优点：
- 支持 slot 感知，按分片搬运；
- 可在网络中断后自动续传；
- 支持只读同步，避免新加坡端被写入污染。
3.2 方式二：Slot 分组复制 + 自定义 Repl Proxy（自研）
我们也尝试构建 Slot-aware proxy，将每个香港主节点 replicaof 到对应新加坡集群的主节点，但稳定性不如 Shake 工具，最终未采用。
四、客户端访问策略：读写隔离与容灾切换
4.1 正常流量分发
- 香港业务使用原生 Redis Cluster，连接香港主 Region；
- 东南亚与新加坡周边业务接入只读 Region，仅提供状态类读操作；
- 通过 DNS + GeoDNS 实现智能分流，防止写入新加坡端。
4.2 故障切换流程
我们编写如下切换逻辑：
- 香港 Redis 大面积节点宕机；
- 哨兵系统（或 Redis 自检 +心跳）触发；
- DNS 将 redis.myapp.com 指向新加坡集群；
- 临时将新加坡节点切换为可写（readonly no）；
- 后续启动异步“反同步”模块将写回补齐。
五、网络与链路层优化建议
跨境 Redis 同步与访问受限于链路质量，因此我们在网络层也做了如下调整：
5.1 链路加速
使用 BGP Anycast + QUIC Relay 搭建了香港<->新加坡的专线；
RTT 控制在 30ms 以内，Jitter 小于 2ms，保证 redis-shake 同步连续性。
5.2 防火墙配置
确保以下端口放通：
| 端口 | 说明 |
|---|---|
| 7000 | Redis 集群通信 |
| 7001+ | 多节点 Redis 实例端口 |
| 9443 | Redis-Shake 管理接口（可选） |
六、监控与运维机制
6.1 主从一致性监控
我们构建定时对比器：
每分钟抽样 N 条 Slot 的 key 比较值是否一致；
每小时抽样 LRU TOP 100 key 的时序差异；
6.2 redis-shake 监控
- 接入 Prometheus Exporter；
- 监控延迟、断点续传、Slot 失败率。
七、扩展与风险控制建议
| 场景 | 建议解决方案 |
|---|---|
| 新加坡误写入数据 | 加强防火墙，仅开放必要 IP 写权限 |
| redis-shake 丢失 key | 启用 AOF + 定时全量同步做双重保障 |
| 跨地域 RTT 波动 | 引入 QUIC/HTTP3 Relay Tunnel 或 MPLS 专线 |
| 多 Region 同时写入需求 | 使用更强一致性系统如 CRDT Redis / Tendis / Dragonfly |
部署 Redis Cluster 跨地域同步并非简单的“节点复制”，而是一套系统性的 读写隔离、网络加速、状态监控、灾难恢复能力设计 的结合体。在我负责的这套架构中，通过香港主 Region + 新加坡只读 Region 的方式，不仅达成了 可横向扩展 + 异地容灾 + 查询卸载 的目标，也为后续全球多活打下了基础。
