如何在 Go 中利用 singleflight 解决缓存击穿

本篇文章给大家分享《如何在 Go 中利用 singleflight 解决缓存击穿》，覆盖了Golang的常见基础知识，其实一个语言的全部知识点一篇文章是不可能说完的，但希望通过这些问题，让读者对自己的掌握程度有一定的认识(B 数)，从而弥补自己的不足，更好的掌握它。

singleflight需与缓存逻辑严丝合缝配合才能防击穿；key须稳定且三者一致，Group须全局复用，所有加载与写缓存操作必须在Do回调内完成，超时和错误需外层兜底。

singleflight 本身不防击穿，必须和缓存读写逻辑咬合严丝合缝，漏掉任意一环——比如 key 不一致、group 非全局、加载逻辑外移——就等于没加。

Do 回调里必须塞进全部副作用操作

常见错误是先查缓存、判断 miss 后再调 Do。这会在两个 goroutine 同时看到 miss 时，都触发 Do 调用——虽然 Do 内部仍会去重，但你在外面做的 log.Info、metrics.Inc、甚至 db.Prepare 都已重复执行。

• 正确做法：所有真实加载动作（db.QueryRowContext、http.Get、JSON 解析）和成功后的缓存写入（cache.Set）全放在 Do 的回调函数里
• 失败路径不写缓存，避免脏数据；空结果可考虑写空值缓存（防穿透），但那是额外逻辑，singleflight 不管
• 回调签名必须是 func() (interface{}, error)，漏掉 interface{} 返回类型会编译失败

key 必须稳定且业务语义对齐

缓存 key、singleflight.Do 的 key、DB 查询条件三者不一致，去重直接失效。比如缓存用 "user:123"，Do 却传 123 或 fmt.Sprintf("u%d", id)，请求根本不会合并。

• key 类型必须是可比较的，推荐用 string；别传裸 int、struct{} 或带时间戳/traceID 的 URL
• 提取业务本质字段：用户查询就用 "user:" + strconv.Itoa(id)，而不是整个 r.URL.String()
• HTTP header 中的 X-Request-ID、X-Trace-ID 等非幂等字段必须剔除，否则每个请求都是新 key

Group 必须全局复用，不能按请求 new

压测时发现 DB 查询数仍线性上涨？大概率是把 var g singleflight.Group 声明在了 HTTP handler 里。每次请求新建一个 Group，内部的 map[string]*call 完全是空的，完全无法跨 goroutine 共享状态。

• 应声明为包级变量：var userGroup singleflight.Group，或注入到 service 结构体中复用
• 多个业务（用户、配置、权限）可共用同一个 Group，无需拆分；它线程安全，内部用 sync.Mutex 和 sync.Map 管理
• 别手动清理 Group 状态——它不持有长期资源，生命周期与服务一致即可

超时、错误、shared 信号都要自己兜底

Do 不接受 context，也不处理超时；返回的 shared 布尔值不是缓存命中信号，而是“你是否亲自执行了回调”的标记——这点极易误用。

• 超时必须由外层控制：在回调函数里用 ctx.Done() 检查，配合 db.QueryRowContext 等带 ctx 的 API，否则等待者可能永久卡住
• shared == false 时拿到的 error 是别人失败的结果，需结合降级（如返回默认值）或重试策略，不能直接透传
• 可用 if !shared { log.Info("first load", "key", key) } 打点首次加载，但别用它做业务分支逻辑

最易被忽略的是：缓存写入必须在 Do 回调的成功路径内完成，且仅写一次；否则下次请求仍 miss，Do 就退化成排队器，而非去重器。

本篇关于《如何在 Go 中利用 singleflight 解决缓存击穿》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！