用 Go singleflight 消除缓存击穿：高并发场景下的请求合并与优雅降级

在高并发系统中，缓存击穿（Cache Breakdown）是一个经典但容易被低估的问题。当某个热点缓存键同时失效或尚未写入时，成千上万的并发请求会瞬间穿透缓存层，直接冲击后端数据库，形成所谓的 "惊群效应"（Thundering Herd）。这种流量洪峰往往超出数据库的连接池容量，导致服务雪崩。

Go 语言生态提供了一个优雅的解决方案：golang.org/x/sync/singleflight 包。它通过请求合并机制，确保同一资源的并发查询只执行一次，结果共享给所有等待的调用方，从而将数据库压力从 N 次降为 1 次。

缓存击穿的本质

想象一个社交平台场景：某位头部用户发布了新内容，数百万粉丝同时刷新页面。如果这条内容尚未被缓存，每个请求都会尝试从数据库加载。即使数据库查询仅需 50 毫秒，并发量为 1000 时，瞬时连接需求也可能压垮连接池。

传统的缓存策略（如设置随机过期时间）可以缓解但无法根除这个问题。真正的解决之道是在缓存层与数据源之间引入请求去重机制—— 这正是 singleflight 的设计目标。

singleflight 的核心机制

singleflight.Group 提供了 Do(key string, fn func() (interface{}, error)) 方法，其工作逻辑如下：

1. 首次调用：当某个 key 首次请求时，singleflight 执行 fn 函数，其他相同 key 的并发调用进入等待队列
2. 结果广播：fn 执行完成后，结果被广播给所有等待的 goroutine
3. 共享标识：返回值中的 shared 布尔值标识调用者是否共享了他人的执行结果

这种机制天然适合缓存场景：即使 10 万个 goroutine 同时请求同一个未缓存的 key，数据库也只会收到 1 次查询。

完整实现模式

生产环境中，singleflight 需要与缓存层配合使用，形成 "双重检查" 模式：

type Store struct {
    cache Cache
    group singleflight.Group
}

func (s *Store) Get(ctx context.Context, key string) (string, error) {
    // 第一层检查：快速路径
    if v, ok := s.cache.Get(key); ok {
        return v, nil
    }
    
    // singleflight 保护下的慢路径
    v, err, shared := s.group.Do(key, func() (interface{}, error) {
        // 第二层检查：防止缓存已回填
        if v, ok := s.cache.Get(key); ok {
            return v, nil
        }
        
        // 执行数据库查询
        data, err := s.fetchFromDB(ctx, key)
        if err != nil {
            return nil, err
        }
        
        // 回填缓存
        s.cache.Set(key, data, ttl)
        return data, nil
    })
    
    if err != nil {
        return "", err
    }
    
    // shared 可用于监控：统计节省了多少次查询
    metrics.RecordSingleflightShared(key, shared)
    return v.(string), nil
}

关键细节在于第二层缓存检查。在 singleflight 获得执行权后、实际查询前再次检查缓存，可以防止缓存已在等待期间被其他流程回填导致的重复查询。

可落地的参数与监控

超时控制：singleflight 本身不提供超时机制，但 fn 函数内部应使用 context.WithTimeout 控制数据库查询时长。建议将缓存击穿场景下的查询超时设置为正常值的 1.5-2 倍，以应对可能的连接池竞争。

Key 设计：singleflight key 应与缓存 key 保持一致或建立稳定映射关系。避免使用包含时间戳或随机数的 key，否则将失去请求合并的意义。

监控指标：

• shared=true 的请求占比：反映 singleflight 的命中率，理想情况下缓存击穿时该值应接近 100%
• 在 singleflight 中等待的 goroutine 数量：可通过自定义 Group 的统计接口获取
• 从 singleflight 获取结果到返回的延迟：反映结果广播的开销

分布式场景的补充策略

singleflight 是进程级保护，在微服务多实例部署时，每个实例仍会独立查询数据库。此时需要分层防护：

1. 进程层：singleflight 消除单实例内的重复请求
2. 分布式层：使用 Redis 的 SETNX 或 Redlock 实现跨实例的查询互斥
3. 预热机制：对已知热点数据，在缓存过期前主动刷新，避免被动击穿

Redisson 等客户端库提供了开箱即用的分布式锁实现，与 singleflight 配合可构建完整的防护体系。

边界与注意事项

singleflight 并非万能。如果 fn 函数执行时间过长，会阻塞所有等待该 key 的请求。因此，singleflight 保护下的操作应当是幂等的、可重试的，且具备明确的超时控制。对于可能失败的查询，建议实现降级策略：当数据库不可用时，返回缓存中的过期数据（stale cache）或默认值，而非让请求在 singleflight 中无限等待。

通过合理使用 singleflight，系统可以在不引入复杂分布式锁的情况下，以极低的代码成本消除缓存击穿风险。这种 "零冗余查询" 的设计哲学，体现了 Go 语言在高并发工程实践中的简洁与高效。

参考来源

• kerkour.com: How to avoid the thundering herd problem in Go with the singleflight package
• dev.to: Cache Breakdown Prevention with Go's singleflight

systems