延迟双删删的是第一次更新前删缓存、第二次更新DB后延迟再删缓存；前者防旧缓存命中，后者防主从同步期间脏读写入缓存。
延迟双删到底删的是哪两次？
不是“先删后删”，而是「删缓存 → 更新 DB → 延迟再删缓存」。第一次删是为了让后续读请求触发回源，避免读到旧缓存；延迟第二次删，是为了解决「更新 DB 成功但中间有脏读写入缓存」的问题。
常见错误现象：cache miss 后业务线程查 DB 得到旧值，又写回缓存，导致刚更新的 DB 变成无效状态。
- 延迟时间一般设为
100ms–500ms，需略大于主从同步+应用层读写耗时（比如 MySQL 主从延迟监控值） - 不能用定时任务实现延迟，要用异步消息或带延迟的队列（如 RabbitMQ TTL、Redis
ZSET+ 定时轮询、Kafka 延迟主题） - 如果用
Thread.sleep()或本地定时器，在服务重启/扩容时会丢失延迟任务，直接失效
为什么不用更新缓存而坚持删缓存？
更新缓存看似省事，但多线程下极易产生覆盖写：线程 A 读 DB 旧值、线程 B 已更新 DB 并写新缓存，A 还是把旧值塞进缓存，结果白忙活。
删缓存天然具备幂等性，且规避了「谁负责构造完整缓存对象」的耦合问题——尤其是缓存 value 是多表 JOIN 或含外部 API 调用时。
- 缓存数据结构复杂（如含
user_info+order_summary+coupon_status）时，更新缓存逻辑极易漏字段或错版本 - 删操作对 Redis 压力远低于写，尤其在高并发更新场景下，
DEL比SET更轻量、更可控 - 如果业务要求强一致性（如资金类），删缓存 + 强制读 DB 是更稳妥的选择，比“尽力更新缓存”更可预期
击穿和一致性冲突时，加锁能替代延迟双删吗？
不能。互斥锁（如 SET key val NX PX 30000）只解决单 key 突发穿透，不解决「DB 已更新但缓存未及时失效」这个时间差问题。
典型错误场景：锁保护的是「缓存重建」过程，但没管「DB 更新」和「缓存失效」之间的竞态——比如锁刚释放，另一个线程就查到了旧缓存并返回，此时 DB 其实已经变了。
- 锁只该用在
cache miss后的加载阶段，不是用来串行化所有写操作 - 若在更新 DB 前加分布式锁，会严重拖慢写性能，且锁粒度难设计（按 user_id？按 order_id？锁错了范围照样出问题）
- 延迟双删和互斥锁是正交策略：一个管「写后清理」，一个管「读时重建」，该共存就共存，别互相替代
Redis 删除失败怎么办？重试机制怎么设才不雪崩？
第一次删失败（比如 Redis 瞬间不可用），会导致后续读请求全部打到 DB，可能击穿；第二次删失败，则留下脏缓存风险。但盲目重试可能压垮下游。
关键不是“一定成功”，而是“失败可感知、影响可收敛”。
- 第一次删失败，必须记录日志并告警，同时临时走「强制读 DB + 不写缓存」逻辑（相当于降级），避免缓存污染
- 第二次删失败，建议最多重试
2次，间隔用指数退避（如100ms、300ms），超过则落库标记「待清理」，由后台补偿任务兜底 - 不要在主线程里同步重试，所有重试都应进异步通道，防止阻塞核心链路
真正难处理的永远不是代码怎么写，而是延迟窗口内 DB 主从不一致、网络分区、或是业务方绕过统一 SDK 直连 DB 更新——这些地方没对齐，删十次缓存也没用。
