缓存能减轻数据库压力，但缓存失效那一刻也可能制造压力。比如热门用户资料过期，突然来了 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 卡住更安全。
常见问题 FAQ
Q: 自己实现还是直接用扩展库？
A: 理解原理后，生产环境推荐使用 golang.org/x/sync/singleflight。它处理了更多边界：context 取消、忘记 key、panic 恢复等。
Q: singleflight 和缓存预热选哪个？
A: 二者可以互补。预热解决"提前准备好"，singleflight 解决"同时 miss 时减少加载"。对大流量热门 key，两者都上最稳妥。
Q: 负缓存多久合适？
A: 通常比正常缓存 TTL 更短，几秒到几十秒。太长了会让新创建的数据延迟可见。
常见陷阱
- key 设计太粗：所有用户共享一个 key，会串行化本不相关的请求。key 要精细到资源粒度。
- 加载函数没有超时：等待者复用结果，但如果第一个请求卡住，所有等待者都会卡住。context 超时是必须的。
- 错误结果被所有请求共享：第一个请求失败后，所有等待者拿到同个错误。这通常合理，但要考虑是否需要降级策略。
对比表
| 策略 | 解决的问题 | 何时使用 |
|---|---|---|
| TTL 缓存 | 减少重复查询 | 通用 |
| singleflight | 缓存击穿的并发加载 | 高并发 + 热门 key |
| 缓存预热 | 预热期无 miss | 可预测的热门数据 |
| 负缓存 | 防止空 key 穿透 | 大量查询不存在数据 |
小结
singleflight 的核心思想是：同一个 key 的并发 miss，只执行一次真实加载，其他请求等待并复用结果。它能缓解缓存击穿，保护数据库和外部依赖。Go 扩展库 x/sync/singleflight 是生产推荐方案。
使用时要注意 key 设计、错误共享、context 取消和负缓存策略。它不是缓存本身，而是缓存 miss 时的一层并发保护。理解这个边界，才能用得稳。先保证正确合并，再考虑性能优化，不要过早引入复杂的预热和负缓存策略。
真实项目用例
在实际团队协作中，下面是几个推荐的工作流：
代码审查清单
- 函数是否处理了所有 error 返回值
- 并发代码是否有明确的退出路径和 WaitGroup
- 用户输入是否经过校验和清洗
- 敏感配置是否通过环境变量或加密存储注入
- 测试是否覆盖了正常路径和至少一个错误路径
- 日志是否包含足够的上下文信息但不泄露敏感数据
- 接口设计是否符合最小接口原则
CI/CD 集成建议
- 每次提交前运行
go fmt ./... - CI 中运行
go vet ./...和golangci-lint run - 单元测试使用
go test -race ./...检测数据竞争 - 关键路径的 benchmark 加入回归测试
- 使用
go mod verify确保依赖完整性
性能调优检查点
- 使用 pprof 分析 CPU 和内存使用
- 关注 benchmark 的 allocs/op，减少高频路径的堆分配
- 检查数据库查询是否使用索引
- 确认外部 HTTP 调用有合理的超时设置
- 缓存热点数据，但注意缓存一致性和过期策略
面试高频考点
如果你正在准备 Go 相关面试，以下概念是高频考点：
- goroutine 和线程的区别
- channel 的缓冲和非缓冲用法
- defer 的执行顺序和与返回值的关系
- map 的并发不安全性和解决方案
- interface 的隐式实现和类型断言
- slice 的底层数组和 append 机制
- GC 的基本原理和调优参数
- context 的使用场景和超时控制
- error 的包装和 errors.Is/errors.As
- sync.Mutex vs sync.RWMutex vs atomic
掌握这些概念意味着你具备了独立开发 Go 服务的基础能力。继续在实际项目中磨练，你会越来越熟悉 Go 的工程风格和最佳实践。
常见问题（FAQ）
Q: 这个特性在实际项目中真的有用吗？
A: 是的。本文介绍的技术来源于真实后端开发场景。无论是标准库工具还是工程实践，在日常服务开发中都会反复用到。
Q: Go 版本会影响示例代码吗？
A: 本文代码主要针对 Go 1.20+ 编写。较新版本（如 1.22、1.23）的语法可能有微调，但核心概念保持不变。如有版本差异，文中会特别说明。
Q: 学习 Go 应该先学标准库还是直接上框架？
A: 强烈建议先学标准库。框架是对标准库的封装和扩展。只有理解了标准库的能力边界，才能正确选择和使用框架，也才能在框架出问题时快速定位。
Q: 代码里的错误处理为什么都是显式的 if err != nil？
A: 这是 Go 的设计哲学。显式错误处理让失败路径清晰可见，不会隐藏在任何 try-catch 之后。习惯了之后，你会发现这种写法实际上降低了排查错误的难度。
Q: 并发相关代码怎么测试？
A: 使用 Go 内置的 -race 标志检测数据竞争：go test -race ./...。结合 sync.WaitGroup 和 context.WithTimeout 编写有退出路径的并发测试，避免 goroutine 泄漏。
常见坑与避坑指南
- 不要信任用户输入：无论表单、JSON、Cookie 还是 HTTP Header，都当作不可信数据处理，做校验和转义。
- 资源要释放：文件、数据库连接、HTTP 响应体都要及时关闭。
defer是一个好习惯。 - 不要忽略错误：即使
defer file.Close()可能返回错误，至少记录日志。完全忽略错误是 bug 的温床。 - 不要滥用 goroutine：每个 goroutine 都要有明确的退出路径。使用
sync.WaitGroup和context管理生命周期。 - 不要硬编码配置：端口、路径、超时时间、密钥都应该从配置读取，让程序适应不同环境。
- 不要过早优化：先让代码正确和可读，再用 benchmark 和 profile 找到真正的热点。
延伸阅读与实践建议
读完本文后，建议完成以下实践：
- 把文中所有示例代码在自己的机器上跑一遍
- 给示例代码补充错误分支的测试用例
- 尝试基于本文内容构建一个小型完整项目
- 在 review 他人的 Go 代码时，检查本文提到的边界是否被覆盖
- 订阅 Go 官方博客，关注语言演进和最佳实践更新
参考资源
- Go 官方网站：https://go.dev/
- Go 标准库文档：https://pkg.go.dev/std
- Go by Example：https://gobyexample.com/
- Effective Go：https://go.dev/doc/effective_go
- Go 常见问题：https://go.dev/doc/faq
- Go 项目实战社区案例和开源项目源码
本文力求在讲解技术细节的同时兼顾工程实用性。Go 语言的设计简洁但不简单，掌握它需要持续的实践和反思。希望这篇文章能成为你学习道路上的一个可靠参考。
singleflight 在生产中的高级用法
在真实场景下，singleflight 不仅仅是合并请求那么简单。比如，要防止单个 key 被长时间占用，可以结合 context timeout：
func (s *Service) GetWithTimeout(ctx context.Context, key string) (Value, error) {
ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
defer cancel()
v, err, _ := s.sf.Do(key, func() (any, error) {
return s.load(ctx, key)
})
if err != nil {
return Value{}, err
}
return v.(Value), nil
}
golang.org/x/sync/singleflight 的 Do 返回的结果中，第三个返回值表示是否共享（即是不是等待者）。这个信息有时很有用，可以统计缓存合并的效率。
singleflight 与缓存的层级设计
L1 cache（内存） -> L2 cache（Redis） -> singleflight -> 数据库，这是一个经典的读穿透防护架构。请求先查 L1，miss 后查 L2，再 miss 后进入 singleflight，只有第一个请求会到达数据库。各层都加 timeout 防止级联等待。这种多层缓存加 singleflight 的设计，在高并发读热点场景下非常有效，是大部分互联网公司的标准做法。
不要过度合并
singleflight 合并的是同一个 key 的请求。如果 key 设计得太粗（如所有用户的请求用一个 key），会导致不必要的串行化。key 应该精确到具体的资源或数据项。
singleflight 的副作用：雪崩还是雪崩转移
singleflight 把数据库的雪崩转移到了等待 goroutine 上。如果有 1000 个请求同时 miss，singleflight 合并后变成 1 个请求查数据库 + 999 个等待结果。如果第一个请求查数据库时很慢（5 秒），那 999 个 goroutine 都会等待 5 秒。这虽然保护了数据库不被压垮，但大量等待的 goroutine 仍然占用内存和调度资源。
缓解方式：
- 给数据库查询加超时（context with timeout）。
- 给等待者也加超时（context done 时退出等待）。
- 使用多级缓存，减少到达 singleflight 的请求数。
singleflight 不是银弹，理解它的副作用才能做出正确的系统设计。
singleflight 在数据库查询中的实战
假设你的应用有一个热门配置 key（比如首页推荐位），所有请求都需要读取这个配置，缓存 1 分钟。在缓存过期的瞬间，大量请求会同时冲向下游数据库。使用 singleflight 后，只有一个请求真正执行 SELECT * FROM config WHERE key='homepage'，其他请求等待复用结果。等待时间对应一次数据库查询的 RTT。如果没有 singleflight，数据库 connection pool 会瞬间被占满，后续请求排队超时。singleflight 把"缓存击穿"变成"一次慢请求"，系统整体可用性大幅提升。这是 singleflight 最经典的用例之一，效果立竿见影。
在实际部署中，可以配合 prometheus 监控 singleflight 的合并命中率。如果命中率极低，说明 key 设计太细（比如每个请求都带了 trace_id），或者并发量不高。如果命中率极高但耗时也很长，说明到达 singleflight 的请求仍然过多，应该在前面加一层更粗粒度的缓存（如"所有配置的缓存"而非"单个配置的缓存"）。
singleflight 和缓存的协同监控
单看缓存命中率是不够的，还需要看 singleflight 合并率：
type SFMetrics struct {
singleCalls atomic.Int64
sharedCalls atomic.Int64
}
func (m *SFMetrics) Ratio() float64 {
shared := m.sharedCalls.Load()
total := m.singleCalls.Load() + shared
if total == 0 {
return 0
}
return float64(shared) / float64(total)
}
如果合并率接近 0，说明 singleflight 没发挥效果（key 设计太细或并发不够高）；如果合并率很高但查询耗时也非常长，说明数据库压力大，需要提前预热或扩容。
最后建议
singleflight 是缓存防护体系中最轻量、最有效的组件之一。理解它并正确配置，能极大地提高系统在面对热点数据和高并发 miss 时的稳定性。从小范围开始（如某一个热门接口）验证效果，逐步推广到更多接口。不要一开始就全量上线，先观察数据再大规模使用。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。