Go语言实现防缓存击穿：Singleflight原理与代码解析

方予

发布时间：2026-10-15| 5人浏览过

原创

在Go语言的高并发服务中，如何解决热点缓存Key突然失效时大量请求直接穿透至数据库的问题？Singleflight提供了一种优雅的解决方案：通过将同时到达的重复请求合并为单一的实际执行，有效降低了后端负载。本文将深入分析其工作逻辑并提供核心实现参考。

缓存击穿的背景

在高并发系统中，热点Key（如热门商品详情、实时热搜等）通常会配合Redis等高速缓存使用。然而，当该Key的缓存恰好过期且没有设置永不过期策略时，一瞬间涌入的大量请求无法命中缓存，从而直接穿透至数据库。这种“缓存击穿”现象可能导致数据库连接池耗尽甚至服务宕机。

为了平滑这一过程，除了常规的互斥锁或永不过期方案外，Go的第三方扩展包 golang.org/x/sync/singleflight 提供了一种更高效的处理思路：让多个发起相同Key查询的请求合并执行，只有一个请求实际访问底层数据源，其余请求共享该次调用的结果。

核心工作原理

Singleflight的设计目标是保证在同一时间，对于同一个Group和Key的组合，只会有一个goroutine真正去执行函数fn（例如查询数据库）。具体流程如下：

请求路由与去重：当第一个请求到达时，如果Group内尚未存在该Key的记录，它将作为主责请求进行实际调用。
请求合并：在第一个请求正在进行期间，如果有其他相同的请求到达，它们会被识别为重复请求并被挂起阻塞。
结果同步：当首个请求完成并返回结果后，所有被阻塞的请求将直接从内存中读取已计算好的结果并解除阻塞。

代码级实现与解析

以下是Singleflight的基础结构拆解，帮助理解如何通过数据结构实现上述功能。在实际生产环境中，建议直接使用官方提供的 import "golang.org/x/sync/singleflight"。

第1步：定义数据结构

主要涉及两个核心结构：Caller用于存储当前任务的结果、错误状态以及控制等待信号；Group用于管理所有的请求映射关系。

package singleflight

import (
	"sync"
)

// 简单的计数器，便于后续观察统计
var WaitCount int
var DirectCount int

// Caller 封装了单个正在执行的请求
type Caller struct {
	val interface{} // 函数执行返回值
	err error       // 函数执行错误
	wg sync.WaitGroup // 同步等待组，用于唤醒同组的其他协程
}

// Group 包含所有的pending Callers
type Group struct {
	mu sync.RWMutex      // 读写锁保护map安全
	m  map[string]*Caller // key -> Caller 的映射表
}

第2步：核心逻辑Do方法

Do方法是Singleflight的核心入口，接收一个唯一的key和一个回调函数fn。它负责判断当前是否已有请求在处理该key，如果没有则创建新任务并执行，否则进入等待状态。

func (g *Group) Do(key string, fn func() (interface{}, error)) (interface{}, error) {
	// 加写锁保护全局map的状态变更
	g.mu.Lock()
	if g.m == nil {
		g.m = make(map[string]*Caller)
	}

	// 检查是否有正在运行的同名Caller
	c, ok := g.m[key]
	if ok {
		// 存在，释放全局锁，进入等待状态
		g.mu.Unlock()
		c.wg.Wait()
		WaitCount++ // 记录合并掉的请求数
		return c.val, c.err
	}

	// 不存在，新建Caller并放入map中
	c = &Caller{}
	g.m[key] = c
	c.wg.Add(1) // 设置等待计数
	g.mu.Unlock()

	// 执行真正的业务逻辑（如查DB）
	c.val, c.err = fn()
	c.wg.Done() // 标记当前请求结束，唤醒其他等待者

	// 从map中删除已完成的任务，节省内存
	g.mu.Lock()
	delete(g.m, key)
	g.mu.Unlock()

	DirectCount++ // 记录直接触发的请求数
	return c.val, c.err
}

测试验证

通过并发模拟10000个请求去获取同一个Key的数据，来验证Singleflight的效果。正常情况下，只有极少部分请求会触发实际的fn函数执行，绝大多数都会走阻塞等待路径。

func TestGroup_Do(t *testing.T) {
	sg := &Group{}
	wg := sync.WaitGroup{}

	// 启动10000个并发协程
	for i := 0; i < 10000; i++ {
		fn := func() (interface{}, error) {
			return i, nil // 此处模拟耗时IO操作
		}
		wg.Add(1)
		go func() {
			defer wg.Done()
			_, err := sg.Do("test-key", fn)
			_ = err // 忽略具体错误
		}()
	}

	wg.Wait()
	fmt.Println("waitCount:", WaitCount)
	fmt.Println("DirectCount:", DirectCount)
}