单靠Redis读写分离无法支撑百万级读QPS，因其本质依赖网络IO导致延迟升高、主从同步存在数据滞后风险、节点故障无法自动剔除、热点key易打爆单个slave且无本地兜底。
单靠 Redis 读写分离扛不住百万级读 QPS，必须叠加本地缓存才能把延迟压到微秒级、把 Redis 调用量砍掉 90% 以上。
为什么不能只靠 Redis 读写分离？
Redis 主从架构确实能提升读吞吐（加 slave 就能线性扩容读能力），但本质仍是网络 IO：哪怕内网 RTT 0.2ms，10 万 QPS 下排队+序列化开销也会让 P99 延迟跳到 5ms+。更关键的是——主从同步有延迟，从节点可能读到过期数据；一旦 Redis 集群抖动或网络分区，整个缓存层就不可用。
-
redis-cli --cluster check显示FAIL状态时，所有依赖 Redis 的业务都会降级 - 从节点故障不会自动剔除，客户端若没做健康检查，会持续往挂掉的 slave 发请求
- 单个 key 热点（如秒杀商品）打爆一个 slave，无法靠本地内存兜底
Caffeine + Redis 读写分离的典型组合方式
本地缓存不是简单加一层，它得和 Redis 的读写路径对齐，否则数据不一致风险极高。核心原则是：写操作走 Redis 主节点并触发本地缓存失效，读操作优先查本地缓存，未命中再查 Redis 从节点。
- 写流程：
updateUser()→ 写 Redis 主节点 → 发送失效消息（如 Canal / Redis PubSub）→ 各服务实例调用cache.invalidate("user:123") - 读流程：
getUser(123)→ 查CaffeineCache.getIfPresent("user:123")→ 命中则返回 → 未命中则走redis.readFrom(SLAVE).get("user:123")→ 回填本地缓存（注意设合理expireAfterWrite） - 本地缓存容量必须硬限制，比如
maximumSize(10000)，避免 OOM；推荐用recordStats()监控hitRate，低于 0.85 就要调参
读写分离下本地缓存的三个易踩坑点
很多团队在 Redis 配了 slave-read-only yes、本地缓存也上了，结果还是出现脏读或雪崩——问题往往出在细节没对齐。
- Redis 从节点同步延迟未监控：
INFO replication中的master_repl_offset和slave_repl_offset差值超过 1000，说明从节点已滞后，此时不应将流量切过去；建议用redis-cli -h $slave -p $port info replication | grep offset定期巡检 - 本地缓存未区分「空值」和「未命中」：
getIfPresent返回null时，你没法判断是 key 不存在，还是查 Redis 失败导致没回填；应统一用get(key, k -> loadFromRedis(k))，由 Caffeine 控制加载逻辑 - 缓存穿透没兜底：恶意请求
user:-1这类非法 ID，本地缓存不存，Redis 也不存，每次都会击穿到 DB；必须在本地缓存层拦截，比如用布隆过滤器预判 key 是否合法，或对空结果也缓存 2 分钟（cache.put("user:-1", Optional.empty())）
高可用链路中谁该负责熔断和降级？
本地缓存不是保险丝，它只解决「快」的问题；真正扛住 Redis 故障的，是分层熔断策略。
- 当
redis.readFrom(SLAVE)连续超时 5 次，应主动标记该 slave 不可用，并触发cache.refreshAll()强制本地缓存按旧 TTL 续命（别清空） - Redis 全链路失败时，本地缓存不能直接清空——要保留「陈旧但可用」的数据，靠
refreshAfterWrite异步刷新，而不是阻塞式重载 - 最危险的是写链路：如果
writeToMaster失败，本地缓存必须立即失效（不能等异步消息），否则下次读会拿到脏数据；这是强一致性要求，绕不开
本地缓存和 Redis 读写分离不是简单拼凑，而是要让它们在失效时机、加载逻辑、错误响应上咬合得严丝合缝。最容易被忽略的，其实是「缓存空值」的处理粒度和「从节点延迟」的实时感知——这两点一松动，整个多级加速层就会从性能引擎变成一致性黑洞。
