本文介绍如何在 go 中避免对同一资源的重复昂贵请求，通过请求合并机制让并发请求共享首个请求的结果，从而提升缓存命中率与系统吞吐量。
本文介绍如何在 go 中避免对同一资源的重复昂贵请求，通过请求合并机制让并发请求共享首个请求的结果，从而提升缓存命中率与系统吞吐量。
在高并发 Web 或微服务场景中，常遇到“缓存穿透+重复计算”问题：客户端 A 请求资源 A，因缓存未命中而触发耗时的后端计算；此时客户端 B 同样请求资源 A，缓存仍为空，若直接发起第二轮计算，不仅浪费资源，还加剧延迟与负载。理想方案是让 B 阻塞等待 A 的结果，而非重复执行——这种模式称为 Request Coalescing（请求合并）。
Go 原生不提供开箱即用的请求合并库，但凭借其强大的并发原语（channel、sync.Map、sync.Once 等），可构建轻量、线程安全且无全局锁瓶颈的实现。核心思想是：为每个唯一键（如 resource ID）动态创建一个“协调单元”，由单一 goroutine 负责该键的所有请求调度与结果分发，从而天然规避竞态，无需全局互斥锁。
✅ 推荐实现：基于键路由的无锁协调器
以下是一个生产就绪的简化示例，使用 sync.Map 存储按 key 分片的 *requestGroup，每个 group 内部通过 channel 实现请求排队与结果广播：
type Result struct {
Data interface{}
Err error
}
type requestGroup struct {
mu sync.RWMutex
pending []chan<- Result // 所有等待该 key 的响应通道
result *Result // 缓存结果（nil 表示尚未完成）
}
// 全局协调器：按 key 路由到对应 group
type Coalescer struct {
groups sync.Map // string => *requestGroup
}
func (c *Coalescer) Do(key string, fetch func() (interface{}, error)) (interface{}, error) {
// Step 1: 获取或创建该 key 对应的 group
group, _ := c.groups.LoadOrStore(key, &requestGroup{})
rg := group.(*requestGroup)
// Step 2: 尝试快速读取已缓存结果（乐观读）
rg.mu.RLock()
if rg.result != nil {
r := *rg.result
rg.mu.RUnlock()
return r.Data, r.Err
}
rg.mu.RUnlock()
// Step 3: 加写锁，检查是否已有 pending 请求（防重复启动 fetch）
rg.mu.Lock()
if rg.result != nil { // 双检锁：可能被其他 goroutine 在 unlock 间隙完成
r := *rg.result
rg.mu.Unlock()
return r.Data, r.Err
}
// 第一个请求：启动 fetch 并注册等待者
ch := make(chan Result, 1)
rg.pending = append(rg.pending, ch)
rg.mu.Unlock()
// Step 4: 执行实际计算（仅由第一个请求执行）
data, err := fetch()
result := Result{Data: data, Err: err}
// Step 5: 广播结果给所有等待者，并清理状态
rg.mu.Lock()
rg.result = &result
for _, ch := range rg.pending {
ch <- result
}
rg.pending = nil
rg.mu.Unlock()
// Step 6: 返回结果（当前 goroutine）
return data, err
}调用方式简洁明了：
coalescer := &Coalescer{}
data, err := coalescer.Do("resource:A", func() (interface{}, error) {
// 模拟昂贵操作：DB 查询 / HTTP 调用 / 计算渲染
time.Sleep(2 * time.Second)
return "cached_value", nil
})✅ 关键优势：
- 无全局锁瓶颈：sync.Map 是分段锁实现，requestGroup 锁粒度仅限单个 key；
- 零依赖：纯标准库，无第三方包耦合；
- 内存友好：group 在结果返回后自动被 GC（无长期持有 channel）；
- 可扩展：可通过哈希分片（如 key % N）进一步将 groups 拆分为多个 sync.Map，彻底消除 Map 级竞争。
⚠️ 注意事项与进阶建议
- 超时控制：上述示例未处理等待超时。实际使用中，应在 ch := make(chan Result, 1) 后配合 select + time.After 实现 per-request 超时，避免永久阻塞。
- 错误传播一致性：若 fetch() 失败，所有等待者均收到相同错误，符合幂等性预期；但需确保错误本身可安全跨 goroutine 传递（避免含 sync.Mutex 等不可拷贝字段）。
- 生命周期管理：长时间无请求的 requestGroup 可考虑定期清理（如结合 time.Now() 时间戳 + sync.Map.Range 扫描），防止内存泄漏（尤其 key 空间无限时）。
-
替代方案对比：
- singleflight.Group（golang.org/x/sync/singleflight）是官方推荐方案，语义更简洁，内部也采用类似分组 channel 模式，强烈建议优先选用；
- 若需深度定制（如带优先级、熔断、指标埋点），则上述手写模式更灵活。
✅ 总结
请求合并不是银弹，但它能显著缓解缓存雪崩与资源争抢。Go 的 channel 与轻量级 goroutine 天然适合构建此类协调逻辑。比起全局 map + mutex 的粗粒度方案，以 key 为单位隔离状态、用 channel 替代显式锁、辅以双检锁与 sync.Map 分片，是兼顾性能、可维护性与可扩展性的最佳实践路径。对于大多数场景，直接使用 singleflight.Group 即可满足需求；若需深度控制，则本文所展示的手动实现提供了清晰、可控的底层范式。
