如何利用Redis集群扩容应对缓存雪崩？

缓存雪崩是大量缓存key同时失效或缓存服务不可用，导致请求直击数据库引发过载甚至宕机；主因包括集中过期、Redis宕机、slot迁移后key分布失衡及客户端路由延迟未及时刷新。

扩容时为什么反而会触发缓存雪崩

不是因为加了机器，而是 redis-cli --cluster rebalance 的 reshard 过程打乱了 key 的分布和失效节奏。slot 迁移后，原本分散在多个节点、不同过期时间的 key，可能被集中到同一新节点上；这些 key 的 EXPIRE 时间没变，但新节点重建 slot 时的访问模式、客户端路由刷新延迟，会让大量请求在同一窗口内打到空缓存上，直接穿透。

写入阶段必须强制使用 setex + 随机 TTL

这不是上线后补救手段，是扩容前必须卡死的红线。所有业务写缓存的地方，setex 的 TTL 必须是运行时计算值，不能写死：

1. base_ttl 设为业务可接受的最短有效时间（例如 1800 秒），variance 至少取 ±15%～25%，即 ±270～450 秒
2. PHP 用户用 random_int(base_ttl - variance, base_ttl + variance)，别用已弃用的 rand()
3. Java 用户在 opsForValue().set(key, value, Duration.ofSeconds(ttl)) 中，ttl 必须是每次调用都重新生成的随机数
4. 切忌对热点 key 单独设长 TTL 而不加随机——它会在过期瞬间变成“压力放大器”

迁移期间 maxmemory-policy 必须切为 noeviction

如果还用 allkeys-lru 或 volatile-lru，内存陡增时会批量踢掉刚迁入却尚未访问的 key，造成无效淘汰 + 重复回源。应：

1. 临时改配置：CONFIG SET maxmemory-policy noeviction
2. 靠应用层控制写入节奏，配合监控 used_memory_peak_human 提前告警
3. 用 redis-cli --cluster rebalance 时加 --threshold 1，强制每次只搬少量 slot，避免单次重哈希引发大批 key 集中失效

别忽略客户端路由刷新延迟这个隐性瓶颈

集群拓扑变更后，客户端未必立刻感知。Jedis、Lettuce 等默认有缓存路由表，若未配置 refreshPeriod 或未监听 MOVED/ASK 重定向，会导致一批请求持续打到旧节点或空节点。检查点包括：

1. JedisCluster 构造时是否传入了 new JedisPoolConfig() 和合理 maxRedirections
2. Lettuce 是否启用了 DynamicNodeTopologyProvider 并设置了 refreshTriggersReconnectThreshold
3. 有没有在日志里高频看到 MOVED 错误但未触发自动重试

这个环节一旦漏掉，再严格的 TTL 随机化和内存策略也挡不住穿透流量。