为什么Spring Boot更新数据库后Redis延时双删依然出现脏数据-Redis-PHP中文网

延时双删无法解决缓存与数据库一致性根本问题，因第二次删除无法覆盖“旧值回填”盲区；错误在于读请求在主从同步延迟或事务未提交时查库写入旧值，删缓存后仍循环脏读。

为什么spring boot更新数据库后redis延时双删依然出现脏数据

延时双删不是“加个定时器就万事大吉”，它解决不了根本问题：缓存删除和数据库更新之间依然存在竞态窗口，且第二次删除的时机无法精确对齐主从同步延迟或读请求回填行为。

为什么延迟500ms后删第二次还是读到旧数据？

这不是延时时间设短了，而是你误判了脏数据产生的真正路径。典型错误时序是：

线程A执行 updateProduct()：先删缓存 → 更新DB → 启动500ms延迟任务准备二次删
线程B在A删完缓存但DB尚未提交（或刚提交）时发起读请求：redisTemplate.opsForValue().get(key) miss → 查DB拿到**旧值**（因为A事务还没commit，或主从同步未完成）→ 写入缓存
500ms后A的延迟任务执行 redisTemplate.delete(key)，但此时缓存里已经是B写入的旧值，删掉后下一次读又会重复这个过程

关键点：第二次删除不解决“旧值回填”问题，只清掉可能残留的中间态；而B写入旧值发生在A事务提交前/主从同步前，这是延时无法覆盖的盲区。

Spring中`TransactionSynchronizationManager.registerSynchronization()`没用对

很多人以为注册了事务同步回调就高枕无忧，但常见错误包括：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

回调里直接调用 redisTemplate.delete(key)，但该操作可能走的是连接池中未绑定事务的连接，导致删的是另一个Redis实例（集群下尤其明显）
用了 @CacheEvict 注解却没配 key = "product:{#command.productId}" 这种带哈希标签的格式，导致Cluster模式下key分散在不同slot，DEL 命令只命中部分节点
事务传播行为是 REQUIRES_NEW 或嵌套事务，registerSynchronization() 注册的回调不会触发

正确做法是：在 afterCommit 回调中，用同一个 RedisConnection 实例（或确保Lettuce client配置了 ClusterClientOptions.builder().maxRedirects(5).build()）执行 delete，并显式指定key哈希标签。

延迟双删掩盖了更关键的问题：读请求的缓存回填逻辑本身有缺陷

看你的读方法：

if (cache != null) {
    return cache;
}
Product product = productMapper.selectById(productId); // ← 这里查的是从库？
redisTemplate.opsForValue().set(key, product, 10, TimeUnit.MINUTES);

如果 productMapper.selectById() 走的是MySQL从库，而更新操作写的是主库，那么即使DB已提交，从库延迟也会让读请求拿到旧值并写入缓存——这时无论删几次都没用。你应该：