引言
在高并发后端系统的开发中，并发模型的选型直接影响系统的吞吐量与可维护性。Go 语言凭借 Goroutine 和 Channel 两大原语，将并发编程的复杂度大幅降低。然而，真正发挥其威力需要理解几种核心并发模式。本文将从实际工程场景出发，梳理 Fan-Out/Fan-In、Pipeline 和 Worker Pool 三种模式的适用边界与实现要点。
一、Goroutine 与 Channel：并发编程的基石
Goroutine 是 Go 运行时管理的轻量级线程，初始栈大小仅 2KB，创建和切换成本远低于操作系统线程。一个典型的 Go 服务在运行期间可以轻松持有数十万个 Goroutine。
Channel 则是 Goroutine 之间的通信管道，遵循 CSP（Communicating Sequential Processes）模型，通过"不要通过共享内存来通信，而要通过通信来共享内存"这一设计哲学，从根本上避免了传统多线程编程中的数据竞争问题。
Go
// 有缓冲 channel 实现生产者-消费者
ch := make(chan int, 100)
go func() {
for i := 0; i < 1000; i++ {
ch <- i
}
close(ch)
}()
for v := range ch {
process(v)
}二、Fan-Out / Fan-In 模式
当单个 Goroutine 处理速度跟不上数据流入速度时，需要将任务分发给多个 Worker 并行处理（Fan-Out），再将结果汇聚（Fan-In）。
适用场景：批量数据处理、API 聚合调用、日志处理管线。
实现要点在于：使用 sync.WaitGroup 等待所有 worker 完成，通过合并 channel 将多路结果汇聚为单路输出。
Go
func fanIn(channels ...<-chan Result) <-chan Result {
out := make(chan Result)
var wg sync.WaitGroup
wg.Add(len(channels))
for _, ch := range channels {
go func(c <-chan Result) {
defer wg.Done()
for r := range c {
out <- r
}
}(ch)
}
go func() {
wg.Wait()
close(out)
}()
return out
}注意事项：
- Worker 数量应与 CPU 核心数和 I/O 特征匹配，CPU 密集型用 runtime.GOMAXPROCS(0) 作为上限，I/O 密集型可适度放大。
- 上游 channel 关闭后，Fan-In 的合并 channel 必须等所有 worker 结束后再关闭，否则会导致 panic。
三、Pipeline 模式
Pipeline 将数据处理流程拆分为多个阶段，每个阶段由一个或多个 Goroutine 负责，数据通过 Channel 在阶段间流转。
适用场景：ETL 数据管道、请求中间件链、编译流水线。
Go
// 阶段1：读取数据
func stage1(done <-chan struct{}, inputs []int) <-chan int {
out := make(chan int)
go func() {
defer close(out)
for _, v := range inputs {
select {
case out <- v:
case <-done:
return
}
}
}()
return out
}
// 阶段2：数据转换
func stage2(done <-chan struct{}, in <-chan int) <-chan int {
out := make(chan int)
go func() {
defer close(out)
for v := range in {
select {
case out <- v * v:
case <-done:
return
}
}
}()
return out
}关键设计原则：
- 每个阶段通过 done channel 支持优雅取消，防止 Goroutine 泄漏。
- 上游主动 close(channel) 通知下游数据已结束，避免使用哨兵值。
- 各阶段独立可测，只需构造 chan 即可单元测试单个阶段。
四、Worker Pool 模式
固定数量的 Worker Goroutine 从共享任务队列中取任务执行，是后端服务中最常用的并发控制手段。
适用场景：数据库连接池管理、HTTP 请求并发控制、任务调度器。
Go
type WorkerPool struct {
tasks chan func()
workers int
}
func NewWorkerPool(workers int) *WorkerPool {
return &WorkerPool{
tasks: make(chan func(), workers*2),
workers: workers,
}
}
func (wp *WorkerPool) Start() {
for i := 0; i < wp.workers; i++ {
go func() {
for task := range wp.tasks {
task()
}
}()
}
}调优建议：
- 任务 channel 的缓冲区大小建议为 workers × 2，既能缓冲突发流量，又不至于堆积过多。
- 结合 context.Context 实现超时控制和链路传递。
- 生产环境中接入 Metrics（如 Prometheus）监控队列长度和处理延迟。
五、模式选择决策树
| 模式 | 数据流特征 | 并行度 | 典型场景 |
|---|
|----------------|---------|-------|----------------|
| Fan-Out/Fan-In | 一对多再合一 | 动态 | 批量 API 调用、并行计算 |
| Pipeline | 多阶段顺序流转 | 逐阶段固定 | ETL、中间件链 |
| Worker Pool | 无状态任务队列 | 固定池大小 | 连接池、请求限流 |
选择时需综合考虑：
- 任务之间是否有依赖关系？（有 → Pipeline）
- 是否需要聚合分散的结果？（是 → Fan-Out/Fan-In）
- 是否需要限制并发度？（是 → Worker Pool）
六、常见陷阱与规避
Goroutine 泄漏：任何启动的 Goroutine 必须有明确的退出路径。未关闭 channel 的阻塞等待、无限循环缺少 done 信号是最常见的泄漏源。排查时可使用 runtime.NumGoroutine() 或 pprof 的 goroutine profile。
Channel 误用：向已关闭的 channel 发送数据会 panic，从已关闭的 channel 读取会立即返回零值。始终遵循"谁写入谁关闭"原则，避免跨 Goroutine 关闭同一个 channel。
竞态条件：go test -race 是开发阶段的必备工具，任何涉及共享变量并发读写的代码都应通过竞态检测。对于确实需要共享状态的场景，优先使用 sync.Mutex 或 atomic 包，而不是裸露的 map 操作。
结语
Go 的并发模型简洁但不简单。Fan-Out/Fan-In、Pipeline、Worker Pool 三种模式覆盖了后端开发中绝大多数的并发场景。在实际工程中，这些模式往往组合出现------例如一个 HTTP 服务可能用 Worker Pool 控制请求并发度，用 Pipeline 处理请求生命周期，用 Fan-Out 并行调用多个下游服务。理解每种模式的底层机制和边界条件，才能在高并发场景下游刃有余。