Go缓存雪崩击穿问题解决方法

本文深入剖析了Go应用中缓存雪崩与缓存击穿的本质区别及精准应对策略：雪崩源于大批量key因固定TTL扎堆过期，须通过随机化TTL（如`baseTTL + rand.Int63n(600)*time.Second`）主动打散过期时间，严禁先SET后EXPIRE或忽略NTP校时；击穿则聚焦单个热点key过期瞬间的并发回源，需严格采用singleflight（配合完整闭环：查缓存→Do回源→写缓存，且Group必须全局复用）或Redis原子SETNX抢锁（锁过期时间需严控在5–30秒），绝不可混用方案或误用本地锁。二者边界清晰——雪崩防“批量失效”，击穿防“单点并发”，错误统一处理反而会劣化冷key性能、抬高延迟、引入故障风险。

缓存雪崩和击穿不是 Redis 的问题，是业务层没控制好过期时间扰动和回源原子性。雪崩靠随机 TTL 打散过期点，击穿靠 singleflight 或 SETNX 保证单次回源——两者必须分开处理，混用反而增加延迟和故障风险。

Go 中设置随机 TTL 防雪崩：别写死 time.Now().Add()

所有同类 key 用相同固定过期时间（比如统一 30 * time.Minute），服务重启或批量预热后就会扎堆失效。Redis 不会帮你加抖动，得自己算。

• redis.Set(ctx, key, val, baseTTL + time.Second*time.Duration(rand.Int63n(600))) 是安全写法；rand.Intn(600) 在 Go 1.20+ 可直接用，不用手动 rand.Seed()
• 绝对不要先 SET 再单独调 EXPIRE —— 网络失败会导致 key 永不过期，或只设成功一半
• 如果用 redis.NewClusterClient，各节点系统时间差超过 2 秒就可能让实际过期不一致，必须开 NTP 校时
• 基础 TTL 别设太短（如 10s），否则抖动后部分 key 过期太快，起不到错峰作用；建议 ≥ 5 * time.Minute

singleflight 防击穿：必须闭环，不能只套 Do

singleflight.Group 本身不防击穿，它只合并请求。真正起作用的是「查缓存 → Do 回源 → 成功后写缓存」这个完整闭环。漏掉任一环，等于白加。

• var userGroup singleflight.Group 必须声明为包级变量或注入 service 结构体，不能在 handler 里 new(singleflight.Group) —— 否则每个请求都是新实例，Do 完全无效
• 所有副作用操作（DB 查询、日志打点、指标上报、cache.Set）必须全部塞进 Do 回调里，否则竞态窗口仍在
• 回调内必须用带 ctx 的 API（如 db.QueryRowContext(ctx, ...)），并自行处理超时与错误传播；失败时不写缓存，避免脏数据
• key 要稳定幂等，比如 "user:" + strconv.FormatInt(id, 10)，不能含时间戳或随机数

SETNX 原子抢写防击穿：锁过期时间要卡准

适用于 Redis 单实例或对一致性要求极高的场景。比 singleflight 多一层跨进程保障，但要注意锁生命周期。

• 用 rdb.Set(ctx, key, placeholder, redis.SetArgs{Mode: redis.SetNX, Expire: 10 * time.Second}) 抢锁；抢到的查 DB 并 Set 最终值，没抢到的 sleep 后重试或轮询 GET
• 锁过期时间必须 ≥ DB 查询耗时（建议 ≥ 5 * time.Second），但别超 30 * time.Second，否则故障时残留锁拖垮后续请求
• 绝对别用 sync.Mutex 或本地 map —— 多实例部署下完全无效
• 别手写三步锁（GET → SETNX → DEL），网络中断或 panic 会导致锁残留；SetArgs 是原子命令，更可靠

最易被忽略的一点：雪崩和击穿的触发边界非常清晰——雪崩是“一批 key 同时过期”，击穿是“单个热点 key 过期瞬间并发回源”。用同一个方案去套两者（比如给所有 key 加 singleflight），不仅没效果，还会把冷 key 的查询也串行化，白白增加 P99 延迟。

好了，本文到此结束，带大家了解了《Go缓存雪崩击穿问题解决方法》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！