缓存能减轻数据库压力，但缓存失效那一刻也可能制造压力。比如热门用户资料过期，突然来了 200 个请求，如果每个请求都发现缓存没有，然后同时查数据库，数据库会被瞬间打满。这类问题常被称为缓存击穿。
singleflight 的思路是：同一个 key 的并发请求，只让第一个请求真正执行查询，其他请求等它的结果。Go 的扩展库里有成熟实现，但先理解思想更重要。本文用一个简化版讲清楚基本结构。
没有合并时的问题
一个普通缓存读取：
func (s *Service) GetProfile(ctx context.Context, id string) (Profile, error) {
if value, ok := s.cache.Get(id); ok {
return value, nil
}
profile, err := s.store.LoadProfile(ctx, id)
if err != nil {
return Profile{}, err
}
s.cache.Set(id, profile, time.Minute)
return profile, nil
}
这段代码在低并发时没问题。高并发下，缓存 miss 后所有请求都会进入 LoadProfile。缓存越热门，失效瞬间越危险。
一个简化 singleflight
定义正在执行的调用：
type call[T any] struct {
done chan struct{}
val T
err error
}
type Group[T any] struct {
mu sync.Mutex
m map[string]*call[T]
}
执行：
func (g *Group[T]) Do(key string, fn func() (T, error)) (T, error) {
g.mu.Lock()
if g.m == nil {
g.m = make(map[string]*call[T])
}
if c, ok := g.m[key]; ok {
g.mu.Unlock()
<-c.done
return c.val, c.err
}
c := &call[T]{done: make(chan struct{})}
g.m[key] = c
g.mu.Unlock()
c.val, c.err = fn()
close(c.done)
g.mu.Lock()
delete(g.m, key)
g.mu.Unlock()
return c.val, c.err
}
这段代码的关键是 map 里记录同一个 key 的进行中调用。后来的请求发现已有调用，就等待 done 关闭，然后复用结果。第一个请求完成后删除记录，下一轮缓存 miss 可以重新发起。
用在缓存 miss
服务中使用：
type Service struct {
cache Cache
store Store
group Group[Profile]
}
func (s *Service) GetProfile(ctx context.Context, id string) (Profile, error) {
if value, ok := s.cache.Get(id); ok {
return value, nil
}
return s.group.Do(id, func() (Profile, error) {
if value, ok := s.cache.Get(id); ok {
return value, nil
}
profile, err := s.store.LoadProfile(ctx, id)
if err != nil {
return Profile{}, err
}
s.cache.Set(id, profile, time.Minute)
return profile, nil
})
}
注意 Do 里面又查了一次缓存。因为当前请求等待之前，可能已经有别的请求把缓存写回了。这个“双重检查”能减少不必要查询。
错误也会共享
如果第一个查询失败，等待的请求也会拿到同一个错误。这通常是合理的，因为大家请求的是同一个 key，底层依赖也确实失败了。但要注意：失败结果不要写缓存，除非你有明确的负缓存策略。
负缓存是把“不存在”也缓存一小段时间，避免不存在的 key 被反复查库。但负缓存要谨慎，时间太长可能让刚创建的数据短时间不可见。
context 的边界
简化版里等待者无法单独取消：
<-c.done
真实项目里你可能希望等待时也能响应请求取消：
select {
case <-c.done:
return c.val, c.err
case <-ctx.Done():
var zero T
return zero, ctx.Err()
}
但这会让 Do 的签名更复杂。入门时先理解合并同 key 调用的核心，再考虑取消、忘记 key、共享标记等细节。生产中可以使用成熟的 singleflight 实现。
不要把所有请求都合并
singleflight 适合同一个 key 的昂贵操作。比如用户资料、配置加载、权限规则、热门文章。它不适合把所有不同 key 都串起来。如果 key 设计太粗，比如统一用 "profile"，所有用户资料请求都会互相等待，吞吐会下降。
key 应该表达真正共享的资源：
key := "profile:" + userID
不要包含每次都变化的请求 ID，否则完全合并不了。也不要漏掉必要维度，比如语言、租户、权限视角。key 设计错了，缓存和 singleflight 都会出问题。
测试是否只调用一次
可以写一个计数测试：
func TestGroupDoMergesCalls(t *testing.T) {
var g Group[int]
var calls atomic.Int64
fn := func() (int, error) {
calls.Add(1)
time.Sleep(20 * time.Millisecond)
return 42, nil
}
var wg sync.WaitGroup
for i := 0; i < 10; i++ {
wg.Add(1)
go func() {
defer wg.Done()
got, err := g.Do("answer", fn)
if err != nil || got != 42 {
t.Errorf("got %d, err %v", got, err)
}
}()
}
wg.Wait()
if calls.Load() != 1 {
t.Fatalf("calls = %d, want 1", calls.Load())
}
}
这个测试用 sleep 制造重叠时间。真实测试要避免过长等待，几十毫秒足够表达并发重叠。
和缓存预热的区别
singleflight 解决的是“同一时刻重复加载”的问题，缓存预热解决的是“请求到来前先准备好”的问题。两者可以配合，但不是一回事。比如首页配置可以在服务启动时预热，热门用户资料则更适合在 miss 时用 singleflight 合并请求。
还有一种常见做法是“提前刷新”：缓存快过期时，后台异步刷新，而不是等用户请求命中过期。这样用户更少遇到 miss，但实现更复杂。入门阶段可以先用 TTL 缓存加 singleflight，等确实观察到过期抖动，再考虑提前刷新。
不要把 singleflight 当成数据库保护的唯一手段。限流、超时、连接池、SQL 索引、缓存 TTL 都会影响系统稳定性。singleflight 只是其中一个很实用的小工具。
如果加载函数本身很慢，也要给它设置超时。等待者复用结果，不代表它们愿意无限等待。把请求 context 传进加载逻辑，超时后让所有等待者都尽快返回，比让一批 goroutine 卡住更安全。
小结
singleflight 的核心思想是：同一个 key 的并发 miss，只执行一次真实加载，其他请求等待并复用结果。它能缓解缓存击穿，保护数据库和外部依赖。
使用时要注意 key 设计、错误共享、context 取消和负缓存策略。它不是缓存本身，而是缓存 miss 时的一层并发保护。理解这个边界，才能用得稳。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。