4. 缓存策略基础：四种核心模式
在集成测试中验证缓存一致性，首先需要理解应用程序与缓存系统之间的交互模式。不同的缓存策略决定了数据何时写入缓存、何时回源数据库，以及缓存与数据库之间可能出现的不一致窗口。本章详细剖析四种经典缓存模式：Cache-Aside、Read-Through、Write-Through 和 Write-Behind，并给出每种模式在 PostgreSQL 集成测试中的关注点。
4.1 Cache-Aside（旁路缓存）
Cache-Aside 是最常用的缓存模式，应用程序代码显式管理缓存的读取和写入。读取时先查缓存，未命中则回查数据库并填充缓存；写入时先更新数据库，再使缓存失效或更新缓存。
核心流程：
- 读请求：检查缓存 → 命中则直接返回；未命中则查询数据库 → 将结果写入缓存 → 返回数据。
- 写请求：更新数据库 → 使缓存失效（或更新缓存）。
集成测试要点：Cache-Aside 模式下，测试必须覆盖“缓存未命中→回填”和“写后缓存失效”两个关键路径。特别注意并发写请求可能导致缓存与数据库的短暂不一致，测试应验证失效操作的原子性。
4.2 Read-Through（通读缓存）
Read-Through 模式将缓存层抽象为一个代理，应用程序只与缓存交互。当缓存未命中时，缓存组件自动回查数据库并填充缓存，对应用透明。应用无需编写回源逻辑。
| 特性 | Cache-Aside | Read-Through |
|---|---|---|
| 回源逻辑归属 | 应用程序 | 缓存层（如 Redis、Memcached） |
| 代码侵入性 | 高，需显式管理缓存 | 低，应用只读缓存 |
| 缓存一致性控制 | 灵活，可自定义失效策略 | 依赖缓存提供商的实现 |
| 集成测试关注点 | 验证应用层缓存逻辑 | 验证缓存层回源行为 |
测试陷阱：Read-Through 模式下，如果缓存层回源时数据库连接超时或返回错误，缓存层的行为可能因实现而异（返回旧数据、抛出异常或阻塞）。集成测试必须覆盖这些异常路径，确保应用层有合理的降级策略。
4.3 Write-Through（通写缓存）
Write-Through 模式要求每次写操作同时更新缓存和数据库，且缓存层保证写入数据库成功后才返回成功。这种模式牺牲了部分写性能，但能保证缓存与数据库的强一致性。
关键特征：
- 写操作必须等待数据库确认后才返回。
- 缓存始终与数据库保持同步，读操作几乎总是命中缓存。
- 适合读多写少且对一致性要求极高的场景。
集成测试策略：Write-Through 模式下，测试应重点验证“缓存写入失败但数据库写入成功”或“数据库写入失败但缓存写入成功”的异常场景。理想情况下，缓存层应实现事务性写入，保证两者要么都成功，要么都回滚。
4.4 Write-Behind（写后缓存 / 回写缓存）
Write-Behind 模式允许写操作先更新缓存，然后异步批量写入数据库。这种模式提供最高的写性能，但引入了数据丢失和一致性问题。
| 对比维度 | Write-Through | Write-Behind |
|---|---|---|
| 写入延迟 | 高（等待数据库确认） | 低（仅更新缓存） |
| 数据一致性 | 强一致 | 最终一致 |
| 数据丢失风险 | 低 | 高（缓存宕机时丢失未落盘数据） |
| 适用场景 | 金融交易、库存扣减 | 日志收集、计数器、社交点赞 |
| 集成测试重点 | 事务回滚、超时处理 | 异步落盘、数据最终一致性校验 |
测试挑战：Write-Behind 模式下，集成测试需要模拟缓存宕机、异步队列积压、数据库连接中断等场景，验证数据最终是否一致。建议在测试中引入“延迟断言”机制，等待异步落盘完成后再校验数据库状态。
4.5 四种模式对比总结
| 模式 | 读性能 | 写性能 | 一致性 | 实现复杂度 | 典型场景 |
|---|---|---|---|---|---|
| Cache-Aside | 高（命中时） | 中 | 最终一致 | 中 | 通用 Web 应用 |
| Read-Through | 高（命中时） | 中 | 最终一致 | 低（应用侧） | 内容管理系统 |
| Write-Through | 高 | 低 | 强一致 | 中 | 金融、库存 |
| Write-Behind | 高 | 极高 | 最终一致 | 高 | 日志、计数器 |
选型建议：在集成测试驱动的缓存一致性校验实践中，推荐优先使用 Cache-Aside 模式，因为它对测试最友好——缓存逻辑显式暴露在应用代码中，便于注入故障、模拟延迟和验证状态。Write-Through 和 Write-Behind 模式虽然性能或一致性更优，但测试时需要更复杂的 mock 和异步等待机制。