引言

在高并发后端系统的开发中，并发模型的选型直接影响系统的吞吐量与可维护性。Go 语言凭借 Goroutine 和 Channel 两大原语，将并发编程的复杂度大幅降低。然而，真正发挥其威力需要理解几种核心并发模式。本文将从实际工程场景出发，梳理 Fan-Out/Fan-In、Pipeline 和 Worker Pool 三种模式的适用边界与实现要点。

一、Goroutine 与 Channel：并发编程的基石

Goroutine 是 Go 运行时管理的轻量级线程，初始栈大小仅 2KB，创建和切换成本远低于操作系统线程。一个典型的 Go 服务在运行期间可以轻松持有数十万个 Goroutine。

Channel 则是 Goroutine 之间的通信管道，遵循 CSP（Communicating Sequential Processes）模型，通过"不要通过共享内存来通信，而要通过通信来共享内存"这一设计哲学，从根本上避免了传统多线程编程中的数据竞争问题。

// 有缓冲 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 将多路结果汇聚为单路输出。

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 数据管道、请求中间件链、编译流水线。

// 阶段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 请求并发控制、任务调度器。

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	无状态任务队列	固定池大小	连接池、请求限流

选择时需综合考虑：

1. 任务之间是否有依赖关系？（有 → Pipeline）
2. 是否需要聚合分散的结果？（是 → Fan-Out/Fan-In）
3. 是否需要限制并发度？（是 → 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 并行调用多个下游服务。理解每种模式的底层机制和边界条件，才能在高并发场景下游刃有余。