热路径下重复请求导致的雪崩问题可通过QPS上升时DB CPU或下游响应时间陡增、goroutine数暴涨、同一key请求日志密集、后端耗时稳定但总延迟飙升等现象识别。
热路径下重复请求导致的雪崩问题怎么识别
当接口被高频调用，且后端依赖（比如数据库查询、远程 API）耗时较长时，SingleFlight 就该出现了。典型现象是：QPS 上去后，DB CPU 或下游服务响应时间陡增，但监控里看不出明显慢 SQL —— 实际是几十个相同参数的请求同时打到后端，每个都查一遍。
这不是缓存没生效，而是「缓存穿透前的并发冲击」。关键判断点：goroutine 数暴涨 + 同一 key 的请求日志密集出现 + 后端耗时稳定但总延迟飙升。
SingleFlight 怎么正确包裹热路径函数
SingleFlight 不是自动拦截器，必须显式包装你要保护的函数。它只对「同一 key」的并发调用做合并，不处理缓存逻辑，也不替代 sync.Once。
- 用
singleflight.Group.Do(key, fn)，其中key必须能唯一标识一次计算（比如"user:" + userID），不能是空字符串或固定值 -
fn必须是无参函数，返回(interface{}, error)；如果原函数带参，需闭包捕获，注意变量逃逸和生命周期 - 不要在
fn里再调用Do同一 key，会死锁；不同 key 可嵌套，但要小心循环依赖 - 返回的
val是第一个成功完成的 goroutine 的结果，err同理；后续并发调用拿到的是相同val/err，不会重试
示例：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
var sg singleflight.Group
func GetUser(ctx context.Context, id string) (*User, error) {
v, err, _ := sg.Do("user:"+id, func() (interface{}, error) {
u, err := db.QueryUser(ctx, id) // 真实耗时操作
return u, err
})
if err != nil {
return nil, err
}
return v.(*User), nil
}
为什么 DoChan 和 Forget 容易用错
DoChan 返回 channel，适合不想阻塞当前 goroutine 的场景（比如 HTTP handler 中提前发请求，后面再 select），但它不解决「取消传播」—— 如果原始 ctx 超时，DoChan 不会自动 cancel 正在执行的 fn，得你自己在 fn 里检查 ctx.Done()。
-
Forget(key)仅从 group 内部 map 删除 key 对应的 entry，**不影响已在运行的 fn**；已排队等待的 goroutine 仍会收到结果 - 频繁调用
Forget可能导致 key 失效后新请求又触发计算，反而放大压力；除非你明确知道该 key 已过期且后续请求不该复用旧结果（比如配置强一致性更新） - 没有全局清理机制，
Group本身无大小限制，长期运行的服务若 key 泛化严重（如带毫秒时间戳），可能内存泄漏
和缓存一起用时要注意什么
SingleFlight 和缓存（如 redis 或 bigcache）是互补关系，不是二选一。常见错误是：先查缓存未命中 → 直接进 Do → 成功后不写回缓存，下次还是走 Do。
- 标准流程应是：
查缓存 → 命中则返回；未命中 → Do → 成功后异步写缓存（注意失败重试策略） - 避免「缓存击穿」：缓存失效瞬间大量请求涌向
Do，此时SingleFlight能兜底，但最好加一层「逻辑过期」或「互斥锁续命」 - 不要把
Do结果直接当缓存值传给下游；它没有 TTL，也不保证一致性；缓存该有的过期、淘汰、序列化逻辑一样不能少
真正难的从来不是加一行 sg.Do，而是 key 设计是否收敛、fn 是否可中断、失败后要不要 fallback、以及缓存与 SingleFlight 的职责边界有没有划清。
