主从切换本身不会引发雪崩，但新主节点空缓存会立刻触发雪崩；其根源在于未预热、无错峰、缺fallback，需通过事件驱动预热、限速加载热点key、客户端协同降级等策略防控。
主从切换本身不会引发雪崩，但新主节点空缓存会立刻触发雪崩
Redis Sentinel 或 Cluster 的故障转移完成之后，新选举出的主节点内存是空的（除非启用了 RDB/AOF 持久化且数据已加载完毕）。此时所有对原 key 的读请求仍会命中——但全部 miss。客户端若未做降级，就会批量穿透到 DB。这不是主从切换“导致”雪崩，而是它暴露了原有缓存失效逻辑缺陷：没有预热、没有错峰、没有 fallback。
常见错误现象：LOADING Redis is loading the dataset in memory（新主正在加载 RDB，从节点拒绝服务）、TimeoutException 在应用层集中爆发、数据库连接池 wait_timeout 被打满。
预热必须在主从切换完成前或切换窗口内启动，不能等服务“稳定”后再做
等新主节点对外提供写服务、客户端重连完成、健康检查通过之后再开始预热，已经晚了。真实流量会在 2–10 秒 failover 窗口内持续打穿缓存，尤其在高并发场景下，第一批 miss 请求足以压垮 DB。
- 预热动作应由哨兵/集群状态变更事件触发（如 Sentinel 的
switch-master通知），而非依赖定时任务或人工介入 - 预热数据源优先用本地热点缓存快照（如本地 Caffeine 中最近 5 分钟高频 key），而非全量 DB 查询
- 预热需限速：用令牌桶控制 QPS（例如
RateLimiter.create(200.0)），避免预热本身变成对 DB 的 DDoS - 预热失败 key 要记录日志并加入重试队列，但不阻塞整体流程
预热 ≠ 全量刷缓存，关键在“错峰+分级+可中断”
把几百万 key 一股脑塞进新主，既拖慢恢复时间，又可能因内存抖动触发 OOM 或复制延迟。真正有效的预热是带策略的：
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 只预热
hot_key_pattern_*类型的 key（例如product:1001、user:8823），跳过低频或冷数据 - 对每个 key 的过期时间叠加随机偏移（如基础 3600s +
ThreadLocalRandom.current().nextInt(180)），防止预热完成后再次集体失效 - 预热过程支持优雅中断：收到
SIGTERM或健康检查失败时，保存当前进度（如最后成功 set 的 key），下次从断点续跑 - 若预热期间发现 DB 响应延迟 > 200ms 或错误率 > 5%，自动降级为仅加载 top 100 热点 key
别忽略客户端侧的“预热感知”能力
服务端在预热，客户端如果还按老习惯疯狂 get，照样雪崩。必须让客户端知道：“当前缓存不可信”，从而主动启用降级路径。
可行做法包括：
- 在 Redis 连接字符串中嵌入元信息，如
redis://new-master:6379?prewarming=true，客户端初始化时读取并切换行为 - 用一个全局开关 key（如
cache:status:prewarming）配合 TTL，客户端每次 get 前先 check，命中则走本地 fallback 或返回 stale 数据 - FailoverClient 库需支持
OnMasterChanged回调，在回调里广播预热信号，触发本地缓存加载和熔断器重置
最易被忽略的一点：预热不是一次性动作。一次主从切换后若没解决根本问题（比如 key 过期时间仍集中），下一次故障还会复现。随机过期、永不过期热点、多级缓存这三件事，得在业务代码里扎下去，而不是寄希望于运维兜底。
