定时任务触发缓存批量写入时，必须在缓存写入逻辑内部为每个key计算带随机扰动的TTL（如base_ttl + random.randint(0,600)），而非依赖调度层延时；需使用本地真随机、避免时间戳种子，并配合幂等标识与版本化key防止重试覆盖。
直接说结论：定时任务集中触发缓存写入或失效，是 Redis 雪崩的典型诱因之一；关键不是“少用定时任务”，而是切断“任务时间点 → 缓存批量过期 → 数据库穿透”这条链路。
定时任务触发缓存批量写入时，如何避免 TTL 同步固化？
很多调度系统（如 XXL-JOB、Quartz）在凌晨 2 点统一刷新商品/配置缓存，所有 setex 都用相同 ttl=3600，结果整点一到，上万 key 同时失效。
- 必须对每个 key 的过期时间做随机扰动，不能只在任务调度层加随机延时——因为任务可能重试、补发、多实例并行执行，仍会收敛到相近时间点
- 推荐做法：在缓存写入逻辑内部计算 ttl，例如
redis.setex(key, base_ttl + random.randint(0, 600), value)，其中base_ttl是业务要求的最小保质期，600是允许的最大抖动（10 分钟） - 注意：不要用
System.currentTimeMillis()或任务触发时间做随机种子——多实例下仍可能趋同；应使用本地真随机（如/dev/urandom或语言原生SecureRandom）
任务依赖“预热缓存”时，为什么本地缓存比 Redis 更适合作第一道防线？
比如一个定时任务负责“预热首页 banner”，如果它直接往 Redis 写 500 个 key，且都设 ttl=1800，那 30 分钟后这 500 个 key 又会在同一秒内集体失效。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 改用两级写入：
Caffeine（本地）设expireAfterWrite(30, TimeUnit.SECONDS)，再异步刷到 Redis；这样即使 Redis 全挂，本地缓存还能扛住短时流量 - Redis 层 ttl 必须和本地层错开：比如本地 30 秒，Redis 设为
1800 + random.nextInt(300)，形成时间梯度 - 禁止在任务中调用
redis.flushdb()或批量del热点前缀——这是人为制造雪崩，应改用带条件的scan + unlink分批清理
当调度系统本身发生故障重试时，怎样防止缓存被重复覆盖或清空？
XXL-JOB 默认失败重试 3 次，若每次重试都执行 cacheService.refreshAllProducts()，就可能把刚加上的随机 ttl 覆盖成固定值，或触发多次数据库全量查询。
- 给每个任务执行加幂等 key，例如
job:product_refresh:20260904，用setnx标记是否已执行；任务体开头先检查，已存在则直接 return - 避免“全量刷新”，改用增量识别：任务只查
updated_at > 上次执行时间的数据，再逐条更新对应 key，不碰其他 key - Redis 写操作必须带版本标识，例如
product:1001:v2，而不是反复覆盖product:1001；这样即使重试，也不会让旧值覆盖新值
真正容易被忽略的是：调度系统和缓存系统之间没有“时间感知协同”。任务认为“我按计划执行了”，但缓存层不知道这个计划——所以所有随机化、错峰、幂等逻辑，必须下沉到缓存写入那一刻，而不是寄托于调度器的“尽量不同时”。
