2. 缓存基础回顾：缓存类型、策略与灾备角色
在深入灾备缓存命中巡检之前，必须建立对缓存体系的基础共识。缓存并非单一技术，而是由本地缓存、分布式缓存与CDN构成的层次化加速体系。不同缓存类型在灾备场景下承担的角色截然不同，其失效模式与恢复策略也各有差异。本节从类型、策略与灾备角色三个维度进行系统梳理。
2.1 缓存类型：本地、分布式与CDN
根据数据存储位置与访问范围，缓存可分为以下三类：
| 缓存类型 | 存储位置 | 典型实现 | 访问延迟 | 容量上限 | 灾备敏感度 |
|---|---|---|---|---|---|
| 本地缓存 | 应用进程内/同机内存 | Guava Cache、Caffeine、Ehcache | 纳秒级（<1μs） | 受限于单机堆内存 | 高（进程重启即丢失） |
| 分布式缓存 | 独立缓存集群 | Redis、Memcached | 毫秒级（1-5ms） | 可水平扩展至TB级 | 中（依赖网络与集群状态） |
| CDN | 边缘节点（全球分布） | CloudFront、Akamai、阿里云CDN | 取决于节点距离（10-100ms） | 极大（静态资源） | 低（多节点冗余） |
瓶颈分析视角：本地缓存失效通常由进程重启或GC引发，影响范围小但恢复快；分布式缓存失效（如Redis主从切换）可能导致大面积缓存击穿，是灾备巡检的核心关注点；CDN失效多由DNS或边缘节点故障引起，通常有自动回源机制。
下图展示了三种缓存类型在典型微服务架构中的部署位置与数据流向：
2.2 缓存策略：LRU、TTL与Write-Through
缓存策略决定了数据何时写入、何时淘汰以及如何保持一致性。在灾备场景下，策略选择直接影响缓存重建速度与数据一致性风险。
2.2.1 淘汰策略：LRU（最近最少使用）
LRU（Least Recently Used）是使用最广泛的缓存淘汰算法。当缓存空间满时，淘汰最久未被访问的数据项。Redis 的 allkeys-lru 和 volatile-lru 策略均基于此。
- 优点：实现简单，对热点数据友好，命中率较高。
- 灾备风险：主从切换后，新主节点的LRU状态与旧主不一致，可能导致热点数据被提前淘汰。
- 巡检建议：对比切换前后LRU淘汰次数与命中率变化。
2.2.2 过期策略：TTL（生存时间）
TTL（Time To Live）为每个缓存键设置过期时间，到期后自动失效。这是防止缓存雪崩与数据不一致的关键手段。
- 典型设置：热点数据 5-30 分钟，低频数据 1-5 分钟。
- 灾备风险：批量键同时过期（缓存雪崩）；主从延迟导致过期时间不一致。
- 巡检指标：过期键占比、过期驱逐速率、TTL分布直方图。
2.2.3 写入策略：Write-Through（穿透写入）
Write-Through 策略要求应用在写入数据库的同时，同步更新缓存。与之对应的还有 Write-Behind（异步写回）和 Cache-Aside（旁路缓存）。
| 写入策略 | 写入时序 | 一致性 | 写入延迟 | 灾备适用性 |
|---|---|---|---|---|
| Write-Through | 先写缓存，再写DB | 强一致（同步） | 较高（两次写入） | 适合主备切换场景 |
| Write-Behind | 先写缓存，异步写DB | 最终一致 | 低（仅缓存写入） | 切换时可能丢数据 |
| Cache-Aside | 先写DB，再删缓存 | 弱一致（读时更新） | 低（仅DB写入） | 切换后缓存需预热 |
灾备关键提醒：Write-Through 策略在灾备切换时数据一致性最好，但写入延迟较高；Cache-Aside 是大多数互联网应用的默认选择，但切换后缓存为空，需关注缓存击穿风险。建议在灾备演练中测试不同策略下的缓存重建时间。
2.3 灾备场景下的缓存角色
在灾备架构中，缓存不再仅仅是性能加速器，而是承担了以下三个关键角色：
- 流量缓冲层：当数据库主库故障或网络抖动时，缓存层可以继续服务读请求，防止流量直接压垮后端。此时缓存命中率直接决定系统可用性。
- 状态恢复锚点：分布式缓存（如Redis）通常作为会话状态、分布式锁、计数器等关键状态的存储点。灾备切换后，缓存数据的完整性决定了业务能否无缝恢复。
- 性能基线锚定：灾备切换后，缓存命中率是衡量系统是否恢复至正常性能水平的首要指标。命中率低于阈值通常意味着缓存预热未完成或策略配置异常。
下图展示了灾备切换前后缓存角色的动态变化：
核心结论：灾备场景下，缓存从“性能加速器”转变为“系统生命线”。缓存命中率是灾备切换后第一个需要恢复的指标。巡检时需重点关注：切换后缓存命中率是否在5分钟内恢复到80%以上；缓存键的TTL分布是否合理；是否存在因主从切换导致的缓存数据不一致。