cache aside 模式无法解决高并发缓存不一致，延迟双删需设合理延时（≥主从延迟p95与读接口p99之和+100ms）、异步执行且辅以ttl、版本校验或分布式锁兜底。
Cache Aside 模式本身不能解决高并发下的缓存不一致问题，延迟双删也不是万能补丁——它只在特定并发窗口下有效，且必须配合合理的延时和异步执行，否则反而引入阻塞或失效。
Cache Aside 写操作为什么还会脏数据
很多人以为「先更新 DB，再 delete 缓存」就万事大吉，但实际线上常出现：缓存刚删完，另一个读请求就查到旧 DB 数据并写回缓存，而此时更新事务还没提交或主从还没同步。
- 数据库事务未提交 → 读请求查到的是旧快照（尤其在 RR 隔离级别下）
- MySQL 主从延迟 → 从库读到的仍是旧值，写入缓存后变成“合法脏数据”
-
delete是立即生效的，但 DB 更新不是原子广播，中间存在时间差
延迟双删的 delay 值到底怎么设
500ms 不是银弹，它得覆盖「最慢读请求完成 + 主从同步延迟」的上限，否则第二次 delete 就没意义。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
SHOW SLAVE STATUS查当前最大Seconds_Behind_Master，取 P95 值 - 压测典型读接口（含 DB 查询 + 序列化 + 写缓存），记录 99 分位耗时
- 最终
delay至少 = max(主从延迟 P95, 读接口 P99) + 100ms 安全余量 - 千万别写死
delay = 500L；在@DelayDoubleDelete(delay = #{@config.delayTime})这种方式更可控
为什么必须用异步线程做第二次 delete
主线程 sleep 会卡住整个请求响应，吞吐直接掉；而用 CompletableFuture.runAsync() 或 TaskScheduler 延迟执行，才能既保证清理时机，又不伤性能。
- 别在 AOP 切面里写
Thread.sleep(delay)—— 这是反模式，会吃光 Tomcat 线程池 - 推荐用 Spring 的
TaskScheduler：taskScheduler.schedule(() -> redisTemplate.delete(cacheKey), Instant.now().plusMillis(delay)) - 注意：若服务重启，未触发的延迟任务会丢失，对强一致性场景需搭配 Redis Delay Queue 或 MQ 补偿
延迟双删失败时的兜底手段
哪怕 delay 设得再准、异步执行再稳，仍可能因网络抖动、Redis 故障等导致第二次 delete 失败。这时候仅靠策略本身已不可靠。
- 给关键缓存加短 TTL（如 2 分钟），让脏数据自动过期，避免永久不一致
- 在读流程中增加「版本号/时间戳校验」：DB 记录
updated_at，缓存也存一份，读时比对，不一致则强制回源并刷新 - 对核心业务（如订单、库存），改用「更新缓存」而非删除——但必须用分布式锁 + CAS，代价更高
真正难的从来不是写两次 delete，而是判断「什么时候该删」「删了有没有真生效」「删失败了怎么办」——这些边界条件，往往比主逻辑更消耗调试时间。
