第 206 题：缓存一致性，Cache-Aside vs Write-Through的取舍？
题目
缓存一致性，Cache-Aside vs Write-Through的取舍？
完整讲解
一、缓存与一致性
缓存：在数据库/存储前加一层高速存储（如 Redis、本地缓存），减轻 DB 压力、降低读延迟。一致性：缓存与 DB 的数据何时一致；若写 DB 后缓存未更新或未失效，会读到脏数据。常见模式有 Cache-Aside 与 Write-Through。
二、Cache-Aside（旁路缓存）
- 读：先查缓存，命中则返回；未命中则查 DB，写入缓存后返回。
- 写：只写 DB，然后删除（invalidate）缓存，不直接写缓存；下次读时未命中再从 DB 加载并回填缓存。
- 优点：实现简单、缓存只存热点、DB 为唯一真实源。缺点：删除缓存与写 DB 非原子，并发下可能出现：写 DB 后、删缓存前，另一请求读了旧缓存并回填，导致一段时间脏读；可通过「先删缓存再写 DB」、延迟双删或分布式锁缓解。
三、Write-Through（写穿）
- 写：先写缓存，再由缓存同步写 DB（或先写 DB 再更新缓存）；读只走缓存，缓存命中即一致。
- 优点：读总从缓存、写路径一致性好。缺点：写必经缓存，写放大会（写少的数据也占缓存）；若缓存与 DB 写非原子，仍有一致性窗口；实现与故障处理更复杂（缓存挂了如何与 DB 对齐）。
四、取舍小结
- 读多写少、可接受短暂不一致 → Cache-Aside 更常见、简单。写多或要求写后读必一致 可考虑 Write-Through，但需接受写放大与实现复杂度。也可混合：热点读 Cache-Aside，关键路径 Write-Through 或加分布式锁/版本号。
面试要点
- 能说清缓存一致性的问题（脏读、失效时机）；能描述 Cache-Aside 的读写流程（读先缓存后 DB、写只写 DB 再删缓存）。
- 能描述 Write-Through：写经缓存并同步 DB；能对比二者优缺点（简单性、一致性与写放大）。
- 能简述 Cache-Aside 的并发脏读与缓解（延迟双删、先删后写、锁）；能给出选型建议。
记忆要点
- Cache-Aside：读先缓存后 DB、写只写 DB 再删缓存；简单但并发可能脏读，可延迟双删/先删后写。
- Write-Through：写经缓存同步 DB；一致性好但写放大、实现复杂；选型看读多写少与一致性要求。