扩容易触发缓存雪崩主因是reshard迁移打破key分布与失效节奏，导致大量key集中过期及请求穿透；须在写入阶段强制采用setex+随机TTL（base_ttl±15%~25% variance），禁用固定TTL与热点key长TTL，迁移期改maxmemory-policy为noeviction，并用--threshold 1细粒度迁移。
为什么扩容时特别容易触发缓存雪崩
不是因为加了机器，而是因为迁移过程打破了原有 key 的分布和失效节奏。Redis Cluster 扩容本质是 reshard：把一部分 slot 从老节点搬走，新节点接管后，这些 slot 下的 key 会重新计算 CRC16 值、映射到新位置——但过期时间不会变，大量原本分散在不同节点的 key，可能因 slot 迁移集中在同一波重建窗口里失效；更糟的是，客户端重连或路由刷新延迟，会导致一批请求打到空的新节点上，直接穿透。
setex + 随机 TTL 是最简单有效的防雪崩手段
别等扩容完成再补救，要在写入阶段就埋下“时间差”。所有业务写缓存的地方，必须把固定 setex 改成带随机偏移的过期策略——这不是可选项，是上线前必须卡住的红线。
-
base_ttl设为业务能接受的最短有效时间（比如 30 分钟），variance至少取 base_ttl 的 15%～25%，避免偏移太小失去意义 - PHP 示例中用
random_int(base_ttl - variance, base_ttl + variance)，不要用rand()（PHP 7.2+ 已弃用） - Java 用户注意：Spring Data Redis 的
opsForValue().set(key, value, Duration.ofSeconds(ttl))中 ttl 必须是运行时计算值，不能写死 - 切忌对热点 key 单独设置长 TTL 而不加随机——它反而会成为雪崩后的“压力放大器”，因为所有请求都挤在它过期那一刻回源
迁移期间禁用被动淘汰，改用主动驱逐 + 内存水位预控
扩容窗口内，maxmemory-policy 如果还设成 allkeys-lru 或 volatile-lru，等于给雪崩加火药。节点内存陡增时，LRU 会批量踢掉大量 key，而这些 key 很可能刚被迁入、还没来得及被访问，导致无效淘汰 + 重复回源。
- 临时将 policy 改为
noeviction，靠应用层控制写入节奏，配合监控used_memory_peak_human提前告警 - 用
redis-cli --cluster rebalance时加--threshold 1参数，强制细粒度迁移（每次只搬少量 slot），避免单次操作引发大批 key 重哈希失效 - 新节点上线后，用
redis-cli -h 新节点IP info memory | grep mem确认mem_fragmentation_ratio
客户端路由刷新必须同步触发，不能依赖超时重试
Cluster 扩容后，MOVED 和 ASK 重定向响应会激增。如果客户端像 Jedis 或 Lettuce 没配置 refreshPeriod 或没调用 clusterRefresh，就会持续把请求发到旧节点，造成缓存 miss 率飙升、DB 压力集中——这本质上就是一次人为制造的雪崩。
- JedisCluster 初始化时必须传
new HostAndPort("host", port)列表，并启用new JedisPoolConfig()中的setTestOnBorrow(true)，否则连接池无法感知节点变更 - Lettuce 推荐使用
RedisClusterClient.setOptions(ClusterClientOptions.builder().autoReconnect(true).build())，并监听ClusterTopologyChangedEvent主动 reload - 严禁在扩容期间使用
redis-cli --cluster call批量执行命令——它不走集群路由逻辑，可能绕过 slot 映射，误删/误写 key
真正难的不是技术方案，是把「随机 TTL」落到每个写缓存的代码分支里，把「路由刷新」嵌进所有服务的启动生命周期中。漏掉一个点，雪崩就可能从那个缺口灌进来。
