Go singleflight 防缓存击穿实战：相同请求只查一次数据库

高并发接口里最怕一种场景：某个热点商品缓存刚好过期，几十个请求同时打进来，全部发现缓存未命中，然后一起去查数据库。缓存本来是用来保护数据库的，结果在过期瞬间反而把压力集中打过去，这就是常说的缓存击穿。

Go 里可以用 golang.org/x/sync/singleflight 处理这类问题。它的思路很朴素：同一个 key 同一时间只允许一个请求真正去查后端，其他请求等待并共享这次结果。本文用商品详情接口做例子，讲清代码怎么写、key 怎么设计，以及超时兜底怎么补。

适合人群

适合已经写过 Go HTTP 服务、用过 Redis 或本地缓存的开发者。如果你遇到过热点 key、缓存过期瞬间数据库抖动、接口突然慢一阵，这篇文章可以直接参考。

目录

• 先看缓存击穿的请求流向
• 用 singleflight 合并同 key 请求
• 封装商品详情查询代码
• 给等待请求加超时兜底
• 常见坑位和上线建议

先看缓存击穿的请求流向

假设商品 product:1001 是一个热点 key。缓存过期的一瞬间，多个请求同时进入接口，它们都会走到“缓存未命中”分支。如果没有合并机制，每个请求都会发起一次数据库查询。

更稳的做法是：缓存未命中后，先按业务 key 进入 singleflight。同一个 key 下只有第一个请求去查数据库，查询结束后回填缓存，其他请求直接共享这次结果。

用 singleflight 合并同 key 请求

先安装依赖：

go get golang.org/x/sync/singleflight

核心类型是 singleflight.Group。它的 Do 方法接收一个 key 和一个函数：同一时刻相同 key 的调用只会让函数真正跑一次，其他调用拿到共享结果。

package product

import (
    "context"
    "fmt"
    "time"

    "golang.org/x/sync/singleflight"
)

type Product struct {
    ID    int64
    Name  string
    Price int64
}

type Service struct {
    group singleflight.Group
    cache Cache
    repo  Repository
}

type Cache interface {
    Get(ctx context.Context, key string) (Product, bool)
    Set(ctx context.Context, key string, value Product, ttl time.Duration) error
}

type Repository interface {
    FindProduct(ctx context.Context, id int64) (Product, error)
}

这里把缓存和数据库访问都抽成接口，方便测试，也避免示例被具体 Redis 客户端绑死。

封装商品详情查询代码

下面是一个完整的查询流程：先读缓存；没命中时进入 singleflight；真正查库的请求负责回填缓存；等待中的请求共享同一份结果。

func (s *Service) GetProduct(ctx context.Context, id int64) (Product, error) {
    cacheKey := fmt.Sprintf("product:%d", id)

    if product, ok := s.cache.Get(ctx, cacheKey); ok {
        return product, nil
    }

    value, err, shared := s.group.Do(cacheKey, func() (any, error) {
        if product, ok := s.cache.Get(ctx, cacheKey); ok {
            return product, nil
        }

        product, err := s.repo.FindProduct(ctx, id)
        if err != nil {
            return Product{}, err
        }

        _ = s.cache.Set(ctx, cacheKey, product, 5*time.Minute)
        return product, nil
    })
    if err != nil {
        return Product{}, err
    }

    product := value.(Product)
    if shared {
        // 可以在这里记录一次共享命中，观察热点 key 是否被合并。
    }
    return product, nil
}

注意函数内部又读了一次缓存。这一步很关键：第一个请求进入 singleflight 后，可能有另一个节点已经把缓存写好了；再读一次可以避免不必要的数据库查询。

给等待请求加超时兜底

Do 会等待同一个 key 的首次查询结束。如果数据库很慢，后面的请求也会一起等。对接口来说，更推荐使用 DoChan 搭配 context，让等待请求有机会按时返回兜底结果。

func (s *Service) GetProductWithTimeout(ctx context.Context, id int64) (Product, error) {
    cacheKey := fmt.Sprintf("product:%d", id)

    if product, ok := s.cache.Get(ctx, cacheKey); ok {
        return product, nil
    }

    waitCtx, cancel := context.WithTimeout(ctx, 800*time.Millisecond)
    defer cancel()

    resultCh := s.group.DoChan(cacheKey, func() (any, error) {
        product, err := s.repo.FindProduct(ctx, id)
        if err != nil {
            return Product{}, err
        }
        _ = s.cache.Set(ctx, cacheKey, product, 5*time.Minute)
        return product, nil
    })

    select {
    case result := 

这张图对应的是等待请求的兜底路径：同一个 key 先进入等待队列，如果首次查询按时完成就共享结果；如果超过接口预算，就返回超时，由上层决定是否读取旧缓存、降级字段或提示稍后重试。

常见坑位和上线建议

第一，key 要包含完整业务维度。 商品详情只用 product:id 可能够用，但如果接口还按地区、语言、用户等级返回不同字段，key 就要把这些维度带上，否则会把不该共享的结果混在一起。

第二，不要把所有请求塞进同一个 key。 singleflight 是按 key 合并，不是全局锁。key 太粗会让无关请求互相等待，反而拖慢接口。

第三，配合缓存空值和随机过期时间。 singleflight 能减少同一时刻的重复查询，但不能替代缓存空值、TTL 抖动、限流和降级。热点接口最好组合使用。

第四，记录 shared 指标。 shared 为 true 说明有请求共享了结果。把它打到指标系统里，可以看到哪些 key 经常被合并，从而判断热点是否集中。

总结

singleflight 适合解决“同一个 key 在短时间内被重复查询”的问题。它不会让接口变成缓存系统，但可以把缓存过期瞬间的多次数据库查询压成一次，再配合回填缓存、等待超时和降级策略，让热点接口更稳。

落地时记住三个点：key 必须足够准确，函数内部最好二次检查缓存，等待路径要有超时预算。这样写出来的 Go 接口，面对热点 key 时会从容很多。