在分布式系统中，缓存与数据库的一致性是核心挑战之一。由于缓存和数据库是独立的存储组件，更新操作的顺序、网络延迟、并发请求等都可能导致数据不一致。项目中通常通过 “先更新数据库，再删除缓存（Cache Aside Pattern）” 的策略保证一致性，同时辅以补偿机制处理异常场景。以下是具体分析：
一、缓存与数据库一致性的核心更新策略：先更 DB 再删缓存
在主流的缓存更新策略中， “先更新数据库，再删除缓存” 是被广泛采用的方案，优于 “先删缓存再更 DB” 或 “更新 DB 后更新缓存”。具体逻辑如下：
- 业务操作先执行数据库更新（确保数据持久化正确）；
- 数据库更新成功后，删除缓存中对应的旧数据；
- 后续请求访问时，因缓存缺失，会从数据库读取最新数据并写入缓存，恢复一致性。
二、为什么选择 “先更 DB 再删缓存”？
对比其他策略的优缺点，该方案的优势更明显：
1. 避免 “先删缓存再更 DB” 的并发不一致问题
若采用 “先删缓存，再更新数据库”，可能出现以下问题：
-
线程 A 先删除缓存，准备更新数据库；
-
此时线程 B 发起查询，发现缓存缺失，从数据库读取旧数据并写入缓存；
-
线程 A 完成数据库更新（新数据），但缓存中已被线程 B 写入旧数据，导致后续查询读到缓存旧数据，与数据库新数据不一致。
这种场景下，不一致的时间窗口较长（从 A 删缓存到 A 更 DB 完成），且难以通过简单机制避免。
2. 避免 “更新 DB 后更新缓存” 的性能与并发问题
若采用 “更新数据库后同步更新缓存”，存在两个核心问题：
- 并发覆盖问题：线程 A 更新 DB 后准备更新缓存，线程 B 同时更新 DB 并先更新缓存，最终缓存可能被 A 的旧更新覆盖，导致缓存与 DB 不一致；
- 性能损耗：缓存更新成本可能很高（如大对象序列化），频繁更新会浪费资源，而 “删除缓存” 是轻量操作，仅在下次查询时才触发缓存重建，更高效。
3. “先更 DB 再删缓存” 的不一致风险极低
该策略的潜在风险是：线程 A 更新 DB 后，尚未删除缓存时，线程 B 读取到缓存中的旧数据。但这种场景的影响范围极小：
- 时间窗口极短：仅存在于 “DB 更新完成” 到 “缓存删除完成” 之间，通常是毫秒级；
- 最终一致性保障：线程 A 后续会删除缓存，线程 B 即使读到旧缓存，下一次查询时缓存已被删除，会从 DB 加载新数据，不一致仅为瞬时状态。
三、异常场景的补偿：如何处理 “删缓存失败”？
“先更 DB 再删缓存” 的最大风险是：数据库更新成功，但缓存删除失败（如网络波动、缓存服务宕机），导致缓存中仍保留旧数据，与 DB 新数据不一致。需通过以下机制补偿：
1. 重试机制
删除缓存失败时，立即发起本地重试（如重试 2-3 次），若仍失败则进入兜底流程。
2. 异步补偿（最终一致性保障）
通过监听数据库 binlog 或本地消息表，异步触发缓存删除，确保即使即时删除失败，后续仍能补删：
- binlog 监听：通过 Canal 等工具订阅数据库 binlog，解析更新操作，当检测到目标表数据变更时，异步调用缓存删除接口；
- 本地消息表：更新 DB 时，同步写入一条 “缓存删除任务” 到本地消息表，通过定时任务扫描未完成任务，重试删除缓存。
四、特殊场景的优化：延时双删
针对高并发场景（如秒杀、热点数据更新），可额外增加 “延时双删” 机制降低不一致概率：
-
先更新数据库；
-
立即删除一次缓存；
-
间隔短暂时间（如 100-500ms，根据业务耗时调整）后，再次删除缓存。
作用：避免线程 A 更新 DB 后删缓存前，线程 B 已读取旧缓存并写入的场景。第二次删除可清除线程 B 可能写入的旧数据。
总结
项目中通过 “先更新数据库，再删除缓存” 作为核心策略，配合重试机制和 binlog 异步补偿保障最终一致性。该方案平衡了性能与一致性，不一致的时间窗口极短，且通过补偿机制可覆盖异常场景，是工业界验证的成熟方案。
