读写分离不能防止雪崩，只能延缓爆发时间、缩小单点故障影响范围；其前提是主从延迟可控且从节点具备兜底能力，盲目增加从节点而不做应用层加固反而可能放大雪崩风险。
读写分离不能防止雪崩，只能延缓爆发时间、缩小单点故障影响范围——前提是主从延迟可控、从节点有兜底能力。盲目加从节点却不做应用层加固，反而可能放大雪崩风险。
为什么从节点读流量会加速雪崩？
常见误判是：「加了从节点 = 读高可用」。实际中，以下情况会让从节点成为雪崩推手：
-
slave_repl_offset停滞时（如全量同步卡住 20 秒），所有从节点返回的都是过期数据，业务仍当作有效值使用，导致大量请求 fallback 到 DB - 哨兵切换期间（10–30 秒），客户端 DNS 缓存或连接池未刷新，部分请求发往已下线的旧主地址，
LettuceConnectionException暴增 - 从节点默认
read_only yes，但没配maxmemory-policy volatile-lru，内存打满后直接READONLY You can't write against a read only slave拒绝新读请求
从节点必须独立配置的三项硬性参数
只在 redis.conf 里加 replicaof 和 slave-read-only yes 远不够。应用层必须显式控制：
- 每个从节点连接池需独立初始化，
maxIdle≥ 主节点，避免高并发下从节点连接耗尽反向拖慢主节点 - 读请求必须包裹超时与 fallback：
stringRedisTemplate.opsForValue().get()抛出LettuceConnectionException后，立即走 Caffeine 本地缓存或默认值，禁止重试 - 监控
evicted_keys指标，突增说明maxmemory-policy不合理或内存不足；建议设为volatile-lru而非noeviction
主从延迟 > TTL/2 时，怎么避免“假过期”穿透？
业务设 key 过期时间为 5 分钟，主从延迟已达 4 分钟，此时从节点读到的 key 实际只剩 60 秒有效寿命。直接返回 null 会触发穿透，返回旧值又违反一致性。折中解法是：
- value 存结构：
{"data": {}, "expireAt": 1757124000000} - 应用读取后判断
expireAt ，若逻辑过期则触发异步更新（用分布式锁防重复） - 不依赖
EXPIRE物理过期，而是靠业务层控制“何时该刷新”，把失效压力从瞬间爆发转为平滑摊销
真正容易被忽略的是：雪崩发生时，你的代码是否还在对不可用的从节点疯狂重试？连接池是否堆积了上千个等待响应的线程？这些细节比加几个从节点更能决定系统生死。
