本文介绍如何在 go 中优雅地实现任务 id 去重与结果广播，通过中间协调协程替代手动维护 channel+map+mutex 的复杂同步逻辑，避免死锁并支持高并发下的请求合并（request coalescing）。
本文介绍如何在 go 中优雅地实现任务 id 去重与结果广播，通过中间协调协程替代手动维护 channel+map+mutex 的复杂同步逻辑，避免死锁并支持高并发下的请求合并（request coalescing）。
在构建高吞吐、低延迟的服务时，常遇到一类典型优化场景：多个客户端并发提交相同 ID 的任务（如查询同一用户数据、渲染同一模板），而底层处理逻辑开销巨大（如 I/O 密集型或 CPU 密集型计算）。若不加干预，每个请求都会触发一次完整处理，造成严重资源浪费。此时，“任务合并”（coalescing）成为关键优化手段——即将同 ID 的多个待处理任务暂存，仅执行一次真实计算，并将结果广播给所有原始请求者。
最直观的思路是用 map[ID][]Task 配合 sync.Mutex 管理待处理任务队列，再辅以一个 chan Task 供工作协程消费。但这种方案需在多处手动加锁、维护 map 与 channel 的一致性，易出错且扩展性差。更优解是引入无锁的中间协调协程（coordinator goroutine），它作为单一可信中心，统一接管任务分发与结果路由。
✅ 推荐方案：单协程协调器（Lock-Free Coordinator）
核心思想是分离关注点：
- 生产者只向 queue chan Task 发送任务；
- 工作协程只从 worker chan Task 消费并返回结果到 response chan *TaskResult；
- 协调协程独占管理 active map[TaskID][]*Task，负责去重、暂存、广播，全程无需 mutex。
基础版本如下（注意：此版存在潜在死锁风险，仅作逻辑演示）：
go func() {
active := make(map[TaskID][]*Task)
for {
select {
case task := <-queue:
if len(active[task.ID]) == 0 {
worker <- task // 触发首次计算
}
active[task.ID] = append(active[task.ID], task)
case r := <-response:
for _, t := range active[r.ID] {
t.Result <- r.Result // 广播结果
}
delete(active, r.ID) // 清理已完成 ID
}
}
}()⚠️ 关键陷阱：当 worker 通道阻塞（如所有工作协程繁忙），worker
✅ 生产就绪方案：非阻塞 Select 调度
为彻底规避阻塞，我们利用 Go select 的 nil channel 特性（对 nil channel 的操作永不就绪），动态切换输入/输出通道状态：
go func() {
active := make(map[TaskID][]*Task)
var next *Task // 缓存待发送的任务
in := queue // 当前监听：接收新任务
var out chan<- *Task // 当前监听：发送至 worker（初始为 nil）
for {
select {
case task := <-in:
// 收到新任务：暂存，切换为向 worker 发送
next = task
in, out = nil, worker // 关闭输入，开启输出
case out <- next:
// 成功发送：恢复接收，清空缓存
in, out = queue, nil
next = nil
case r := <-response:
// 处理响应：广播 + 清理
if tasks, ok := active[r.ID]; ok {
for _, t := range tasks {
t.Result <- r.Result
}
delete(active, r.ID)
}
}
}
}()该设计确保协调协程永不阻塞：
- 若 worker 拥堵，out
- response 通道始终可被监听，保证结果能及时广播；
- active map 仅由单个协程访问，天然线程安全，零 mutex。
? 补充增强建议
- 结果缓存：在 active map 外增加 LRU 缓存（如 github.com/hashicorp/golang-lru），对近期完成的 ID 直接返回缓存结果，进一步降低重复计算概率。
- 超时控制：为每个 active[ID] 记录时间戳，定期清理滞留任务，防止内存泄漏。
- 错误传播：response 通道应携带 error 字段，协调协程需将错误统一写入所有对应 task.Result，避免部分请求永远阻塞。
- 监控埋点：统计 len(active) 峰值、平均合并率（len(tasks)/1）、广播延迟等指标，用于容量评估。
✅ 总结
任务合并不是简单的“去重”，而是对请求生命周期的精细编排。本文提出的基于 select 动态通道切换的协调协程模式，以极简代码实现了：
✅ 无锁安全（single-owner map）
✅ 防死锁（非阻塞调度）
✅ 高内聚（职责清晰，无共享状态泄露）
✅ 易扩展（缓存、超时、监控均可正交叠加）
它比直接操作 channel+map+mutex 更健壮，也比引入第三方并发集合（如 concurrent-map）更轻量。在微服务网关、GraphQL 批量解析、分布式缓存穿透防护等场景中，这一模式已成为 Go 生态中 request coalescing 的事实标准实践。
