Redis 过期键集中到期时怎么错开 TTL

Redis 缓存批量写入时，如果所有 key 都使用同一个 TTL，例如统一设置为 30 分钟，那么它们的过期时刻也会挤在相近的时间段。更稳妥的做法是把 TTL 写成“基础时长 + 小范围随机抖动”，让过期时间分散到一个窗口里。抖动只负责错开批量失效，单个热点 key 仍需要互斥回源、逻辑过期或限流保护。

常用落地方式是：缓存首次回填时计算一次随机 TTL，后续命中不重置；基础 TTL 决定数据新鲜度，抖动窗口决定批量失效的分散程度。

为什么固定 TTL 会把请求推向同一个时间点

假设任务在 10:00 批量刷新 10 万个商品缓存，并对每个 key 都执行 EXPIRE key 1800。这些 key 的理论过期时间都接近 10:30。Redis 的过期删除有访问时的被动检查，也有后台主动清理；真正让业务看到压力的，往往是缓存 miss 后的大量回源请求，而不只是删除动作本身。

因此，问题不在于“过期是否准点”，而在于写入事件是否把许多 key 的生存周期对齐了。先把固定值拆成基础时长和抖动窗口，才能控制这个相关性。

用随机抖动生成可控的 TTL

Redis 的 SET 可以直接带 EX 设置秒级过期时间，也可以先写入再调用 EXPIRE。应用侧只需在缓存回填时计算一次有效 TTL。下面的 Go 示例使用 go-redis，抖动范围包含 0，便于把最短时长严格控制在 baseTTL。

package cache

import (
    "context"
    "math/rand"
    "time"

    "github.com/redis/go-redis/v9"
)

// ttlWithJitter 让同一批回填的 key 分散到一个有限窗口内。
func ttlWithJitter(baseTTL, jitterMax time.Duration) time.Duration {
    if jitterMax 

这个窗口的含义是：同类 key 的 TTL 最短为 5 分钟，最长接近 6 分钟，而不是让所有 key 都在第 5 分钟同时失效。实际项目中，jitterMax 要结合回源吞吐、数据库连接池和数据可接受陈旧时间设置；它不是越大越好。

把批量写入、刷新和热点保护分开

最容易出现反效果的写法，是每次读取缓存都重新执行一次带新随机值的 SET。这样会把缓存变成不断续期的对象，数据可能长期不失效，也会让 TTL 分布难以解释。更清晰的决策是把三种场景拆开：

• 缓存未命中：回源得到数据后写入一次，并加入抖动。
• 后台刷新：按固定节奏刷新少量 key，仍使用同一 TTL 策略，避免刷新任务制造新的整批过期点。
• 单热点保护：对同一个 key 使用短锁、请求合并或逻辑过期；不能只靠抖动解决瞬时并发回源。

如果业务必须延长命中 key 的有效期，可以使用 Redis 的条件过期能力约束刷新方向。例如只在已有过期时间时更新，或只允许新 TTL 大于旧 TTL。无论采用哪种方式，都应让“谁负责刷新、刷新多久、失败是否保留旧值”成为明确的接口语义。

发布前检查 TTL 分布与回源压力

不要凭感觉选择抖动比例。发布前至少观察一轮真实或压测流量：随机抽取缓存 key 读取 TTL，按剩余时间分桶；同时记录缓存 miss、回源耗时、数据库并发和错误率。若分桶仍集中在一个很窄的区间，说明抖动窗口太小，或上游批量任务本身过于同步。

• 数据允许陈旧时间很短时，先减小 baseTTL 之外的窗口，不要为了分散而牺牲一致性要求。
• 回源容量不足时，增加抖动只能缓解批量到期，仍要加请求合并、限流或降级。
• 更新操作会覆盖原有 TTL；写入逻辑必须确认每一次 SET 是否都带上了期望的过期时间。
• 用 TTL key 检查少量样本即可，不要把全量扫描当作线上监控方案。

常见问题

随机 TTL 能彻底避免缓存雪崩吗？

不能。它主要降低批量 key 同时失效的概率；数据库、网络或 Redis 本身故障时，还需要限流、降级和多级缓存。

抖动窗口应该设置成基础 TTL 的百分之多少？

没有通用比例。先以业务可接受的陈旧时间为上限，再用 TTL 分桶和回源峰值反推窗口，避免直接套用固定百分比。

每次命中都重新设置随机 TTL 可以吗？

通常不建议。它会让热点 key 持续续期并掩盖真实失效；除非明确采用滑动过期，否则只在回填或受控刷新时设置。