后台任务队列设计:把慢活移出请求

一、请求里塞慢操作,迟早要还的

先看一个典型的"反模式"用户注册接口:

async function register(req) {
  const user = await db.createUser(req.body)
  await sendWelcomeEmail(user)        // 1.2s
  await generateOnboardingReport(user) // 2.5s
  await syncToCRM(user)                // 0.8s
  await pushToAnalytics(user)          // 0.5s
  return user
}

总共 5 秒,看似没崩,实则埋了五颗雷:

• 超时:浏览器默认 30s,移动端网关往往 10s 就掐;5 秒的接口在弱网下基本必挂。
• 阻塞:一个请求占一个连接/线程,慢请求一多,吞吐直接塌方。
• 用户体验差:白屏转圈 5 秒,注册转化率掉一半不夸张。
• 部分失败难回滚:用户建好了,邮件发了,CRM 同步挂了——数据不一致,还无法自动恢复。
• 强耦合:第三方 SMTP 抖一下,整个注册流程就 502。

后台队列的核心思路很简单:请求只做"必须立即返回结果的事"(写库 + 入队),慢活推到后台异步跑。用户 100ms 拿到响应,邮件晚 2 秒到没人关心。

改造后:

async function register(req) {
  const user = await db.createUser(req.body)
  await emailQueue.add('welcome', { userId: user.id })   // 几毫秒
  await reportQueue.add('onboarding', { userId: user.id })
  await crmQueue.add('sync', { userId: user.id })
  return user   // 100ms 返回
}

请求瞬间变轻,业务边界也更清晰。

二、后台队列的核心组件

一张架构图说清:

 ┌──────────┐   enqueue    ┌──────────────┐    pull     ┌──────────────┐
 │ Producer │ ───────────> │   Queue      │ ──────────> │ Worker Pool  │
 │ (业务代码) │              │ (Redis/MQ)   │             │ (后台进程)    │
 └──────────┘              └──────┬───────┘             └──────┬───────┘
                                   │                            │
                            retry with                          │ 执行
                          backoff 重试                           ▼
                                   │                       ┌─────────┐
                                   ▼                       │  任务    │
                            ┌─────────────┐   N 次失败     │ 执行完毕 │
                            │ Retry Buffer│ <──────────── └─────────┘
                            └──────┬──────┘
                                   │ 仍失败
                                   ▼
                            ┌─────────────┐
                            │ Dead Letter │ ── 人工介入
                            │   Queue     │
                            └─────────────┘

         ┌──────────┐
         │ Monitor  │ ──> 积压 / 失败率 / 执行时长 / 吞吐
         └──────────┘

六个组件,逐个拆解:

1. Producer(入队):业务代码把任务序列化(JSON)推入队列,通常带 type、payload、options(优先级/延迟)。这一步必须快——本地走 Redis 通常 1ms 内。
2. Queue(队列后端):存待执行任务。Redis 最常见(轻量、够用),RabbitMQ 提供更强的消息语义(确认、路由),Kafka 适合高吞吐事件流。
3. Worker/Consumer(执行者):常驻后台进程,从队列拉任务执行。生产环境一般跑多实例 + 多并发。
4. Retry(重试):失败自动重试,带指数退避(1s → 2s → 4s → 8s)避免惊群。瞬时故障(网络抖动)大多数能自愈。
5. Dead Letter Queue(死信队列):重试 N 次(比如 5 次)仍失败的任务进死信,等人工排查。没有死信的队列等于把错误吞掉,线上出事查无此案。
6. Monitor(监控):积压数、失败率、执行时长——下面第八节细讲。

三、选型:三大主流,按语言选

几个实战判断:

• Redis 做后端,90% 的场景够用。轻量、普及、运维成本低。只有当你需要复杂路由(topic/fanout)、严格消息确认、跨机房流量控制时,才考虑 RabbitMQ。Kafka 别拿来当任务队列用——它是事件流,语义不对,延迟也高。
• 选你语言生态的,别为队列换语言。BullMQ/Sidekiq/Celery 功能集大同小异,团队能维护的才是好队列。
• 别自己撸。队列看似简单,真正难的是重试、可见性超时(visibility timeout)、死信、并发控制——这些成熟库都踩过坑。

四、任务类型:四种调度模式

后台队列不只是"立刻干",还得会"等会儿干"和"周期性干":

1. 即时任务(immediate):入队即执行。95% 的场景都是这种。
2. 延迟任务(delayed):指定时间后执行。典型用法:注册后 24 小时发提醒邮件、订单 30 分钟未支付自动取消。

   await reminderQueue.add('inactive', { userId }, { delay: 24 * 3600 * 1000 })
   

3. 定时任务(scheduled / cron):周期性重复。每天凌晨生成报表、每分钟同步数据。BullMQ/Celery 都支持 repeat job。
4. 优先级(priority):重要任务插队。VIP 用户邮件优先级 1,普通用户优先级 10,worker 先取小的。

一个常见坑:延迟/定时任务别用 setTimeout 或系统 crontab 凑。setTimeout 进程重启就丢;crontab 没重试、没监控、没幂等保证,任务一多就乱。队列的延迟能力才是工程化方案。

五、幂等:重试安全的命门

这是后台队列最容易被忽略、出事最难查的点。

任务会重试,这是设计使然。但如果你写的执行逻辑不幂等,重试一次就重复一次:

• 邮件重试 → 用户收 5 封欢迎邮件
• 支付重试 → 用户被扣 5 次
• 报表生成重试 → 数据库写 5 条重复记录

幂等的几种实战套路:

1. 唯一键 + 去重:任务带 idempotencyKey,执行前检查是否已处理过(查 Redis/DB)。

   const processed = await redis.set(`email:sent:${key}`, 1, 'NX', 'EX', 86400)
   if (!processed) return // 已经发过了,跳过
   await sendEmail(...)
   

2. 条件更新:用版本号/状态机,确保只在预期状态下推进。

   UPDATE orders SET status='paid' WHERE id=? AND status='pending'
   

   返回影响行数 0,说明已被其他重试改过,直接退出。
3. 外部服务要带幂等头:调 Stripe 用 Idempotency-Key,调自家 API 也建议加。第三方接口不幂等,你自己再做一层去重。

判断标准:任何一个任务,问自己"重试 10 次会出事吗?" 出事就回去加幂等,别等线上炸了再补。

六、worker 并发与限流:别把下游打爆

队列本身不容易挂,真正挂的是下游——数据库、第三方 API、内部服务。

常见事故:为了"快",worker 并发开到 50,结果:

• 数据库连接池打满,整个应用挂
• 第三方 API 触发限流(429),任务全失败
• 下游服务 OOM

几个原则:

• 并发数看下游承受能力,不是看 worker 机器 CPU。DB 连接池 20 个,worker 并发就别超 15。
• 按任务类型分队列:发邮件、跑报表、调外部 API 各走各的队列、各自的 worker。一个慢任务把队列堵了,不会影响别的业务。
• 客户端限流:调第三方 API,本地用 token bucket 限流(比如每秒最多 10 个请求)。
• 超时必须设:每个任务设硬超时(BullMQ 默认 30s),防止 worker 卡死在一个慢调用上,拖垮整个队列吞吐。

七、什么活该异步:三条判断标准

不是所有操作都该进队列——队列也增加复杂度(状态不可见、调试难、运维成本)。判断标准:

1. 慢操作(>200ms):发邮件、生成报表、处理上传文件、视频转码、调第三方 API。
2. 用户不需要立即结果:注册欢迎邮件可以晚 5 秒到,用户不在意;但"搜索结果"就不能异步。
3. 可重试、能自愈:失败后过会儿再试有可能成功(网络抖动、第三方短暂故障)。如果是确定性错误(参数非法),重试也没用,直接报错别浪费 worker。

反例:用户登录校验、支付前余额检查、查询接口——这些绝不该异步,用户在等结果,异步等于功能不可用。

边界判断:如果业务可以接受"几秒后一致",就异步;如果必须"现在就一致",就同步。事务内的关键写操作,别放队列,队列做不到 ACID。

八、监控:队列的体检指标

线上队列跑得好不好,看三个核心指标:

1. 积压(backlog):队列里待处理任务数。突然飙升往往是 worker 挂了、下游慢了、或流量突增。设告警:积压 > 阈值持续 N 分钟,告警。
2. 失败率:失败任务 / 总任务。某个任务类型失败率突然变高,通常是下游出事或代码 bug。死信队列长度也得监控——死信不为 0 就该有人看。
3. 执行时长(p95/p99):任务执行时长分布。p99 突然飙高,说明下游变慢或 worker 卡住。

其他有用的指标:吞吐(每秒处理任务数)、worker 利用率、重试次数分布。

监控不到位,队列就是个黑盒——平时风平浪静,出事就是大事(任务全卡死、积压几小时没人发现)。BullMQ 自带 Bull Board,Sidekiq 有 Web UI,Celery 配 Flower,先把这些面板挂上,再谈别的。

小结

• 请求只做必须立即返回的事,慢活推队列——这是后台队列的全部精髓,把延迟从用户眼前挪走。
• 六大组件缺一不可:入队、队列、worker、重试、死信、监控。少一个就有对应的事故面。
• 选型按语言走:BullMQ/Sidekiq/Celery 任选,Redis 后端 90% 够用,别为队列换语言,别自己撸。
• 幂等是底线:任何任务都得能安全重试——"重试 10 次会出事吗"是必问的代码 review 项。
• 监控三个数:积压、失败率、执行时长。队列不是设了就完事,得有人盯。

金句:请求里塞慢操作,是把延迟甩给用户;用队列,是把延迟留给自己。 优秀的系统不是没有延迟,而是把延迟放到用户感受不到的地方。