本文介绍一种基于单调度协程 + 每 id 独立通道的 go 并发控制模式，可安全、无锁、低开销地确保同一 id 的任务始终由至多一个 goroutine 串行执行，适用于无显式生命周期边界（如“事务结束”）的长期 id 复用场景。
本文介绍一种基于单调度协程 + 每 id 独立通道的 go 并发控制模式，可安全、无锁、低开销地确保同一 id 的任务始终由至多一个 goroutine 串行执行，适用于无显式生命周期边界（如“事务结束”）的长期 id 复用场景。
在构建高并发 Web 服务时，常遇到一类典型需求：对具有相同业务标识（如数据库主键 id）的请求，必须严格串行化其关键操作——例如更新某用户账户余额、处理某设备的配置变更等。若并发执行，极易引发数据竞争或状态不一致。但传统方案（如全局 sync.Map + 每 ID 动态 sync.Mutex + 手动引用计数 + 定期 GC）不仅逻辑复杂、易出死锁，还难以保证资源及时释放与长周期 ID 的正确复用。
更优解是采用 “中心化调度 + 按 ID 分流通道” 模式：仅由一个长期运行的调度协程（dispatcher）统一管理所有 ID 对应的执行通道与状态，彻底规避多协程竞争 map 和 mutex 的风险。每个 ID 拥有专属的无缓冲或有缓冲 channel，调度器负责将任务派发至对应 channel；而每个 ID 最多存在一个工作协程（worker），持续从该 channel 接收并执行任务。关键在于：worker 不自行决定退出，而是向 dispatcher 发送完成信号；dispatcher 根据内部计数器（记录待处理任务数）自主判断是否终止 worker 并清理资源。
以下为完整可运行实现：
package main
import (
"fmt"
"time"
)
// Task 表示待执行的任务
type Task struct {
ID string
Work func()
Done chan<- struct{} // 用于通知 dispatcher 当前任务完成
}
// Dispatcher 调度器核心结构
type Dispatcher struct {
workCh chan Task
stopCh chan struct{}
idState map[string]*idState // id -> {ch, count}
}
type idState struct {
ch chan Task
count int
}
func NewDispatcher() *Dispatcher {
return &Dispatcher{
workCh: make(chan Task),
stopCh: make(chan struct{}),
idState: make(map[string]*idState),
}
}
func (d *Dispatcher) Run() {
defer close(d.stopCh)
for {
select {
case task := <-d.workCh:
d.handleNewWork(task)
case <-d.stopCh:
return
}
}
}
func (d *Dispatcher) handleNewWork(task Task) {
state, exists := d.idState[task.ID]
if !exists {
// 首次为该 ID 创建 channel 和 worker
ch := make(chan Task, 1) // 可根据吞吐调整缓冲区大小
d.idState[task.ID] = &idState{ch: ch, count: 0}
go d.worker(task.ID, ch)
}
// 无论是否存在，均发送任务并递增计数
state.ch <- task
state.count++
}
func (d *Dispatcher) worker(id string, ch <-chan Task) {
for {
select {
case task := <-ch:
task.Work()
if task.Done != nil {
task.Done <- struct{}{}
}
case <-d.stopCh:
return
}
}
}
// Submit 提交任务到调度器（线程安全）
func (d *Dispatcher) Submit(id string, work func()) {
done := make(chan struct{}, 1)
d.workCh <- Task{ID: id, Work: work, Done: done}
// 可选：同步等待任务完成（若需结果）
<-done
}
// Stop 停止调度器（需配合 graceful shutdown）
func (d *Dispatcher) Stop() {
close(d.workCh)
<-d.stopCh
}
// 示例使用
func main() {
dispatcher := NewDispatcher()
go dispatcher.Run()
defer dispatcher.Stop()
// 模拟多个请求：相同 ID 的任务将被串行执行
for i := 0; i < 5; i++ {
id := "user_123"
go func(i int) {
fmt.Printf("Request %d for %s submitted\n", i, id)
dispatcher.Submit(id, func() {
fmt.Printf("Executing request %d for %s...\n", i, id)
time.Sleep(2 * time.Second) // 模拟耗时操作
fmt.Printf("Finished request %d for %s\n", i, id)
})
}(i)
}
time.Sleep(15 * time.Second) // 等待所有任务完成
}✅ 关键优势说明：
- 零锁设计：所有 map 访问、channel 创建/销毁均由单个 dispatcher 协程完成，完全避免 sync.Mutex 或 sync.RWMutex；
- 自动资源回收：worker 退出由 dispatcher 决策（通过 count 判断），无需手动 GC 或引用计数；
- 长 ID 生命周期友好：ID 可闲置数天后再次激活，调度器会自动重建 channel 与 worker；
- 弹性缓冲控制：通过调整 make(chan Task, N) 的缓冲大小，可在吞吐与内存间权衡（N=0 为严格 FIFO，N>0 可缓解突发流量）；
- 可扩展性强：支持添加超时控制、任务优先级、失败重试等策略，只需在 dispatcher 中增强状态机逻辑。
⚠️ 注意事项：
- 调度器本身是单点，但因只做轻量消息转发（无 IO/计算），实际性能瓶颈极低；若极端高并发（>10k QPS），可考虑分片（sharding by ID hash）；
- Submit 默认同步等待完成，若需纯异步，可移除 done channel 逻辑；
- 生产环境建议为 workCh 设置合理缓冲（如 make(chan Task, 1024)）并监控积压，防止 dispatcher 成为背压源头；
- 若任务可能 panic，应在 worker 内部加 recover()，避免 worker 意外退出导致后续任务丢失。
该模式本质是将“并发控制”问题转化为“消息路由”问题，以清晰的状态流转替代脆弱的锁协同，是 Go 生态中符合 CSP 哲学的优雅实践。
