首页 > Golang > Go教程

Go singleflight 怎么合并同一请求：缓存失效时别让 500 个请求一起回源

来源：17golang原创

时间：2026-07-17 16:15:57 109浏览收藏

缓存里的热门商品刚过期，500 个并发读取并不会排队等缓存恢复；它们很可能同时落到数据库或商品服务。这类峰值不一定需要先上复杂的分布式协调。若重复请求在同一个 Go 实例内重叠，singleflight 可以把“同一个业务 key 的加载”合成一趟，其余调用等待同一份结果。

实践要点：

singleflight 放在缓存未命中后的读取入口，合并同一业务 key 的重叠回源。
Group 要随读取组件持续存活，key 必须包含租户、版本等可共享边界。
它不是缓存，也不会跨多个实例自动合并请求；超时与下游承载仍需单独核对。

singleflight 解决的不是缓存，而是重叠回源

把它看成读取入口的一层“请求合并器”更准确：第一个拿到 product:tenant-a:42 的调用负责加载；同 key 的后来者不再另起一次加载，而是等候该结果。Group.Do 的第三个返回值 shared 用来表明结果是否被多个调用复用。

因此它只在同一时间窗口内抑制重复工作。结果返回后，下一次读取仍会进入加载逻辑；要保存较长时间的结果，缓存层仍然要单独存在。把这两个职责混在一起，排查过期、预热和淘汰时会很难判断问题在哪一层。

Go singleflight 的原创工程证据截图，低饱和代码编辑器和请求轨迹显示同一缓存键的首个加载与等待调用复用结果

先确认压力点：缓存失效不是唯一触发条件

常见场景是热点 key 到期，也可能是启动后首批读取、短暂网络抖动后的重试，或一个上游接口被多个页面同时查询。判断能否合并，关键不在“请求数量很大”，而在这些请求是否确实需要同一份结果。

记录回源前后的计数，确认同一业务对象在很短时间内被反复读取。
确认读取没有依赖调用者私有状态，例如权限、语言、价格版本或草稿视图。
先设定下游超时和并发上限；请求合并只能减小重复量，不能让慢依赖变快。

例如商品详情若按租户、地区和版本返回不同内容，key 也必须携带这些维度。只写商品 ID，可能让本来不该共享的调用排到同一趟加载里，得到错误内容。

最小放置方式：让 Group 随读取组件存活

Group 不应在每次读取时新建，否则每个调用都拥有自己的合并器，等于没有合并。更合适的地方是负责读取的组件字段：组件存活期间，相同 key 才能相遇。下面的示例把业务值和 shared 一起交给调用方，便于把复用比例写入指标。

type ProductLoader struct {
    group  singleflight.Group
    store  ProductStore
}

func (l *ProductLoader) Load(tenant, id string) (Product, bool, error) {
    key := tenant + ":" + id

    value, err, shared := l.group.Do(key, func() (any, error) {
        return l.store.Load(tenant, id)
    })
    if err != nil {
        return Product{}, shared, err
    }

    product, ok := value.(Product)
    if !ok {
        return Product{}, shared, fmt.Errorf("product type mismatch")
    }
    return product, shared, nil
}

调用方不需要因为 shared 为真就改变返回内容；它主要是观测线索。高峰期它持续升高，说明合并确实覆盖了重复读取。若一直为假，要检查 key 是否过细、Group 是否被频繁重建，或请求本来就没有时间重叠。

两个常见反例：单一 key 和把它当成持久缓存

第一个反例是把所有读取都塞进固定 key。这样虽然能减少回源，却会把不相干用户的读取串成一列，延迟和隔离边界一起变差。key 至少应描述“可共享结果”的业务范围，例如租户、资源 ID、内容版本和必要的展示维度。

第二个反例是认为它会替代缓存。singleflight 只管正在进行的一趟函数调用，不保存随后请求可读取的值。缓存命中、缓存过期、负缓存、预热和淘汰仍应由原有缓存策略负责；它放在缓存未命中之后、真正回源之前更容易解释。

多实例边界：每个实例只会合并自己看到的请求

Group 是进程内对象。把服务部署成多个实例后，负载均衡可能把同一个 key 的请求分到不同实例；每个实例都可能各自保留一趟加载。这不是缺陷，而是它的工作范围。若跨实例的回源仍然过大，需要结合共享缓存、合理的过期抖动、队列或专门的协调方案评估，不能仅凭 singleflight 推断全局只剩一次回源。

Go singleflight 的原创工程证据截图，低饱和日志检查面板显示 key 范围、shared 指标、超时和多实例边界

上线前按四项核对，别只看能否编译

核对项	应看到的信号	发现异常时先查什么
key 范围	同一 key 的结果确实可共享	租户、地区、权限、版本是否遗漏
复用比例	峰值时 `shared` 有合理增长	Group 生命周期、key 颗粒度、流量是否分散
失败表现	同一批等待者收到一致的失败结果	下游超时、重试节奏、错误缓存策略
实例边界	单实例回源下降，跨实例仍可解释	副本数、路由、共享缓存和热点 key

等待者也会继承首个加载的结果，其中包括错误。因此外层仍要有明确的超时、重试和降级策略。若调用方需要在等待中自行放弃，可研究 DoChan 的单次接收方式；官方文档特别说明它返回的通道不会关闭，不能把它当作可持续遍历的通道。

核对来源

Go Package 文档：golang.org/x/sync/singleflight：核对 Group.Do 的同 key 重叠调用合并、shared 返回值、DoChan 的通道说明和 Forget 行为。
Go Package 文档：golang.org/x/sync：核对该模块中 singleflight 的职责为重复调用抑制。