@Cacheable会读到旧数据，是因为Spring Cache默认只连单个Redis节点（主或从），不感知主从拓扑；若读请求命中未同步完成的从节点，且无读写路由控制，就会返回过期数据。
直接说结论：Spring Boot 应用本身不感知 Redis 主从拓扑，所谓“处理主从延迟”，本质是绕过从节点读取、或让读请求知道“此刻该不该信任从节点”。不能靠 RedisTemplate 自动识别主从，得自己加控制逻辑。
为什么 @Cacheable 会读到旧数据
Spring Cache 抽象层（比如 @Cacheable）默认只对接一个 RedisCacheManager，背后连的是单个连接池——你配置的是主节点地址，还是从节点地址，它根本不管。如果你手动做了读写分离（比如用 JedisPool 分开配 master/slave），但没在业务代码里显式路由，@Cacheable 仍可能命中某个旧数据的从节点缓存。更常见的是：你把 Redis 当作纯缓存用，却把读请求发到了刚写完还没同步的从节点上。
常见错误现象：
- 用户提交订单后立刻查订单列表，看到“待支付”状态（实际已支付）
- 商品价格更新后前端刷新页面，仍显示旧价
- 后台改了用户权限，前端菜单没变，重登才生效
用写后标记 + 读前校验强制走主节点
核心思路：写操作发生时，在 Redis 里记一个短期标记；读操作发起前先查这个标记，存在就跳过从节点，直连主节点查库或查缓存。
标记 key 格式必须唯一可推导，推荐：write:db:user:1001（含义：user 表主键为 1001 的记录刚被写过）；过期时间设为略大于主从平均延迟，比如 1200 毫秒。
实操建议：
- 写操作后，用
redisTemplate.opsForValue().set("write:db:user:1001", "1", Duration.ofMillis(1200)) - 读操作前，先
redisTemplate.hasKey("write:db:user:1001")，返回true就不走@Cacheable，改用JdbcTemplate直连主库查 - 避免用全局开关（如“最近1秒有写”），粒度太粗，会误伤大量无关读请求
- 标记 key 不要带业务值（比如价格、状态），只保留“谁被写了”的事实，否则失效逻辑难维护
WAIT 命令不是万能的，慎用于高并发写场景
WAIT 是 Redis 原生命令，要求写操作在返回前，至少同步到 N 个从节点。Spring Data Redis 通过 execute() 调用原生命令可接入：
redisTemplate.execute((RedisCallback<Long>) connection -> {
connection.set("user:1001".getBytes(), "new_data".getBytes());
return connection.waitReplicas(1, 500); // 等 1 个从节点，超时 500ms
});
但它有明显限制：
- 超时即失败，
WAIT返回 0 表示未达成，你得自己重试或降级，不能当同步屏障用 - 主节点写入吞吐会下降，尤其在从节点网络抖动时，所有写请求卡在
WAIT - Spring Boot 默认连接池不支持 WAIT 的语义透传，需手动获取
RedisConnection，无法和@Transactional自动集成 - 仅对当前命令生效，不保证后续读请求一定读到——如果读请求发给了另一个还没同步的从节点，照样脏读
真正关键的其实是读路径的可控性
很多团队花大力气调 repl-backlog-size 或上哨兵，却忽略最简单的事实：你根本没控制住读请求发给哪个节点。Spring Boot 应用里，RedisTemplate 连的是单个地址；Jedis/Lettuce 客户端若配了多个地址，默认是轮询或随机，不会自动避开滞后从节点。
容易被忽略的点：
- 别指望客户端自动做延迟探测——Lettuce 的
ReadFrom策略（如READ_FROM_REPLICA_PREFERRED）只管选节点，不校验数据新鲜度 - 应用层做“读己之写”保障，必须绑定上下文：比如把标记 key 和用户 session ID 关联，或用 ThreadLocal 记录本次请求涉及的写 key 集合
- 如果业务允许最终一致性，就别强行兜底；频繁触发 fallback 主读，说明架构设计和业务预期不匹配
