update DB → delete cache 是当前 Spring Boot 项目里落地成本最低、出问题概率最小的双写策略，它不追求绝对一致，但能保证绝大多数请求看到的是最新数据。
先更新数据库再删缓存，不是最优解但最稳
直接说结论：update DB → delete cache 是当前 Spring Boot 项目里落地成本最低、出问题概率最小的双写策略。它不追求绝对一致，但能保证绝大多数请求看到的是最新数据。很多人卡在“为什么不能 update cache”，因为缓存值可能来自多字段拼装、关联查询或计算逻辑，直接写缓存容易漏字段、错序列化，反而引入脏数据。
常见错误现象：CachePut 更新后，缓存里是新数据，但数据库事务回滚了，缓存就永久性污染；或者并发更新时，CachePut 写入顺序和 DB 提交顺序错乱，导致旧值覆盖新值。
- 只对「读多写少 + 允许短暂不一致」的业务用
CachePut，比如用户头像 URL、配置项 - 对「状态变更敏感」的场景（订单、库存、账户余额），必须走
CacheEvict删除缓存，让下次读自动重建 - 删除操作要带条件 key，避免误清：比如
@CacheEvict(value = "userCache", key = "#user.id")，别写成allEntries = true
Oracle 主键自增时，CacheEvict 的 key 构造容易错
Oracle 没有 MySQL 那种原生自增主键，通常靠 SEQUENCE + trigger 或 MyBatis 的 selectKey 回填 ID。这意味着：新增记录后，对象的 id 字段才真正有值——但如果你在 @CacheEvict 里直接用 #user.id，而这个 id 还是 null 或 0，那缓存根本删不掉。
正确做法是把 ID 获取逻辑显式暴露出来，例如：
@Insert("INSERT INTO user(name, email) VALUES(#{name}, #{email})")
@SelectKey(statement = "SELECT user_seq.NEXTVAL FROM DUAL", keyProperty = "id", before = true, resultType = Long.class)
void insertUser(User user);
然后在 service 方法里确保 user.getId() 已赋值，再调用删除：
@Transactional
public void createUser(User user) {
userMapper.insertUser(user); // 此时 user.id 已被 selectKey 填充
cacheManager.getCache("userCache").evict(user.getId()); // 手动删，比注解更可控
}
- 别依赖
@CacheEvict自动解析参数，尤其当参数是新建对象且 ID 未生成时 - Oracle 下建议统一用
selectKey或@Options(useGeneratedKeys = true)（需驱动支持），避免 trigger 导致 ID 不可见 - 如果必须用注解，确保方法签名接收的是已含 ID 的对象，比如
updateUser(@Param("id") Long id, @Param("user") User user)
Redis 缓存失效时间要和 Oracle 查询计划绑定
很多人设个固定 time-to-live: 3600 就完事，结果发现：某张表加了索引后查询变快，但缓存还按旧逻辑过期；或者某条 SQL 加了 /*+ FULL(t) */ 强制走全表扫描，响应从 5ms 涨到 800ms，缓存却还在频繁击穿。
缓存 TTL 不是拍脑袋定的，得看实际慢查询阈值。比如你用 Oracle AWR 报告确认：95% 的 SELECT * FROM order WHERE status = ? 耗时 120000（120秒），而不是盲目设 1 小时。
- 用
spring.cache.redis.time-to-live控制全局默认 TTL，但关键接口要用@Cacheable(expire = 120000)覆盖 - 对 Oracle 中经常做
ANALYZE TABLE或统计信息自动收集的表，缓存 TTL 应略短于统计刷新周期（比如统计每 24 小时跑一次，缓存 TTL 设 22 小时） - 如果用了 Oracle 的
RESULT_CACHE，注意它和 Redis 缓存是两层，别让 Redis TTL 远长于 Oracle 自身缓存，否则可能拿到 Oracle 缓存里的旧快照
多节点部署时，本地缓存（Caffeine）和 Redis 同步很脆弱
Spring Boot 默认只配 Redis 缓存，但上线后一加集群，就发现：节点 A 删了 Redis 缓存，节点 B 的 Caffeine 本地缓存还留着旧数据，用户请求打到 B 就看到脏数据。这不是 bug，是设计使然——Caffeine 本身不支持跨 JVM 同步。
解决思路不是禁用 Caffeine，而是控制它的作用域和失效节奏：
- 本地缓存只存「读频极高 + 变更极低」的数据，比如地区字典、系统开关，别缓存用户订单这类动态数据
- Caffeine 的
expireAfterWrite必须设得比 Redis TTL 短，比如 Redis 设 120 秒，Caffeine 就设 60 秒，形成自然衰减梯度 - 不要用
@CacheEvict(allEntries = true)清本地缓存，它只清当前 JVM；真要强制同步，发一个 Redis Pub/Sub 消息，各节点监听后手动cache.invalidateAll()
最易被忽略的一点：Caffeine 的 maximumSize 如果设得太大（比如 10 万），在 GC 压力大时可能触发 full GC，反而拖慢整个节点响应——它不是越大越好，要结合堆内存和热点数据量来压测确定。
