redis集群不自动随机化过期时间，需业务层实现；限流须在应用层或网关层统一控制；热点key需加扰动后缀分散分片；三者叠加（集群+随机过期+限流）且随机范围≥±5%才有效防雪崩。
Redis集群本身不自动处理过期时间随机化
Redis Cluster 只负责数据分片、故障转移和请求路由，EXPIRE 命令的行为在每个节点上仍是独立执行的。也就是说，集群不会帮你把 set key value EX 3600 自动改写成带随机偏移的过期时间——这个逻辑必须由业务代码或中间件层控制。
常见错误是以为“上了集群就天然防雪崩”，结果所有节点上的热点 key 仍按统一 TTL 失效，集群只是把压力均匀打到多个数据库实例上，反而更难收敛。
- 过期时间随机化必须在写缓存时完成，例如：用
SET key value EX 3600改为计算后调用SET key value EX 3240或EX 3960 - 如果使用 Spring Cache，不能只配
@Cacheable(expire = 3600)，得配合自定义CacheManager注入随机逻辑 - 客户端直连 Redis 时，需在调用
setex/expire前生成随机值，不是靠集群配置项
集群节点间无法共享限流状态，得靠外部组件
Redis Cluster 各分片之间不互通连接数、QPS、错误率等运行指标，所以单靠 Redis 本身无法实现“整个集群维度”的限流。一旦某个分片因雪崩前兆开始超时，其他分片完全感知不到。
真实可用的限流必须落在应用层或网关层：
- 用
Sentinel或Resilience4j统计全链路缓存失败率，触发熔断后直接降级，不再发任何 Redis 请求 - 在 API 网关（如 Kong、Spring Cloud Gateway）配置全局 Redis 调用限流，比如每秒最多 500 次
GET，超限返回429 Too Many Requests - 避免在每个微服务里各自实现限流逻辑，否则各服务限流阈值不协同，可能某服务已熔断，另一服务还在猛刷 DB
集群模式下随机过期时间要结合分片策略设计
如果热点 key 全被 hash 到同一个分片（比如都用 user:123:profile 这种格式），即使加了随机过期，该分片仍可能在短时间内集中失效大量 key，引发局部雪崩。
这时需要主动干预 key 的分布：
- 对高并发 key 加扰动后缀，例如
user:123:profile:shard1和user:123:profile:shard2，让同一用户的不同缓存落到不同 slot - 避免用纯业务 ID 作 key 主体，可拼接
hashCode(userId) % 4作为分片标识，强制分散 - 用
CLUSTER KEYSLOT key命令验证 key 分布是否均匀，别依赖“应该会散开”的直觉
真正起作用的是“集群 + 随机过期 + 限流”三层叠加
单独做任何一项都防不住雪崩：集群解决单点宕机，但不管过期节奏；随机过期打散失效时间，但扛不住 Redis 全挂；限流保护下游，却无法缓解缓存层自身雪崩引发的连锁超时。
最容易被忽略的一点是：随机范围不能太小。比如基础 TTL 是 1 小时，只加 ±10 秒，对万级 QPS 来说仍然可能在几十毫秒内集中失效。实际生产中建议 ±5~15% 基础值，且最低不低于 300 秒，否则短 TTL 本身就会放大抖动。
