3. 缓存基础概念回顾：缓存穿透、击穿、雪崩、一致性、TTL与淘汰策略
在集成测试覆盖缓存冒烟检查之前，必须统一团队对缓存核心故障模式与治理手段的认知。本章从五个关键维度展开：缓存穿透、缓存击穿、缓存雪崩、缓存一致性以及TTL与淘汰策略。这些概念是设计冒烟检查用例的理论基础。
3.1 三大缓存故障模式
缓存穿透、击穿、雪崩是缓存层最常见的三类故障，其成因、影响范围与应对策略各不相同。下表从定义、典型场景与检查要点三个维度进行对比：
| 故障模式 | 定义 | 典型场景 | 冒烟检查要点 |
|---|---|---|---|
| 缓存穿透 | 请求查询一个根本不存在的数据，缓存与数据库均无命中，导致每次请求都穿透到数据库。 | 恶意攻击、非法参数（如 id = -1） | 检查空结果是否被缓存（布隆过滤器或空值缓存） |
| 缓存击穿 | 某个热点 key 在缓存失效的瞬间，大量并发请求同时回源数据库。 | 秒杀商品详情、爆款文章 | 检查热点 key 是否设置逻辑过期或互斥锁 |
| 缓存雪崩 | 大量 key 在同一时间批量失效，或缓存节点宕机，导致请求全部落到数据库。 | 缓存服务重启、统一过期时间 | 检查 TTL 是否添加随机偏移、是否启用本地缓存兜底 |
冒烟检查提示： 迁移后的缓存冒烟必须覆盖上述三种场景的防御机制是否生效。例如，使用不存在的 key 发起请求，观察是否触发数据库查询；对热点 key 执行缓存失效操作，观察是否出现回源尖刺。
3.2 缓存一致性
缓存一致性指缓存中的数据与数据库中的数据保持同步的程度。在 OpenAPI 迁移场景中，缓存一致性是冒烟检查的核心关注点之一。根据业务对一致性的容忍度，通常分为以下三种模型：
- 强一致性： 缓存与数据库实时同步，写入后立即读取到最新值。实现成本高，通常依赖分布式事务或同步双写。
- 最终一致性： 允许短暂的不一致窗口，经过一定时间后数据自动对齐。常见实现方式为异步消息队列 + 缓存失效。
- 弱一致性： 缓存数据可能长期落后于数据库，适用于非关键数据（如用户头像、静态配置）。
在冒烟检查中，需要验证缓存更新策略是否正确执行。以下为常见的缓存更新模式对比：
| 更新模式 | 操作顺序 | 一致性风险 | 冒烟检查方法 |
|---|---|---|---|
| Cache Aside | 读缓存 → 未命中读 DB → 写缓存；写 DB → 删除缓存 | 删除缓存与写 DB 非原子，可能读到旧数据 | 并发读写同一 key，验证最终一致性 |
| Read/Write Through | 缓存代理层统一处理读写 | 缓存层故障可能导致数据丢失 | 模拟缓存节点宕机，检查数据完整性 |
| Write Behind | 异步批量写入 DB | 宕机时可能丢失未落盘数据 | 强制 kill 缓存进程，检查 DB 数据是否完整 |
3.3 TTL 与淘汰策略
TTL（Time To Live）控制缓存数据的有效时长，淘汰策略决定缓存空间满时如何驱逐旧数据。两者共同决定了缓存系统的内存利用率与命中率。
3.3.1 TTL 设计原则
- 差异化 TTL： 热点数据设置较短 TTL（如 1~5 分钟），冷数据设置较长 TTL（如 1~24 小时）。
- 随机偏移： 在基础 TTL 上增加 ±10%~30% 的随机值，避免大量 key 同时过期引发雪崩。
- 逻辑过期： 不设置物理 TTL，而是由业务代码在缓存 value 中嵌入过期时间，异步刷新。
3.3.2 常见淘汰策略
| 策略名称 | 淘汰逻辑 | 适用场景 | 冒烟检查关注点 |
|---|---|---|---|
| LRU | 淘汰最近最少使用的 key | 访问模式有明显热点 | 热点 key 是否被错误淘汰 |
| LFU | 淘汰访问频率最低的 key | 访问频率分布不均匀 | 频率统计是否准确 |
| FIFO | 淘汰最早进入缓存的 key | 数据时效性要求高 | 是否淘汰了仍在使用的 key |
| TTL | 淘汰即将过期的 key | 缓存空间紧张 | TTL 设置是否合理 |
冒烟检查建议： 在迁移后的缓存环境中，通过压测工具模拟缓存空间满的场景，观察淘汰策略是否按预期执行，以及是否出现大量缓存 miss 导致数据库压力骤增。
3.4 缓存故障模式与防御机制关系图
下图展示了缓存穿透、击穿、雪崩三种故障模式与对应的防御机制之间的映射关系，帮助理解冒烟检查用例的设计逻辑：
3.5 缓存一致性检查流程
在 OpenAPI 迁移后的冒烟检查中，缓存一致性验证通常遵循以下步骤：
- 准备测试数据： 在数据库中插入一条测试记录，确保缓存中不存在该记录。
- 触发缓存加载： 通过 OpenAPI 查询该记录，触发缓存写入。
- 更新数据库： 直接修改数据库中的该记录（模拟外部系统变更）。
- 验证缓存失效： 检查缓存是否被正确删除或更新（取决于更新策略）。
- 验证最终一致性： 等待预设的同步窗口时间，再次查询 OpenAPI，确认返回最新数据。
常见陷阱： 在缓存一致性检查中，如果缓存更新策略为“先删缓存，再写数据库”，在删除缓存后、写数据库前，另一个线程可能读取到旧数据并重新写入缓存，导致缓存与数据库长期不一致。冒烟检查应覆盖此类并发场景。
3.6 本章小结
缓存穿透、击穿、雪崩是缓存系统最常见的三类故障，分别对应不存在数据、热点 key 失效和批量 key 过期三种场景。缓存一致性模型决定了数据同步的严格程度，TTL 与淘汰策略则控制缓存的生命周期与空间利用率。在后续章节中，我们将基于这些基础概念，设计具体的缓存冒烟检查用例，覆盖迁移后的 OpenAPI 缓存层。