分布式任务调度系统上线后，任务的执行时间往往不再完全可控。Node.js应用习惯用异步回调或Promise来驱动任务，但当一个任务调用了没有超时参数的第三方客户端，或者陷入了复杂计算，Worker进程不会自动感知异常。调度节点只能一直等待结果，消费速率下降，队列越积越多。要解决这个问题，必须从任务状态、超时检测、强制终止和补偿恢复几个层面一起设计，而不是简单地给任务函数套一个定时器。
任务执行超时为什么不能只靠Promise.race
很多团队的第一反应是给任务函数包一层Promise.race，一旦超时就返回失败。这个做法能解决调用侧的超时感知，但无法终止底层任务。以下代码看起来合理：
function withTimeout(task, ms) {
return Promise.race([
task(),
new Promise((resolve, reject) => {
setTimeout(() => reject(new Error('任务执行超时')), ms);
})
]);
}
问题在于，当超时发生时，task()内部可能还在继续执行。比如一个文件下载或数据库查询，计时器已经触发reject，但底层socket仍然占用连接，数据库游标也没有关闭。更麻烦的是，在分布式调度中，调度节点可能已经把任务重新投递给了另一个Worker，而原Worker迟迟没有退出，最终同一个任务被跑了两次。如果任务不是幂等的，就会产生数据错误。
要想真正中断任务，需要分场景处理。对于支持取消的API，可以配合AbortController把取消信号传进去；对于同步CPU密集计算，可以考虑用worker_threads把任务隔离到子线程，超时后直接terminate线程。但分布式调度的难点在于，任务可能运行在不同进程甚至不同机器上，内存级的取消只能解决本地问题，全局状态还是要靠第三方存储来协调。
所以合理的超时控制会分为三层：执行节点负责本地超时与强制中断，调度节点负责全局超时检测与重新投递，存储层记录任务状态以保证幂等。下面的内容会围绕这个分层思路展开。
基于Redis实现全局超时检测
在Node.js分布式调度中，Redis经常被用来做队列和状态存储。如果暂时不想引入重量级队列框架，可以利用Redis的Sorted Set维护任务的到期时间。Sorted Set的成员是任务ID，分数是任务的deadline时间戳，后台定时器周期性扫描小于当前时间的成员，就能找出超时任务。
const redis = require('ioredis');
const client = new redis();
async function addTaskWithDeadline(taskId, deadline) {
// deadline 为毫秒时间戳
await client.zadd('task:deadlines', deadline, taskId);
}
async function scanExpiredTasks(now) {
const expired = await client.zrangebyscore('task:deadlines', '-inf', now, 'LIMIT', 0, 100);
if (expired.length > 0) {
for (const taskId of expired) {
await client.zrem('task:deadlines', taskId);
// 这里可以将 taskId 标记为超时，并触发补偿流程
}
}
return expired;
}
这种做法实现简单，但扫描存在延迟，任务超时后不会立刻被发现。如果任务量很大，频繁扫描会消耗Redis资源，频率太低又会影响检测时效。另一种思路是开启Redis的键过期通知，在任务开始时设置一个带TTL的key，到期后Redis会发布事件。不过这个通知机制并不可靠，订阅端断线或Redis重启都可能丢失事件，所以最好把通知和扫描结合起来使用。
全局超时检测只能发现哪些任务已经超过预期时间，它不能直接阻止执行节点继续跑。因此还要在执行节点上配置本地超时，形成双保险。比如任务开始执行前写入一个带过期时间的锁，其他节点看到锁已经消失就知道任务可能超时。但要注意，锁过期自动释放后，如果原任务还没结束，就可能出现两个节点同时处理同一个任务。解决这个问题需要给锁续期，也就是在执行过程中周期性延长锁的过期时间。
在Node.js中实现锁续期并不复杂。拿到锁之后启动一个setInterval，每隔一段时间检查任务是否仍在执行，如果还在就用expire延长锁的时间。任务结束后无论成功失败都要清理定时器并释放锁。用Redis的set命令配合NX和EX参数可以保证加锁的原子性，下一节会在BullMQ的Worker里体现类似思路。
使用BullMQ控制Worker执行超时
BullMQ是Node.js生态里比较成熟的分布式队列库，底层依赖Redis，支持任务重试、优先级、并发控制和延迟任务。创建Worker时可以直接设置超时参数，让任务超过指定时间后自动标记为失败。下面的示例启动了一个报表处理Worker，并发数为5，任务处理超过10秒就被判为失败。
const { Queue, Worker } = require('bullmq');
const queue = new Queue('report', { connection: { host: '127.0.0.1', port: 6379 } });
const worker = new Worker('report', async (job) => {
// 模拟一个可能超时的任务
const result = await fetchRemoteReport(job.data.reportId);
return result;
}, {
connection: { host: '127.0.0.1', port: 6379 },
concurrency: 5,
lockDuration: 30000,
stalledInterval: 30000,
maxStalledCount: 2,
timeout: 10 * 1000
});
这里需要区分一个关键点：BullMQ设置timeout后，超过处理时间会把任务标记为失败，并触发失败事件，但它不会自动中止正在执行的函数。换句话说，它和Promise.race类似，只是让队列系统知道该任务失败了，函数本身还在后台继续运行。如果处理函数内部有网络请求或者数据库操作，这些资源仍然被占用。
要达到真正的超时中断，应该结合AbortController。Node.js 17.3之后还提供了AbortSignal.timeout静态方法，可以更方便地生成超时信号。下面是一个改进后的Worker，在任务开始时创建超时控制器，把signal传给支持取消的fetch，超时后请求会被真正中断。
const { Worker } = require('bullmq');
const worker = new Worker('report', async (job) => {
const timeoutMs = 10000;
const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), timeoutMs);
try {
const response = await fetch('https://api.ipipp.com/report/' + job.data.reportId, {
signal: controller.signal
});
return await response.json();
} finally {
clearTimeout(timer);
}
}, {
connection: { host: '127.0.0.1', port: 6379 },
concurrency: 5,
timeout: timeoutMs + 2000
});
这个示例中，BullMQ的timeout设置得比本地中断时间稍长，是为了给本地中断逻辑一点缓冲。当fetch收到abort信号后，请求会立即取消，资源也会被释放。如果处理函数里还有数据库操作，可以选用支持signal的驱动，或者把数据库操作拆分成可取消的小步骤。对于纯计算任务，更推荐放到worker_threads中，超时后直接终止线程。
超时发生后，BullMQ会根据配置把任务放入失败队列或直接重试。我们需要监听失败事件，记录日志并触发告警。至少要知道哪个任务超时了、原因是什么、当前重试次数是多少，否则后续排查会无从下手。
超时后的补偿与重试策略
超时控制不等于把任务简单标记为失败，更重要的是恢复系统一致性。如果任务已经在远端执行成功，只是响应超时，直接重试可能导致重复扣款或重复写入。因此任务处理函数必须做幂等设计。一个常见的做法是在任务开始时生成唯一执行ID，并利用数据库唯一约束拒绝重复插入。
async function executeWithIdempotency(taskId, handler) {
const redis = require('ioredis');
const client = new redis();
const lock = await client.set('lock:' + taskId, '1', 'NX', 'EX', 30);
if (!lock) {
throw new Error('任务已由其他节点处理');
}
try {
await handler();
} finally {
await client.del('lock:' + taskId);
}
}
这段代码用Redis的原子锁防止同一个任务被重复处理，但锁的过期时间需要根据任务最长执行时间来设置。如果任务偶尔会超过30秒，就要加入续期机制，否则锁提前释放后，新节点会再次获取锁并执行，原来的节点还在跑，还是会重复。更稳妥的做法是把锁改为任务状态表，任务开始时写入processing状态，处理完成后改为done，超时后由调度节点把状态重置为pending，同时检查是否已经有成功记录。
重试策略也需要谨慎设置。固定间隔重试可能在第三方服务抖动时造成瞬时洪峰，指数退避则能留出恢复时间。BullMQ的backoff参数可以配置为指数退避，结合最大重试次数，避免无限重试耗尽资源。对于无法幂等的关键操作，超时后最好不要自动重试，而是转入人工介入队列，由人工确认后再重放。
const worker = new Worker('report', async (job) => {
// 任务处理逻辑
}, {
connection: { host: '127.0.0.1', port: 6379 },
attempts: 3,
backoff: {
type: 'exponential',
delay: 5000
}
});
最后，超时控制的有效性要依靠监控来验证。需要关注的指标包括任务超时率、平均执行时长、队列深度和滞留在处理状态的任务数量。可以用process.hrtime.bigint()测量每个任务的执行耗时，把这些数据写入日志或Prometheus，当超时率突然升高时就能快速定位是外部依赖变慢还是Worker本身达到了瓶颈。分布式任务调度没有银弹，只有把超时检测、资源释放、幂等重试和监控告警串起来，才能降低任务卡死带来的雪崩风险。