缓存旁路模式实践

审校日期：2026-09-05。Cache-Aside 让应用管理数据库与缓存；它本身不保证二者一致。是否使用缓存，取决于允许的陈旧时间、读取负载与失效机制。

一、基本读写流程

读请求先查缓存；未命中时读取数据库，再把结果写入缓存并设置 TTL。更新请求先提交数据库事务，再删除对应缓存，让后续读请求按需重建。

读：缓存命中 → 返回
    缓存未命中 → 查库 → 回填 → 返回
写：数据库事务提交 → 删除缓存

“数据库写成功”应指事务已经提交。在事务提交前删除缓存，其他请求仍可能读到旧的已提交数据并回填。

删除缓存能避免应用同时维护两份完整对象，并减少多个写入方乱序更新缓存的问题。但它不能彻底消除旧数据回填。直接更新缓存也并非永远错误，需要额外的版本校验、顺序或原子性约束。

Redis DEL 的复杂度取决于键数量与值类型；不能笼统说任何删除都是 O(1)。大集合释放可能带来额外耗时，需结合实际数据结构测量。

下面的时间线中，读请求在数据库更新前取得旧值，在删除缓存后才回填：

因此，“先更库后删缓存只会短暂读到旧缓存”遗漏了慢读回填场景。旧值可能保持到过期、再次失效或补偿生效；没有 TTL 和修复机制时，不能保证何时收敛。

在仓库根目录运行：

node --test examples/consistency.test.js

database-first invalidation still permits stale refill 使用 Promise 屏障固定上述时序：先读 old，再写 new 和删缓存，最后允许读请求回填。测试断言后续仍读到 old；测试通过意味着成功复现风险。

第二个测试加入内存中的原子版本检查，阻止旧值回填，后续读取为 new；已经在途的第一个读仍返回 old。生产中把“数据库查版本”和“Redis 写入”拆成两步并不原子，不能直接照搬这个内存判断。实验说明见并发一致性实验。

延迟双删是降低特定竞态概率的手段；固定等待 500ms 无法覆盖无界的暂停或复制延迟。逻辑过期通常主动接受短时间旧值，也不等同于强一致。

不能仅凭 Write-Through 名称就认定它适合强一致业务。先明确需要保证的读写语义，再检查具体实现能否满足。