Golang singleflight如何防缓存击穿_Golang singleflight教程【深入】

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()，导致下次请求又进 Dokey 设计要一致：缓存 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，会导致内存泄漏且去重失效。

立即学习“go语言免费学习笔记（深入）”；

推荐做法：整个服务共用一个全局 var g singleflight.Group，不要按 context 或参数 new错误处理不能只依赖 Do 的 error 返回：DB 查询失败时，应考虑写空值缓存（防穿透）或 fallback 默认值，而不是让所有请求卡死在失败结果上超时要由外层控制：singleflight 本身不支持超时，得用 context.WithTimeout 包裹实际加载函数，并在函数内检查 ctx.Err()事情说清了就结束。最常漏掉的一点：singleflight 解决的是“同一时刻的并发冲击”，但它对“缓存大面积过期”或“key 长期不存在”完全无效——那得靠过期时间打散、空值缓存、布隆过滤器这些手段补位。