Golang singleflight防缓存击穿教程

Golang 的 singleflight 机制是应对缓存击穿问题的轻量级利器——它通过为相同 key 的并发请求设置“执行闸门”，确保同一时刻仅有一个 goroutine 真实执行耗时操作（如数据库查询），其余请求自动阻塞并共享该结果，从而将原本可能爆发的千次重复查询瞬间压缩为一次真实调用与九百九十九次高效等待，既无需侵入缓存逻辑，也不依赖外部组件，特别适合数据库响应较快、但并发突增易引发雪崩的典型场景。

singleflight.Do 为什么能拦住缓存击穿

因为 Do 对同一个 key 的所有并发调用，只让第一个 goroutine 真正执行函数，其余全部阻塞等待——结果返回后，所有人拿到同一份值。这直接把“1000 个请求同时查 DB”压成“1 个查，999 个等结果”。

• 它不关心缓存是否存在，也不管你有没有写入缓存，只管“此刻这个 key 的加载动作是否已在进行中”
• 适合场景：DB 查询快（
• 不适合场景：加载逻辑本身慢或不稳定（比如跨机房 RPC 超时率高），失败时所有等待者一起失败，可能放大雪崩

不配缓存，singleflight 就是废柴

singleflight.Group 本身不存任何数据，Do 返回的值也不会自动进缓存。如果每次调用都走 Do，等于反复触发去重+等待，但没省下一次 DB 查询——因为下次来还是 miss。

• 必须自己在 Do 的回调里完成“查 DB → 写缓存”闭环，例如用 sync.Map 或 Redis 客户端写入
• 常见错误：写了 g.Do("user:123", loadFromDB)，但 loadFromDB 里没调 cache.Store()，导致下次请求又进 Do
• key 设计要一致：缓存 key、singleflight key、DB 查询条件三者必须对齐，否则去重失效（比如一个用 "user:123"，一个用 "u123"）

shared 字段不是装饰，是关键信号

Do 返回的 shared 布尔值告诉你：“这个结果是不是被别人算出来的”。它不表示缓存命中，而是表示“你没执行函数，只是拿了别人的结果”。

• 可用于日志打点：if !shared { log.Info("first load for key", "key", key) }
• 不能用来判断缓存是否有效——哪怕 shared=true，结果也可能已过期，得靠缓存层自己控制 TTL
• 别忽略 error：如果第一次执行出错，shared=true 时所有等待者也拿到同一个 error，需结合重试策略或降级逻辑

Group 生命周期和错误处理容易翻车

singleflight.Group 是无状态的，但它的生命周期管理常被忽视：全局变量长期持有没问题，但如果按请求或租户新建 Group，会导致内存泄漏且去重失效。

• 推荐做法：整个服务共用一个全局 var g singleflight.Group，不要按 context 或参数 new
• 错误处理不能只依赖 Do 的 error 返回：DB 查询失败时，应考虑写空值缓存（防穿透）或 fallback 默认值，而不是让所有请求卡死在失败结果上
• 超时要由外层控制：singleflight 本身不支持超时，得用 context.WithTimeout 包裹实际加载函数，并在函数内检查 ctx.Err()

事情说清了就结束。最常漏掉的一点：singleflight 解决的是“同一时刻的并发冲击”，但它对“缓存大面积过期”或“key 长期不存在”完全无效——那得靠过期时间打散、空值缓存、布隆过滤器这些手段补位。

理论要掌握，实操不能落！以上关于《Golang singleflight防缓存击穿教程》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！