3. 灾备架构概述：主备、双活、多活架构下的缓存部署模式
在平台门户的灾备体系中，缓存层（Redis / Redis Cluster / 自研 KV）的部署模式直接决定了故障切换速度、数据一致性等级与整体吞吐能力。不同灾备架构对缓存的读写路径、同步机制、故障转移策略有本质差异。本节从主备、双活、多活三种典型架构出发，分析缓存层的部署模式与通信机制。
3.1 主备架构下的缓存部署
主备（Active-Standby）是最基础的灾备模式，缓存层通常采用 一主一从 或 一主多从 的复制拓扑。主节点承载全部读写流量，备节点实时同步数据，仅在主节点故障时提升为新的主节点。
关键特征： 主节点写入后异步或半同步复制到备节点；故障切换由哨兵（Sentinel）或编排工具（如 Keepalived + VIP）触发；切换期间存在秒级不可用窗口。
3.1.1 部署拓扑与数据流
3.1.2 主备模式适用场景与局限
| 维度 | 说明 |
|---|---|
| 适用场景 | 中小规模门户、成本敏感、允许秒级故障切换、RPO 容忍异步复制丢失 |
| RPO | 异步复制下可能丢失最近写入（秒级数据）；半同步复制可降至接近零 |
| RTO | 哨兵自动切换 5~15 秒；手动切换 1~5 分钟 |
| 缓存一致性 | 主备切换后，旧备节点可能缺失部分数据，需配合缓存预热或惰性加载 |
| 资源利用率 | 备节点仅承担只读或空闲，资源浪费约 50% |
避坑提示： 主备架构下，如果应用层直接连接主节点 IP，故障切换后需要更新连接配置。务必使用 VIP + Keepalived 或 Sentinel + 客户端哨兵感知 模式，避免手动修改连接字符串。
3.2 双活架构下的缓存部署
双活（Active-Active）模式下，两个数据中心同时承担读写流量，缓存层需要在两地之间保持数据最终一致。常见的部署方案包括 Redis 双向复制 和 CRDT（Conflict-free Replicated Data Types） 缓存。
3.2.1 双向复制与冲突处理
Redis 原生不支持双向复制，通常通过中间件（如 Redis Enterprise、自研 Proxy）或 CRDT 改造实现。写入任一中心的数据会异步同步到对端，遇到写冲突时采用 最后写入者获胜（LWW） 或 自定义合并策略。
3.2.2 双活缓存的关键挑战
- 写冲突： 同一 Key 在两地同时写入，需定义合并策略（LWW / 增量合并 / 业务自定义）。
- 同步延迟： 跨数据中心网络延迟（通常 10~50ms）导致数据短暂不一致，需业务层容忍。
- 环路复制： 防止 A→B→A 的无限循环，同步代理必须携带源标记或 TTL 防环。
- 数据一致性等级： 双活缓存通常只能保证 最终一致性，不适合强一致性场景。
工程建议： 双活缓存适合 用户会话、商品详情、配置信息 等允许最终一致的数据。对于库存、余额等强一致数据，建议采用 主备 + 分布式锁 或 全局一致性协议。
3.3 多活架构下的缓存部署
多活（Multi-Active）架构在三个及以上数据中心同时提供读写服务，缓存层需要更复杂的 分布式一致性协议 或 无冲突数据类型（CRDT） 支持。典型方案包括 Redis Enterprise 多活（CRDB）、DynamoDB 全局表 以及自研的 一致性哈希 + 异步复制 方案。
3.3.1 多活缓存拓扑
3.3.2 多活缓存一致性模型
| 一致性模型 | 实现方式 | 适用场景 |
|---|---|---|
| 最终一致性 | CRDT / 异步复制 + 冲突合并 | 用户资料、商品信息、配置 |
| 因果一致性 | 向量时钟 + 版本向量 | 社交动态、评论系统 |
| 读己之写 | 会话粘滞 + 本地优先读取 | 购物车、用户会话 |
| 强一致性 | 全局 Paxos / Raft（性能代价高） | 库存扣减、金融交易（通常不放在缓存层） |
3.4 三种架构对比总结
| 维度 | 主备 | 双活 | 多活 |
|---|---|---|---|
| 数据中心数 | 2 | 2 | ≥3 |
| 读写能力 | 单点读写 | 两地同时读写 | 多地同时读写 |
| RTO | 5~15 秒 | <1 秒（客户端切换） | <1 秒（路由切换） |
| RPO | 秒级数据丢失 | 接近零（冲突合并） | 接近零（CRDT） |
| 一致性 | 强一致（主节点） | 最终一致 | 最终 / 因果一致 |
| 部署复杂度 | 低 | 中 | 高 |
| 资源利用率 | 50% | 100% | 100% |
| 典型缓存方案 | Redis + Sentinel | Redis Enterprise CRDB | Redis CRDB / 自研 CRDT |
选型建议：
- 业务对 RTO < 10秒、RPO 可容忍秒级丢失 → 主备 + Sentinel 即可。
- 需要 两地同时读写、RTO < 1秒、允许最终一致 → 双活 CRDB。
- 全球多区域部署、用户就近接入、数据冲突可合并 → 多活 CRDT 方案。
- 强一致性缓存需求 → 优先考虑主备 + 分布式锁，或直接使用数据库层保证。
3.5 缓存巡检在灾备架构中的关注点
无论采用哪种灾备架构，缓存命中巡检都需要针对不同部署模式调整监控指标与巡检策略：
- 主备架构： 重点巡检主节点内存碎片率、备节点复制延迟（Replica Lag）、哨兵健康状态。
- 双活架构： 增加冲突率（Conflict Rate）、同步队列积压、跨中心网络延迟。
- 多活架构： 关注全局时钟偏差、CRDT 合并效率、版本向量膨胀情况。
- 通用指标： 缓存命中率、逐出率（Eviction Rate）、过期 Key 占比、连接数水位。
巡检自动化建议： 将上述指标纳入 Prometheus + Grafana 监控面板，设置多级告警阈值。例如：主备复制延迟 > 5 秒触发 Warning，> 30 秒触发 Critical；双活冲突率 > 1% 触发检查。