缓存雪崩是大量缓存key同时失效或缓存服务不可用，导致请求直击数据库引发过载甚至宕机；主因包括集中过期、Redis宕机、slot迁移后key分布失衡及客户端路由延迟未及时刷新。
扩容时为什么反而会触发缓存雪崩
不是因为加了机器，而是 redis-cli --cluster rebalance 的 reshard 过程打乱了 key 的分布和失效节奏。slot 迁移后，原本分散在多个节点、不同过期时间的 key，可能被集中到同一新节点上；这些 key 的 EXPIRE 时间没变，但新节点重建 slot 时的访问模式、客户端路由刷新延迟，会让大量请求在同一窗口内打到空缓存上，直接穿透。
写入阶段必须强制使用 setex + 随机 TTL
这不是上线后补救手段，是扩容前必须卡死的红线。所有业务写缓存的地方，setex 的 TTL 必须是运行时计算值，不能写死：
-
base_ttl设为业务可接受的最短有效时间（例如 1800 秒），variance至少取 ±15%～25%，即 ±270～450 秒 - PHP 用户用
random_int(base_ttl - variance, base_ttl + variance)，别用已弃用的rand() - Java 用户在
opsForValue().set(key, value, Duration.ofSeconds(ttl))中，ttl必须是每次调用都重新生成的随机数 - 切忌对热点 key 单独设长 TTL 而不加随机——它会在过期瞬间变成“压力放大器”
迁移期间 maxmemory-policy 必须切为 noeviction
如果还用 allkeys-lru 或 volatile-lru，内存陡增时会批量踢掉刚迁入却尚未访问的 key，造成无效淘汰 + 重复回源。应：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 临时改配置：
CONFIG SET maxmemory-policy noeviction - 靠应用层控制写入节奏，配合监控
used_memory_peak_human提前告警 - 用
redis-cli --cluster rebalance时加--threshold 1，强制每次只搬少量 slot，避免单次重哈希引发大批 key 集中失效
别忽略客户端路由刷新延迟这个隐性瓶颈
集群拓扑变更后，客户端未必立刻感知。Jedis、Lettuce 等默认有缓存路由表，若未配置 refreshPeriod 或未监听 MOVED/ASK 重定向，会导致一批请求持续打到旧节点或空节点。检查点包括：
- JedisCluster 构造时是否传入了
new JedisPoolConfig()和合理maxRedirections - Lettuce 是否启用了
DynamicNodeTopologyProvider并设置了refreshTriggersReconnectThreshold - 有没有在日志里高频看到
MOVED错误但未触发自动重试
这个环节一旦漏掉，再严格的 TTL 随机化和内存策略也挡不住穿透流量。
