必须在应用层为每个SET命令的EX参数注入随机偏移量，Redis本身不提供自动打散能力；固定EX 3600会导致批量key同一时刻过期，触发惰性或定期删除风暴，造成主线程卡顿、expired_keys突增、DB瞬时击穿。
必须在应用层为每个 SET 命令的 EX 参数注入随机偏移量，Redis 本身不提供自动打散能力。任何寄希望于配置调优或后台清理机制的方案，都只是补救，无法替代源头分散。
为什么 SET key value EX 3600 是定时炸弹
当批量写入商品、用户、配置类缓存时，若所有 key 都用固定 EX 3600，它们会在同一秒（甚至同一毫秒）触发惰性删除或定期扫描清理。此时 Redis 主线程可能卡在 unlink 或内存回收上，INFO stats 中的 expired_keys 会突增，DB 请求量瞬间翻倍——这不是高并发压测，是自己埋的雷。
常见错误现象包括：
- 用
redis-cli --scan --pattern "product:*" | xargs -I{} redis-cli ttl {}扫出大量完全相同的整数（如全是3598） - 监控里
expired_keys每小时整点出现尖峰，且与你设置的基础 TTL 强相关 - Spring Boot 启动预热时用
redisTemplate.opsForValue().set(key, value, Duration.ofSeconds(3600))未加扰动
如何给 EX 参数加安全随机偏移
偏移不是越乱越好，得兼顾业务语义和失效节奏。基础 TTL 是底线，随机是扰动，二者不可颠倒。
实操要点：
- 偏移范围建议控制在基础值的 5%–20% 区间，例如 3600 秒对应 +0~360 秒（±10%），避免部分 key 寿命缩水超 10 分钟
- Java 必须用
ThreadLocalRandom.current().nextInt(0, 360)，禁用全局Random——否则多线程下极易生成重复序列 - Python 推荐
random.randint(0, 360)，注意参数顺序，别写成randint(360, 0)抛异常 - 所有写入路径都要覆盖：定时任务、MQ 消费、HTTP 接口、后台脚本，漏掉任意一个就可能扎堆
示例（Java）：
public void setWithJitter(String key, String value, int baseSeconds) {
int jitter = ThreadLocalRandom.current().nextInt(0, (int) (baseSeconds * 0.1));
redisTemplate.opsForValue().set(key, value, Duration.ofSeconds(baseSeconds + jitter));
}为什么不能先 SET 再 EXPIRE
两步操作非原子，中间一旦发生网络中断、Redis 写入失败但客户端未感知，key 就变成永不过期——这比雪崩更难排查，因为问题不会立刻爆发，而是潜伏数小时后突然集中失效。
正确做法只用原子命令：
- 用
SET key value EX seconds或SETEX key seconds value，确保写入与过期绑定 - 禁用
SET+EXPIRE组合，尤其在分布式环境或高并发写入路径中 - 如果必须用
EXPIREAT，则对时间戳计算部分加偏移：EXPIREAT key $(( $(date +%s) + 3600 + RANDOM % 120 ))
真正容易被忽略的是分片逻辑里的隐式扎堆：哪怕用了随机偏移，如果所有分片共用同一随机种子、或在定时任务中批量生成 key 时复用同一个 jitter 值，仍会退化为“伪打散”。打散必须是每个 key 独立计算，且跨进程、跨线程、跨实例保持隔离。
