Java中数据库事务无法自动同步Redis缓存，需通过“先更新DB再删缓存”为主、辅以延迟双删、分布式锁、异步补偿及过期兜底等策略实现最终一致。
Java 中事务本身只作用于数据库层面，无法自动延伸到 Redis 缓存。所以“数据库事务 + Redis 缓存”天然不是原子操作，必须靠额外设计来逼近一致性。核心思路不是追求强一致（通常不现实），而是控制不一致的时间窗口、降低发生概率、快速收敛到最终一致。
先更新数据库，再删除缓存（Cache Aside 最佳实践）
这是目前最主流、风险可控、落地成本低的方案。关键不是“更新缓存”，而是“删缓存 + 延迟加载”。
- 写操作：开启数据库事务 → 更新/插入/删除 DB 数据 → 提交事务 → 立即删除对应 key 的 Redis 缓存
- 读操作：查 Redis → 命中则返回；未命中 → 查 DB → 写回 Redis（注意：这步不放在事务内）
- 优势：避免冗余计算（尤其缓存值需多表 join 或聚合）、减少冷数据、失败影响小（删缓存失败可重试，DB 是权威源）
- 风险点：删缓存后、DB 提交前若被并发读，可能把旧值重载进缓存（即“脏读窗口”）
用延迟双删压窄不一致窗口
针对上一方案的并发风险，可在删缓存动作上加一层防护：
- 第一步：在 DB 事务提交前，先删一次缓存（提前清理）
- 第二步：DB 事务成功提交后，延时 100–500ms（依业务 RT 定）再删一次缓存
- 原理：让极短时间内可能已读到旧数据并回填缓存的请求，被第二次删除覆盖
- 注意：延迟时间不能太短（来不及覆盖），也不能太长（影响体验）；可用 ScheduledExecutorService 或消息队列（如 RocketMQ 延时消息）实现
借助分布式锁串行化关键路径
对一致性要求极高（如资金类、库存扣减）且并发写同一 key 的场景，可局部加锁：
立即学习“Java免费学习笔记（深入）”；
- 以业务主键（如 order_id）为锁粒度，使用 Redisson 的 RLock 或 SETNX + Lua 脚本实现
- 流程：获取锁 → 执行 DB 更新事务 → 删除缓存 → 释放锁
- 效果：彻底避免并发写导致的缓存错乱，但会牺牲吞吐量；建议仅用于核心敏感字段，非全量铺开
异步补偿 + 监控兜底
任何方案都无法 100% 避免失败，因此必须有可观测性和自愈能力：
- 记录所有缓存删除失败的日志（含 key、操作类型、时间戳），接入告警（如 ELK + Prometheus + AlertManager）
- 搭建轻量级补偿服务：定时扫描 DB 变更日志（如 MySQL binlog 通过 Canal）、或监听业务 MQ，比对 Redis 中是否存在过期/缺失 key，触发刷新
- 给所有缓存设置合理过期时间（如 30 分钟），作为最终兜底——即使完全没删缓存，也能保证最长 N 分钟后自动回源更新
