Go singleflight 思路入门：避免缓存击穿时重复查询

缓存能减轻数据库压力，但缓存失效那一刻也可能制造压力。比如热门用户资料过期，突然来了 200 个请求，如果每个请求都发现缓存没有，然后同时查数据库，数据库会被瞬间打满。这类问题常被称为缓存击穿。的思路是：同一个 key 的并发请求，只让第一个请求真正执行查询，其他请求等它的结果。

PlumePHP 10 分钟阅读 4996 字

缓存能减轻数据库压力，但缓存失效那一刻也可能制造压力。比如热门用户资料过期，突然来了 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 更短，几秒到几十秒。太长了会让新创建的数据延迟可见。

常见陷阱

  1. key 设计太粗：所有用户共享一个 key，会串行化本不相关的请求。key 要精细到资源粒度。
  2. 加载函数没有超时：等待者复用结果，但如果第一个请求卡住，所有等待者都会卡住。context 超时是必须的。
  3. 错误结果被所有请求共享：第一个请求失败后，所有等待者拿到同个错误。这通常合理，但要考虑是否需要降级策略。

对比表

策略解决的问题何时使用
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 相关面试，以下概念是高频考点：

  1. goroutine 和线程的区别
  2. channel 的缓冲和非缓冲用法
  3. defer 的执行顺序和与返回值的关系
  4. map 的并发不安全性和解决方案
  5. interface 的隐式实现和类型断言
  6. slice 的底层数组和 append 机制
  7. GC 的基本原理和调优参数
  8. context 的使用场景和超时控制
  9. error 的包装和 errors.Is/errors.As
  10. 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 泄漏。

常见坑与避坑指南

  1. 不要信任用户输入：无论表单、JSON、Cookie 还是 HTTP Header，都当作不可信数据处理，做校验和转义。
  2. 资源要释放：文件、数据库连接、HTTP 响应体都要及时关闭。defer 是一个好习惯。
  3. 不要忽略错误：即使 defer file.Close() 可能返回错误，至少记录日志。完全忽略错误是 bug 的温床。
  4. 不要滥用 goroutine：每个 goroutine 都要有明确的退出路径。使用 sync.WaitGroup 和 context 管理生命周期。
  5. 不要硬编码配置：端口、路径、超时时间、密钥都应该从配置读取，让程序适应不同环境。
  6. 不要过早优化：先让代码正确和可读，再用 benchmark 和 profile 找到真正的热点。

延伸阅读与实践建议

读完本文后，建议完成以下实践：

  1. 把文中所有示例代码在自己的机器上跑一遍
  2. 给示例代码补充错误分支的测试用例
  3. 尝试基于本文内容构建一个小型完整项目
  4. 在 review 他人的 Go 代码时，检查本文提到的边界是否被覆盖
  5. 订阅 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 仍然占用内存和调度资源。

缓解方式：

  1. 给数据库查询加超时（context with timeout）。
  2. 给等待者也加超时（context done 时退出等待）。
  3. 使用多级缓存，减少到达 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 时的稳定性。从小范围开始（如某一个热门接口）验证效果，逐步推广到更多接口。不要一开始就全量上线，先观察数据再大规模使用。

继续阅读

探索更多技术文章

浏览归档，发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页