延迟双删是更新数据库后立即删缓存、延迟1–5秒再异步二次删除的兜底方案，用于降低高并发下缓存与数据库不一致的窗口期，适用于读多写少、可容忍秒级不一致的场景。
什么是延迟双删，为什么需要它
在高并发场景下，数据库和缓存（如Redis）同时存在时，容易出现数据不一致问题。比如先更新数据库、再删缓存，中间若恰好有读请求命中旧缓存，就会把脏数据重新写入缓存；反过来，先删缓存、再更新数据库，更新失败时缓存为空而数据库有旧值，也会导致不一致。延迟双删就是为应对这类“窗口期”问题提出的折中方案：更新数据库 → 删除缓存 → 延迟一小段时间 → 再次删除缓存。
延迟双删的核心逻辑与关键参数
它的本质不是靠一次操作保证强一致，而是用“二次兜底”降低不一致持续时间。关键在于两次删除之间的延迟时间设置：
- 延迟时长一般设为1–5秒，需略大于业务中“读-回源-写缓存”最慢路径耗时（比如查库+序列化+网络+写Redis），确保第一次删缓存后，可能正在回源的请求已执行完毕
- 延迟不能过长，否则不一致窗口太大；也不能过短，起不到兜底作用
- 第二次删除是异步执行的，推荐用消息队列（如Kafka/RocketMQ）或定时任务触发，避免阻塞主流程
实际落地中的常见陷阱
延迟双删看似简单，但工程实践中容易踩坑：
- 没处理第二次删除失败的情况：应设计重试机制（如消息队列的重投）或记录日志告警，否则兜底失效
- 延迟时间写死在代码里：不同接口读链路耗时差异大，建议按业务维度配置可调延迟（如通过配置中心）
- 误删其他键：第二次删除必须严格复现第一次的key生成逻辑，尤其涉及分片、前缀、序列化方式等，否则可能删错或漏删
- 和分布式锁混用时顺序混乱：如果更新前加了锁，删缓存动作必须在锁内完成第一次删除，否则锁外延迟删可能被并发请求干扰
它适合什么场景，又该何时放弃
延迟双删适用于对一致性要求中等、读多写少、能容忍秒级不一致的业务，比如商品描述、用户资料页、文章元信息等。但它不是银弹：
- 若业务要求强一致（如余额、库存扣减），应优先考虑串行化读写、变更订阅（如Canal监听binlog）、或使用支持事务的缓存系统
- 若写非常频繁，反复删缓存反而增加Redis压力，此时更适合只更新数据库 + 设置缓存合理过期时间（TTL）
- 若读请求极少，或缓存命中率本就很低，延迟双删收益有限，可能纯属过度设计
