读写分离不解决本地缓存一致性问题，但可降低Redis主节点压力；需将读写分离与缓存失效策略解耦，否则易致脏读或雪崩。
直接说结论：读写分离本身不解决本地缓存一致性问题，但能显著降低 Redis 主节点压力；配合 Caffeine 等本地缓存构建多级加速层时，必须把“读写分离”和“缓存失效策略”解耦设计，否则极易出现脏读或雪崩。
Redis 读写分离对多级缓存的实际影响
很多人误以为开启 Redis 读写分离（比如主从 + 从库读）就能自动提升多级缓存性能，其实不然。它只改变 Redis 层面的流量分发，对本地缓存（如 Caffeine）完全无感知——Caffeine 仍由每个应用实例独立维护，不会因为 Redis 读走从库就自动同步或刷新。
真实影响集中在两点：
- 主库写压力下降：更新数据库后执行
DEL操作只发往主库，避免从库被大量删除命令打满 - 从库读延迟风险：若从库存在复制延迟，而本地缓存又未及时驱逐，
GET从库 +putIfAbsent到Caffeine可能写入旧值 - 客户端需显式路由：Spring Data Redis 默认不支持自动读写分离，得用
RedisTemplate配合LettuceClientConfigurationBuilderCustomizer或自定义RedisConnection路由逻辑
Caffeine + Redis 读写分离下的缓存失效陷阱
最典型错误是「删 Redis 就以为本地缓存也失效了」。实际上，DEL key 只作用于 Redis，Caffeine 实例里的对应 entry 还在，下次请求直接命中，返回陈旧数据。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
必须主动驱逐本地缓存，且要注意场景差异：
- 单机部署：调用
caffeineCache.invalidate(key)即可 - 多实例集群：不能只删当前节点的
Caffeine，需借助 Redis 的 Pub/Sub 或 Kafka 广播失效事件，各节点监听后调用invalidate - 写操作后立即读：避免「先删 Redis → 再删本地 → 数据库更新」这种顺序，应严格按「更新 DB → 删 Redis → 广播本地失效 → 删本地」执行，否则中间窗口可能被并发读命中旧本地缓存
如何让读写分离真正适配多级缓存链路
关键不是让 Redis 自动适配本地缓存，而是让整个链路对「读写分离」透明。推荐做法是封装统一的 CacheLoader 和 CacheWriter，把读写路由逻辑收口：
- 读操作：优先查
Caffeine；未命中时，由统一RedisReader决定走主库还是从库（例如：非事务性查询走从库，带版本号校验的读走主库） - 写操作：所有写请求强制走 Redis 主库，并触发失效广播；
Caffeine的加载统一通过CacheLoader.load()回源，不直接操作 Redis 客户端 - 超时控制要分层：Caffeine 设置
expireAfterWrite(10, TimeUnit.MINUTES)，Redis 设置EXPIRE key 300，数据库查出的结果必须带时间戳，防止本地缓存过期后回源拿到已失效数据
真正难的不是配置读写分离，而是让本地缓存失效与 Redis 主从状态、数据库事务边界、网络分区等现实条件对齐。一个没被广播到的 invalidate，可能让某个节点持续返回错误数据数小时——这比慢一点更危险。
