BullMQ Worker

分离执行，各自专注

Worker 是一个执行者。它不接受用户请求，不返回即时响应，只是默默地处理任务。

在 BullMQ 的架构中，任务的添加和执行是分离的。你向队列中添加任务，然后就可以离开。Worker 会在稍后的某个时刻取出任务，执行它，记录结果。

这种分离带来的最直接好处是：你不必等待。

发送邮件、处理图片、生成报表，这些操作可能需要几秒甚至几分钟。如果用户发起请求后必须等待这些操作完成，体验会很糟糕。但如果你把这些操作交给 Worker，用户可以立即得到反馈，然后继续做其他事情。

时间的重新分配

同步执行意味着：你必须现在做，我必须等你做完。

异步执行意味着：我不需要你现在做，你也不需要现在就做完。

这是对时间的重新分配。

用户的时间是宝贵的。他们不应该为系统的耗时操作买单。当用户点击"生成报表"，他们期待的不是漫长的等待，而是一个确认："我已经收到你的请求，会尽快处理。"

服务器的时间也需要合理分配。接受请求的服务器应该快速响应，而不是被耗时操作堵塞。如果一个请求需要处理 30 秒，而服务器同时只能处理 10 个连接，那么第 11 个用户会等待很久。

Worker 的存在，让这两种时间得以解耦。

用户不必等待任务完成，服务器不必被任务堵塞。任务在队列中等待，Worker 在后台慢慢处理。每个角色都专注于自己擅长的事情。

独立性带来的稳定

Worker 是独立的进程。它不依赖于 API 服务器，也不共享内存或状态。

这种独立性很重要。

如果 API 服务器崩溃，Worker 可以继续运行。如果 Worker 出错，API 服务器不受影响。任务在队列中是持久化的，即使整个系统重启，任务也不会丢失。

更重要的是，Worker 可以扩展。

你可以运行一个 Worker，也可以运行十个。当任务积压时，增加 Worker 数量；当任务减少时，缩减 Worker。这种弹性扩展不需要改动代码，只需要启动更多进程。

const worker = new Worker('queueName', async (job) => {
  // 处理任务
}, {
  concurrency: 5  // 同时处理 5 个任务
});

失败是预期的一部分

Worker 处理的任务可能失败。

网络超时、外部 API 不可用、数据格式错误，失败的原因有很多。在同步执行中，失败意味着用户看到错误。在异步执行中，失败不应该直接暴露给用户。

BullMQ 提供了重试机制。任务失败后，可以自动重试。你可以配置重试次数、重试延迟、重试策略。

await queue.add('send-email', { to: 'user@example.com' }, {
  attempts: 3,  // 最多重试 3 次
  backoff: {
    type: 'exponential',  // 指数退避
    delay: 1000  // 初始延迟 1 秒
  }
});

这不是为了掩盖问题，而是为了应对暂时性的失败。网络抖动、服务重启、资源暂时不可用，这些都是可以恢复的。通过重试，系统可以自愈。

但重试也有边界。如果任务连续失败多次，可能是代码有 bug，或者数据本身有问题。这时应该停止重试，记录错误，转入人工处理。

Worker 的设计假设失败是常态，而不是异常。

优先级与顺序

不是所有任务都同等重要。

发送密码重置邮件应该比发送营销邮件优先。生成用户报表应该比统计分析优先。关键业务操作应该比日志归档优先。

BullMQ 支持优先级队列。你可以为任务设置优先级，高优先级的任务会先被处理。

await queue.add('critical-task', data, { priority: 1 });
await queue.add('normal-task', data, { priority: 5 });
await queue.add('low-priority', data, { priority: 10 });

数字越小，优先级越高。

这让你可以在资源有限时，先处理最重要的事情。

但优先级也有代价。低优先级的任务可能被长期延迟，甚至"饿死"。你需要权衡：是严格按优先级处理，还是给低优先级任务保底的执行机会？

这没有标准答案。取决于你的业务场景和容忍度。

监控与可见性

Worker 在后台运行，看不见也摸不着。

这带来一个问题：你怎么知道它在正常工作？

任务堆积了吗？Worker 挂了吗？处理速度够快吗？错误率多高？

没有可见性的系统是不可控的。

BullMQ 提供了丰富的事件机制。你可以监听任务的生命周期：入队、开始、进度、完成、失败。基于这些事件，你可以构建监控系统。

worker.on('completed', (job) => {
  console.log(`任务 ${job.id} 完成`);
});

worker.on('failed', (job, err) => {
  console.error(`任务 ${job.id} 失败:`, err);
});

worker.on('progress', (job, progress) => {
  console.log(`任务 ${job.id} 进度: ${progress}%`);
});

更进一步，你可以集成 Prometheus、Grafana 等监控工具，实时追踪队列长度、处理速度、错误率、平均延迟。

当队列积压时，你会收到告警。当 Worker 崩溃时，你会知道。当处理速度下降时，你可以调查原因。

可见性是控制的前提。

const worker = new Worker('queueName', processor, {
  maxJobsPerWorker: 1000  // 处理 1000 个任务后重启
});

不是银弹

Worker 解决了很多问题，但也带来了复杂性。

你需要管理额外的进程。你需要处理任务的序列化和反序列化。你需要设计重试策略。你需要监控队列状态。

更重要的是，异步处理意味着延迟。用户提交任务后，不能立即看到结果。他们需要等待，或者通过其他方式（如通知、轮询）获知任务状态。

这种延迟在某些场景下是可接受的，甚至是必要的。但在另一些场景下，用户需要即时反馈。

不要为了使用 Worker 而使用 Worker。

如果一个操作足够快（比如几十毫秒），直接同步执行可能更简单。如果用户必须等待结果才能继续，异步处理反而增加了复杂度。

Worker 的价值在于：当同步执行不可行时，它提供了一种优雅的替代方案。

专注带来的力量

Worker 的设计哲学可以总结为：分离、专注、独立。

分离意味着不同的职责由不同的组件承担。API 服务器负责快速响应，Worker 负责耗时处理。

专注意味着每个组件只做自己擅长的事。API 服务器不被任务堵塞，Worker 不关心用户交互。

独立意味着组件之间松耦合。一个崩溃不影响另一个，一个扩展不需要改动另一个。

这种架构不是为了炫技，而是为了应对现实的复杂性。

系统会变得越来越复杂。功能会越来越多，流量会越来越大，需求会越来越多样化。如果所有逻辑都挤在一起，最终会不堪重负。

分离是为了可持续。专注是为了可靠。独立是为了灵活。

在一个充满变化的世界里，能够让每个部分各司其职，本身就是一种稳定。

参考资源

相关阅读

• 队列、可靠性与系统边界 - 理解队列系统的权衡与设计选择
• BullMQ 队列 - 理解任务的来源与顺序管理
• 错误隔离 - 如何防止失败蔓延