根本原因是大量key的TTL高度趋同；即使加random.randint(0,600)偏移，若基础TTL过整、服务重启无预热、多节点时钟未校准或命令误用（如毫秒/秒混淆），仍会导致70% key落入同一5分钟窗口过期，触发雪崩。
设置了TTL仍会发生Redis雪崩，根本原因不是“用了TTL”，而是“大量key的TTL高度趋同”——哪怕只差几秒，高并发下也足以让Redis在毫秒级内批量丢掉数万缓存，数据库瞬间被压垮。
为什么random.randint(0, 600)还不够用？
很多人照搬示例用 random.randint(0, 600) 加偏移，但实际线上出问题时发现：偏移量太小、基础TTL太整、服务重启后冷启动无缓冲，三者叠加照样雪崩。
- 偏移量若固定为 ±10 分钟，而基础 TTL 是 3600 秒（整 1 小时），在流量高峰时段，仍可能有 70% 的 key 落在同一个 5 分钟窗口内过期
- Spring Boot 应用重启时，
RedisTemplate初始化完成前所有请求都穿透到 DB，此时随机 TTL 完全没机会生效 - 微服务多实例部署时，各节点本地时钟未校准，
System.currentTimeMillis()时间差可能导致 key 过期时间实际对齐
setex 和 set 的过期参数行为差异必须厘清
用错命令会让随机 TTL 彻底失效。比如在 Jedis 中误用 set(key, value) 而非 setex(key, seconds, value)，或在 RedisTemplate 中写成 opsForValue().set(key, value, timeout) 却传入了毫秒值（实际期待秒）。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
setex和set ... EX接收的是**秒级整数**；set ... PX才是毫秒级 - Spring Data Redis 的
redisTemplate.opsForValue().set(key, value, 3600, TimeUnit.SECONDS)正确；若写成TimeUnit.MILLISECONDS，等于只设了 3.6 秒过期 - Go 的
redis.Set(ctx, key, val, 3600*time.Second)没问题，但 Python redis-py 的setex(key, 3600, val)也只认秒，别和expireat混淆
真正扛压的雪崩防护要分三层落地
单靠“加随机数”只是第一层，漏掉任一层，高并发下都可能击穿。
-
预热层：上线前用脚本调用
cachePrewarmService.preloadCache()主动加载热点 key，并设比线上 TTL 长 20% 的过期时间，确保刚启动就有缓冲 -
运行层：对每个 key 的 TTL 计算使用
base_ttl * (0.8 + random.random() * 0.4)（即 ±20% 浮动），避免线性偏移导致的隐式对齐 - 兜底层：当 Redis 响应超时或连接失败时，立刻触发熔断，走
getFallbackData()返回本地缓存或静态兜底数据，而非 fallback 到 DB
最容易被忽略的是：缓存重建本身不能同步阻塞请求。哪怕加了互斥锁，若重建耗时 800ms，后续 500 个等待线程会集体超时。真正的优雅解法是——重建异步化 + 旧值逻辑过期 + 请求端带重试退避，这三者缺一不可。
