Go worker pool 如何处理突发任务：队列背压、拒绝策略和优雅停机

消息高峰时，Go 服务里很容易写出一种看似好用的处理逻辑：收到任务就起一个 goroutine 跑。低流量下基本不会出问题，真正的坑都藏在队列突然积压的场景里——内存一路暴涨，任务完成耗时越来越久，到最后连健康检查的调度机会都抢不到。worker pool 的核心价值根本不是“少创建几个 goroutine”，而是把任务并发数、排队长度和停机流程都变成可控的可量化资源。

无界提交为什么会把突发流量放大

假设订单服务平时每秒处理80个任务，某一时刻上游突然推来2000个任务。如果每个任务进来直接开goroutine跑，服务表面上“接住”了所有请求，但实际处理能力完全没有提升。相当于任务只是从上游的队列里，直接搬迁到了本机的堆内存里。

更麻烦的是，这些任务后续还会持续占用数据库连接、文件句柄或者下游接口配额。于是内存、连接占用、处理耗时一起飙升，最后演变成大面积超时。遇到这种情况别上来就说Go并发性能不够，绝大多数场景都是没给排队逻辑设置上限导致的。

先确定三个核心数值：worker数、队列长度和任务超时时间

worker pool 至少要有三个可落地的配置参数。worker 数量决定了服务的稳定处理速度；队列长度决定最多允许多少任务排队等待；单任务超时规则决定异常任务什么时候主动让出占用的资源。

这些数值可以从现有运行指标反推计算。比如单个任务平均耗时40ms，要达到每秒处理200个任务的稳定目标，理论上8个worker就足够；如果任务耗时的p99值能到300ms，就要给流量波动留出冗余空间，最终数值要经过压测确认，不能图省事直接给队列设一个极大的数值。

最小实现：固定worker搭配有限队列

下面这段代码把worker数量固定为8，队列最多只保留64个待处理任务。提交任务的时候如果队列拿不到位置就直接返回错误，调用方可以根据业务场景选择重试、降级，或者把任务交回上游消息系统暂存。

package pool

import (
    "context"
    "errors"
    "sync"
)

var ErrBusy = errors.New("worker pool is full")

type Job func(context.Context)

type Pool struct {
    ctx    context.Context
    cancel context.CancelFunc
    jobs   chan Job
    wg     sync.WaitGroup
}

func New(size, queue int) *Pool {
    ctx, cancel := context.WithCancel(context.Background())
    p := &Pool{ctx: ctx, cancel: cancel, jobs: make(chan Job, queue)}
    p.wg.Add(size)
    for i := 0; i 

这里的 default 就是拒绝策略的核心：队列满的时候不会阻塞住提交请求的流程。如果业务要求任务必须入队，可以把它改成带context的等待逻辑，但一定要给等待本身设置超时时间，不然背压又会演变成新的无界等待。

生产级实现要先停止提交，再等待任务跑完

上面的最小实现只适合演示基础结构，生产环境的版本要处理两个边界场景：关闭pool的逻辑不能和提交任务的逻辑并发操作同一个channel；任务的执行时间不能无限延长。一般会由服务的生命周期统一管理“停止接收新任务”的状态，再等已提交的任务全部执行完成。

type SafePool struct {
    mu     sync.RWMutex
    closed bool
    jobs   chan Job
    wg     sync.WaitGroup
}

func (p *SafePool) Submit(job Job) error {
    p.mu.RLock()
    defer p.mu.RUnlock()
    if p.closed {
        return errors.New("pool is closed")
    }
    select {
    case p.jobs 

更完善的实现还会让worker从携带取消信号的任务上下文里读取外部资源状态，在服务关闭的时候设置一个最大等待时长。超过这个时长之后，还没跑完的任务要交给支持持久化的外部队列存储，或者明确记录失败状态，不能直接默默丢弃。

等待、拒绝和降级三种策略，该怎么选

这三种策略没有绝对的好坏，核心判断标准是当前任务是否允许延迟处理。

• 等待入队：适合短时间的流量波峰场景，提交请求本身允许排队等待，等待逻辑必须配置context超时兜底。
• 立即拒绝：适合HTTP在线请求场景，快速返回429或者业务忙提示，避免单个慢请求拖垮整个服务。
• 降级处理：适合通知、统计类非核心任务，可以优先丢弃低优先级任务，但要做好计数，明确记录丢弃原因。

如果任务来自Kafka、RabbitMQ这类外部消息系统，内存队列满的时候不要直接丢任务，而是让消费端暂停或者降低拉取速度。内存队列只适合做短时间的流量缓冲，不能替代可靠消息存储。

上线后要重点观察的核心指标

至少要采集四组运行指标：当前队列长度、任务等待耗时、ErrBusy触发次数和worker实际执行耗时，再补充一个关闭流程的耗时指标，就能很方便的区分是“任务本身处理慢”还是“停机时任务没有正常退出”的问题。

压测的时候可以固定8个worker，逐步把输入流量从每秒80提升到400，观察队列长度是否能稳定回落。如果队列长度只涨不跌，说明当前输入速率已经远超处理能力，这时候应该调整上游请求速率或者优化业务逻辑，而不是简单把队列长度改成10万。

常见问题：worker pool的边界逻辑怎么判断

worker数量越大，吞吐就一定越高吗？

不一定。CPU密集型任务的吞吐会受机器核数限制，I/O密集型任务的吞吐会受数据库或者下游接口的连接数限制；worker开太多反而会增加调度竞争，拉高请求的尾延迟。

队列满了直接丢任务可行吗？

只有业务规则明确允许丢弃任务的场景下才可以这么做。重要任务应该返回忙提示、暂停消费或者转存到可靠的外部队列，同时记录好对应的任务ID方便回溯。

关闭pool的时候为什么不能先调用cancel再关闭jobs队列？

cancel操作只会影响正在执行的任务是否继续运行，不会自动拦住后续的新提交请求。正确顺序是先阻止新的任务提交，再关闭队列等待worker处理完存量任务，最后处理剩余任务和超时逻辑。

用一个全局worker pool处理所有类型的任务好吗？

不建议把不同优先级、不同资源依赖的任务混在一起调度。订单、通知、报表这类不同场景的任务最好拆分独立的容量配置，避免低优先级任务挤占核心业务的队列资源。

落地检查清单

一个可长期维护的Go worker pool，应该能明确回答四个问题：最多同时处理多少任务、最多允许多少任务排队等待、满载的时候怎么向外反馈、关闭流程里哪些任务会被执行完成或者转移。把这四点固化到配置和监控体系里，遇到突发流量的时候就不会变成一场靠运气的goroutine数量竞赛。