真实面经题目 · 原创解析
缓存与数据库如何保证一致性？
缓存与数据库如何保证一致性？这道腾讯牛客题的关键是围绕“缓存与数据库一致性”讲清概念、机制、取舍和边界。缓存和数据库通常很难做到强一致，工程上多采用 Cache Aside 并接受短暂最终一致。常见写法是先更新数据库，提交成功后删除缓存；删除失败要有重试、消息补偿或 binlog/CDC 修正。
出现于：腾讯 · 后端开发
01
60 秒回答模板
可以这样回答：缓存和数据库通常很难做到强一致，工程上多采用 Cache Aside 并接受短暂最终一致。常见写法是先更新数据库，提交成功后删除缓存；删除失败要有重试、消息补偿或 binlog/CDC 修正。 读路径先读缓存，未命中查库并回填；写路径以数据库为准，事务提交后删除缓存，让后续读回源加载新值。并发读写可能在删除缓存和回填之间产生脏窗口，因此需要互斥重建、延迟双删、版本号或订阅 binlog 缩小风险。 更新数据库再删缓存能避免缓存长期保存旧值，但删除失败会留下脏数据；先删缓存再更新数据库容易被并发读回填旧值。强一致方案成本高，常需要牺牲性能或引入分布式事务。 不要简单说先删缓存再更新数据库。要说明失败窗口、并发回填、重试幂等、消息可靠性、过期兜底和对账补偿。不同业务对短暂不一致的容忍度决定方案强度。 验证时重点看：关注缓存命中率、脏读投诉、删除失败率、消息堆积、binlog 延迟、回源峰值和数据对账差异。
考点 考点边界
主线 核心机制
易错点 只背延迟双删，没有解释它解决的并发回填窗口。
02
深入解析
考点边界
先区分缓存读写策略、数据库写入顺序、缓存删除/回填时机和异常补偿。缓存一致性题的重点是 Cache Aside、延迟双删、binlog 订阅、互斥重建、回源压力和短暂脏读窗口。 本题对应“缓存与数据库一致性”，核心前提是：缓存和数据库通常很难做到强一致，工程上多采用 Cache Aside 并接受短暂最终一致。常见写法是先更新数据库，提交成功后删除缓存；删除失败要有重试、消息补偿或 binlog/CDC 修正。
核心机制
读路径先读缓存，未命中查库并回填；写路径以数据库为准，事务提交后删除缓存，让后续读回源加载新值。并发读写可能在删除缓存和回填之间产生脏窗口，因此需要互斥重建、延迟双删、版本号或订阅 binlog 缩小风险。 关键证据要落到读写顺序、缓存命中、回源链路、补偿信号，这样才能说明机制为什么能支撑题目结论。如果继续展开，要把写库、删缓存、读缓存、回源、消息补偿和失败重试按时间顺序讲清楚。
关键取舍
更新数据库再删缓存能避免缓存长期保存旧值，但删除失败会留下脏数据；先删缓存再更新数据库容易被并发读回填旧值。强一致方案成本高，常需要牺牲性能或引入分布式事务。 因此要同时看读写顺序、删除失败、并发回填、消息延迟和对账补偿，避免只给单一路径答案。 这些取舍决定了方案在不同输入规模、延迟、内存、并发、泛化或一致性要求下是否仍然成立。
边界风险
不要简单说先删缓存再更新数据库。要说明失败窗口、并发回填、重试幂等、消息可靠性、过期兜底和对账补偿。不同业务对短暂不一致的容忍度决定方案强度。 排查时优先看缓存命中率、回源 QPS、删除失败、binlog 或消息延迟、热点重建和对账差异。 需要特别关注极端输入、数据分布变化、资源不足、并发竞争或观测口径错误带来的退化。修复时要先确认不一致发生在写库、删缓存、并发回填还是异步补偿，再收敛到可重试、可对账的路径。
验证抓手
验证时看缓存命中率、回源 QPS、脏读窗口、删除失败率、binlog/消息延迟、热点 key 重建次数、对账差异和业务读写路径日志。 针对本题，最有价值的验证信号是：关注缓存命中率、脏读投诉、删除失败率、消息堆积、binlog 延迟、回源峰值和数据对账差异。把验证抓手说出来，可以让答案从知识点延伸到缓存读写路径、一致性窗口和补偿验证。
03
易错点
- 只背延迟双删，没有解释它解决的并发回填窗口。
- 承诺缓存和数据库可以简单强一致，忽略跨系统失败和重试问题。
- 把相邻概念混用，没有明确说明这道题真正考察的边界。
- 没有给出验证方式，导致答案听起来完整但无法判断是否真的生效。
04
面试官追问
为什么通常推荐更新数据库后删除缓存？
数据库是权威数据源，先保证数据库提交成功，再删除缓存让后续读加载新值。相比先删缓存，它更能降低并发读把旧值重新写入缓存的风险。
删除缓存失败怎么办？
要有重试和补偿机制，例如本地事务消息、可靠 MQ、binlog/CDC 订阅、定时对账和缓存 TTL 兜底。删除操作本身也要设计成幂等。
“缓存与数据库如何保证一致性”继续追问时最该补哪条边界？
应该围绕“缓存与数据库一致性”补适用前提、失败场景和验证证据。先说明哪些条件下这个机制成立，再说明哪些输入规模、并发状态、数据分布或资源限制会让答案需要调整。
“缓存与数据库如何保证一致性”怎样回答才不是只背概念？
看它能否把“缓存与数据库一致性”的机制链路、关键取舍和可观测信号连起来。回答时应落到具体状态变化、数据路径、复杂度、指标或排查工具，而不是只复述定义。
为什么缓存更新通常更推荐删缓存而不是直接写缓存？
删除缓存可以让下一次读取从数据库加载新值，避免多个写入顺序竞争导致缓存覆盖。直接写缓存更容易被并发旧值覆盖，还要处理复杂的失效和重试。
