Go 用 singleflight 防缓存击穿:同一个 key 的并发请求只穿透一次缓存挂了、或者某个热点 key 刚好过期的那一瞬间,成百上千个请求同时发现缓存 miss,于是一股脑全打到数据库上——这就是缓存击穿。数据库瞬间被同一份查询压垮,而这些请求本可以只查一次、其余人等结果就行。golang.org/x/sync/singleflight就是专治这个的:同一个 key 在同一时刻只允许一次真正的调用在飞,其他并发调用者共享这次调用的结果。这篇手把手把「击穿现场」复现出来,再用 singleflight 补上。先复现缓存击穿假设我们有一个按用户 ID 查资料的函数,底层是一次「昂贵」的数据库查询。为了看清楚有多少请求真的打到了 DB,我用一个原子计数器统计。packagemainimport(fmtsyncsync/atomictime)vardbCallsint64// 模拟一次昂贵的 DB 查询:100msfuncqueryUserFromDB(idstring)(string,error){atomic.AddInt64(dbCalls,1)// 记录真实穿透次数time.Sleep(100*time.Millisecond)returnuser-id,nil}funcmain(){varwg sync.WaitGroup// 1000 个 goroutine 同时查同一个 id,模拟热点 key 刚过期fori:0;i1000;i{wg.Add(1)gofunc(){deferwg.Done()_,_queryUserFromDB(42)}()}wg.Wait()fmt.Println(DB 被调用次数:,atomic.LoadInt64(dbCalls))}跑一下:DB 被调用次数: 10001000 个请求,1000 次穿透。这就是击穿——如果queryUserFromDB是真的连数据库,DB 直接被同一份查询打爆。用 singleflight 收敛成一次singleflight.Group.Do(key, fn)保证:同一个key上如果已经有一个fn在执行,后来的调用者不会再执行fn,而是阻塞等待,拿到同一份返回值。先装依赖:go get golang.org/x/sync/singleflight改造:packagemainimport(fmtsyncsync/atomictimegolang.org/x/sync/singleflight)var(dbCallsint64g singleflight.Group// 一个 Group 管一类 key)funcqueryUserFromDB(idstring)(string,error){atomic.AddInt64(dbCalls,1)time.Sleep(100*time.Millisecond)returnuser-id,nil}// 带 singleflight 的查询入口funcqueryUser(idstring)(string,error){// Do 的第三个返回值 shared 表示这个结果是否被多个调用者共享v,err,shared:g.Do(id,func()(interface{},error){returnqueryUserFromDB(id)})_sharediferr!nil{return,err}returnv.(string),nil}funcmain(){varwg sync.WaitGroupfori:0;i1000;i{wg.Add(1)gofunc(){deferwg.Done()_,_queryUser(42)}()}wg.Wait()fmt.Println(DB 被调用次数:,atomic.LoadInt64(dbCalls))}再跑:DB 被调用次数: 11000 个并发请求,DB 只被真正查了 1 次,其余 999 个都在等这一次的结果。这就是 singleflight 的核心价值:把「同一时刻、同一个 key」的重复工作压成一次。注意Do返回的第三个值shared——它告诉你这次结果是不是被别人共享了。做监控时可以用它统计「合并率」。结合真实缓存:miss 时才 singleflight真实场景里,singleflight 是缓存的第二道防线:先查缓存,miss 了再进 singleflight 查 DB,查完回填缓存。funcgetUser(idstring)(string,error){// 1. 先查缓存(这里用 map 模拟,真实用 Redis)ifv,ok:cacheGet(id);ok{returnv,nil}// 2. 缓存 miss:同一个 key 只让一个 goroutine 去查 DBv,err,_:g.Do(id,func()(interface{},error){// 双重检查:进来后可能别人已经回填过了ifcached,ok:cacheGet(id);ok{returncached,nil}user,err:queryUserFromDB(id)iferr!nil{returnnil,err}cacheSet(id,user)// 回填缓存returnuser,nil})iferr!nil{return,err}returnv.(string),nil}Do内部的双重检查不是多余的:当第一个请求正在查 DB 并回填时,可能刚好又过了一个「窗口期」,但对同一个 key 而言 singleflight 已经保证了串行,这里的双检主要防御 key 竞争进入前缓存已被别的路径填好的情况。坑一:一个请求出错,所有共享者一起失败因为结果是共享的,如果那唯一一次调用返回了 error,所有等待的调用者都会拿到同一个 error。这在偶发抖动时会放大故障——一次超时,1000 个请求一起超时。对策:对可重试的错误不要长时间占用 key。singleflight 提供了Forget(key),可以在调用返回后立刻把 key 从飞行表里删掉,让下一波请求重新发起,而不是复用一个失败结果。v,err,_:g.Do(id,func()(interface{},error){user,err:queryUserFromDB(id)iferr!nil{// 出错立刻 Forget,避免错误结果被后续请求短暂复用g.Forget(id)returnnil,err}returnuser,nil})坑二:DoChan 超时,别让慢查询拖死一片Do是阻塞的:只要那唯一一次调用不返回,所有等待者就一直卡着。如果 DB 慢查询要 30 秒,这一片请求全被拖住。用DoChan配合select给每个调用者独立的超时控制:funcgetUserWithTimeout(idstring,timeout time.Duration)(string,error){ch:g.DoChan(id,func()(interface{},error){returnqueryUserFromDB(id)})select{caseres:-ch:ifres.Err!nil{return,res.Err}returnres.Val.(string),nilcase-time.After(timeout):// 注意:这里只是当前调用者放弃等待,// 底层那次调用还在跑,不会被取消return,fmt.Errorf(query %s timeout,id)}}关键理解:select超时只让当前这个调用者先返回,底层的fn仍在后台执行,不会因为某个等待者放弃就被打断。如果需要真正取消底层调用,得把context传进fn里自己处理。小结缓存击穿 同一个 key 的并发请求在缓存 miss 瞬间全穿透到 DB;singleflight 把它们合并成一次。用法极简:g.Do(key, fn),同 key 并发只执行一次 fn,其余共享结果;shared返回值可用来观测合并率。真实用法是「先查缓存 → miss 才进 Do → 查完回填」,Do 内做双重检查。两个必知坑:出错会连累所有共享者(用Forget及时释放 key),Do阻塞可能被慢查询拖死一片(用DoChan select给每个调用者独立超时)。一句话记忆:singleflight 管的是「同一时刻同一个 key 只查一次」,它不是缓存、也不做过期,它只负责去重。