在多个Node.js进程协同处理后台任务的场景中，不同业务对时效的要求截然不同。支付对账必须在秒级完成，而报表生成容忍分钟级延迟。如果调度层不区分优先级，所有任务按到达顺序消费，高优任务就会被低优任务堵在队列里。本文围绕如何用Node.js搭建支持优先级的分布式任务调度展开，从原理到代码逐一说明。
一、优先级调度的核心原理
分布式任务调度的本质是把“谁来执行”和“何时执行”从业务代码里剥离出来。优先级调度的关键点在于，调度中心在分发任务时，不能只看谁先来，而要看任务携带的优先级权重。常见做法是给每个任务打一个数值标签，数值越小表示越紧急，或者反过来用越大越优先，全看约定。
在单进程里，我们可以用堆结构维护优先级队列，父节点永远比子节点更优先，插入和弹出都是对数复杂度。但到了分布式环境，堆不能跨进程共享，必须依赖外部存储。Redis的ZSet用跳表实现有序集合，分数就是优先级，多台Node.js worker通过同一条ZSet争抢分数最低的成员，天然适合做分布式优先队列。
1.1 为什么不能直接用List做队列
Redis的List结构提供LPUSH和RPOP，是简单的FIFO队列。它没有分数概念，后push的任务只能等前面的消费完。如果想插队，只能另建一个高优List，worker先扫高优再扫低优。这种多队列方案在优先级层级变多后会迅速膨胀，且难以动态调权。
相比之下，ZSet把优先级和任务数据绑定在同一条记录上，ZADD时指定score即可。消费端用ZPOPMIN原子地取出最小score的任务，避免多worker抢同一任务的竞态。下面用一段Node.js代码展示基础写入。
const Redis = require('redis');
const redis = Redis.createClient();
// 高优任务score小，低优任务score大
async function addTask(taskId, payload, priority) {
await redis.zAdd('task_queue', {
score: priority,
value: JSON.stringify({ taskId, payload })
});
}
// 优先级数值：1紧急 5普通 10极低
addTask('order_sync', { orderId: 1001 }, 1);
addTask('report_gen', { date: '2024-01-01' }, 10);
二、基于BullMQ的优先级实践
BullMQ是Node.js生态里成熟的Redis-backed队列库，原生支持优先级字段。它在ZSet之外又用Stream和Lua脚本封装了延迟、重试、占用等逻辑，比手搓ZSet更稳。创建队列时不需要特殊配置，只在添加任务时传priority即可。
需要注意的是，BullMQ的priority数值是越小越优先，默认值为0。如果大量任务都用0，就等于退回了无序竞争。建议业务层做枚举映射，把紧急、普通、低速分别映射到1、5、9，留足中间空间方便以后插新等级。
2.1 Worker端消费代码
Worker进程连接同一个Redis，调用process方法处理任务。BullMQ保证高priority的任务先被nextJob取走。即使低优任务先到，只要高优任务进来，worker空闲时会优先拿高优。
const { Queue, Worker } = require('bullmq');
const connection = { host: '127.0.0.1', port: 6379 };
const queue = new Queue('tasks', { connection });
async function enqueue() {
await queue.add('send_sms', { phone: '13800000000' }, { priority: 1 });
await queue.add('build_stat', { type: 'daily' }, { priority: 9 });
}
new Worker('tasks', async job => {
if (job.name === 'send_sms') {
// 模拟紧急短信
console.log('send sms', job.data);
} else {
console.log('build stat', job.data);
}
}, { connection });
2.2 防止低优任务饿死
如果高优任务持续涌入，低优任务可能永远排不上。工程上常用老化策略：任务在队列里停留超过一定时间，就逐步调高它的优先级。BullMQ没有内建老化，可以用定时脚本扫描ZSet里score大且时间戳老的任务，用ZADD更新score。
另一种思路是worker按比例预留消费额度，比如每消费十个高优，强制取一个低优。这在代码里就是维护一个计数器，到达阈值时主动调低本次获取的优先级上限。两种方案各有取舍，脚本扫描对Redis压力小，计数器法则更实时。
三、多节点下的状态与容错
分布式系统必然有节点崩溃。如果某worker用BullMQ的默认设置，任务被move到active状态后节点宕机，这个任务会卡在active直到锁过期。BullMQ依靠Redis的锁超时自动释放，但期间高优任务可能延迟数十秒。
更稳妥的做法是开启stalledInterval监控，并设置合理的lockDuration。同时把任务结果和优先级快照写进数据库，便于人工补跑。下表对比两种存储后端的差异。
| 方案 | 优先级实现 | 多节点一致性 | 运维成本 |
|---|---|---|---|
| Redis ZSet手搓 | score字段 | 强一致依赖单Redis | 高，需自写容错 |
| BullMQ | priority参数 | Lua脚本保证原子 | 低，社区成熟 |
3.1 节点扩容时的注意事项
水平扩展Node.js worker非常简单，只要新进程连同一个Redis和队列名。但要留意Redis本身的带宽，当worker超过五十个且任务极小，ZPOPMIN的调用频率会压垮单实例。此时应引入Redis集群，按队列名做hash slot拆分，或者把不同优先级放到不同物理队列减少争用。
另外，Node.js是单线程事件循环，如果任务处理函数里有重度CPU计算，会阻塞整个worker。优先级再高，worker不腾出手也白搭。建议把CPU密集部分丢到子进程或单独的服务，主worker只做调度和轻量IO。
四、完整可运行示例
下面给出一个最小但完整的调度demo，包含生产者和两个优先级不同的消费者逻辑。你可以直接复制到本地，起两个终端分别跑worker和producer观察输出顺序。
// producer.js
const { Queue } = require('bullmq');
const connection = { host: '127.0.0.1', port: 6379 };
const q = new Queue('demo', { connection });
(async () => {
await q.add('low', { msg: 'low task' }, { priority: 10 });
await q.add('high', { msg: 'high task' }, { priority: 1 });
await q.add('mid', { msg: 'mid task' }, { priority: 5 });
process.exit(0);
})();
// worker.js
const { Worker } = require('bullmq');
const connection = { host: '127.0.0.1', port: 6379 };
new Worker('demo', async job => {
console.log('handle', job.name, job.data, 'at', Date.now());
}, { connection });
运行后会发现，无论producer按什么顺序add，worker总是先打印high再mid最后low。这就是优先级调度在分布式Node.js里最直接的效果。实际项目里，你只需把job.data换成真实业务参数，并在process函数里调用对应服务。
五、总结与落地建议
用Node.js做分布式任务调度并支持优先级，核心就是选对有序存储和抢占机制。小团队直接用BullMQ省心，大流量再做集群拆分。务必给优先级留中间值，并设计防饿死策略。任务处理保持轻量，重计算外移，才能让高优任务真正快起来。
当业务从单机定时脚本长到多服务异步化，优先级调度几乎是必经之路。照着上面的代码骨架，半天内就能跑起一个可观测、可扩容的调度节点，后续再补监控和告警即可。
Node.js分布式任务调度task_priority修改时间：2026-08-10 06:45:37