3. 灾备场景下的缓存架构：主备缓存架构、多活缓存架构、分布式缓存一致性

在云原生灾备体系中，缓存层承担着“流量削峰”与“数据加速”的双重角色。一旦缓存节点发生故障或数据中心整体宕机，缓存命中率将急剧下降，直接导致后端数据库被击穿。因此，理解不同灾备等级下的缓存架构模式，是设计高可用缓存巡检策略的前提。

3.1 主备缓存架构（Active-Standby）

主备模式是最基础的灾备缓存架构，适用于单数据中心内的故障转移场景。主节点（Active）承担所有读写流量，备节点（Standby）实时同步主节点的数据，但不对外提供服务。当主节点宕机时，通过哨兵或控制面将备节点提升为主节点。

3.2 多活缓存架构（Multi-Active）

多活架构是跨数据中心灾备的主流方案，每个数据中心都部署独立的缓存集群，所有集群同时对外提供读写服务。多活架构的核心挑战在于“写冲突”与“数据最终一致性”。常见的实现方式包括：

• 无冲突复制数据类型（CRDT）： 每个节点独立写入，通过数据结构保证最终一致。
• 基于消息队列的异步同步： 写入本地后，通过 MQ 将变更事件广播到其他数据中心。
• 全局一致性哈希 + 就近路由： 用户请求路由到最近的数据中心，减少跨地域延迟。

3.3 分布式缓存一致性

无论采用哪种灾备架构，分布式缓存一致性都是巡检的核心指标。缓存一致性主要涉及以下三个层面：

1. 缓存与数据库的一致性： 经典的 Cache-Aside 模式中，更新数据库后需主动失效或更新缓存，避免脏数据。
2. 缓存节点间的一致性： 主备或多活场景下，不同节点上的同一 key 必须保持最终一致。
3. 客户端本地缓存与远端缓存的一致性： 部分应用使用多级缓存（本地堆缓存 + 远端 Redis），需通过版本号或 TTL 保证一致性。

3.3.1 一致性策略对比

3.3.2 一致性巡检指标

在灾备缓存命中巡检中，建议将以下指标纳入巡检看板：

• 缓存与数据库差异率： 抽样对比缓存值与数据库值，差异率应 < 0.1%。
• 跨节点同步延迟： 主备或多活节点间同一 key 的更新时间差，阈值建议 < 2 秒。
• 缓存失效命中率： 因缓存失效导致回源数据库的请求占比，正常应 < 5%。
• 写冲突次数： 多活架构中同一 key 在短时间内被多个数据中心同时修改的次数。

3.4 架构选型决策树

在实际项目中，选择哪种缓存灾备架构取决于业务对 RTO、RPO 和一致性的容忍度。以下决策树可辅助判断：

业务需求：
├─ 是否允许缓存数据丢失？
│   ├─ 是 → 使用 Write-Behind + 主备架构（RPO > 0）
│   └─ 否 → 进入下一层
├─ 是否要求跨地域多活？
│   ├─ 是 → 使用 CRDT 或 MQ 同步的多活架构（最终一致）
│   └─ 否 → 进入下一层
├─ 故障切换时间是否 < 5 秒？
│   ├─ 是 → 使用哨兵 + 主备架构（RTO < 10 秒）
│   └─ 否 → 使用 Redis Cluster 原生故障转移（RTO < 30 秒）