node.js多worker进程下定时器独立运行，每个进程拥有自己的事件循环，导致重复执行；解决方法包括主进程调度、worker自检或redis分布式锁；定时器精度仍受单线程阻塞影响，推荐settimeout链式调用。
Node.js 中的定时器在多 Worker 进程（注意：不是 Worker Threads）环境下行为会发生显著变化，核心差异在于“每个进程独立维护自己的事件循环”，而非共享状态。理解这一点，是避免并发重复、时间漂移和资源竞争的关键。
每个 Worker 进程都有一套独立的定时器
当使用 Cluster 模块启动多个 Worker 进程时（例如 worker.count = 4），setInterval 或 Timer::add 在每个进程中都会被单独执行一次。这意味着：
- 如果在
onWorkerStart中写setInterval(() => console.log('tick'), 5000)，4 个进程会各自每 5 秒打印一次——总共每 5 秒输出 4 行，而非预期的 1 行； - 若该定时任务是发邮件、写数据库或清理缓存，就可能造成重复执行、数据冲突或资源浪费；
- 这种“天然并行”不等于“业务并行安全”，需主动控制执行范围。
如何确保仅一个 Worker 执行定时任务
常见且可靠的方案有两类：
-
主进程统一调度 + IPC 转发：由 Master 进程创建定时器，通过
worker.send()向指定 Worker（如workers[0]）发送指令，再由该 Worker 执行具体逻辑； -
Worker 自检 + 进程 ID 判断：在
onWorkerStart中判断process.pid % N === 0或使用process.env.NODE_WORKER_ID（需配合自定义启动逻辑），只让特定编号的 Worker 启动定时器； -
借助外部协调服务：如 Redis 分布式锁（
SET lock:job NX EX 30），各 Worker 尝试获取锁，成功者执行，失败者跳过——适合高可用、跨机器部署场景。
定时器精度受事件循环阻塞影响，多 Worker 并不能缓解
即使开了多个 Worker，单个 Worker 内部仍是单线程事件循环。以下情况仍会导致定时器不准：
- 同步 CPU 密集操作（如大数组排序、正则回溯）阻塞主线程，后续定时回调排队等待；
- 未及时
clearTimeout/clearInterval导致残留定时器累积内存与执行负担； - 使用
setInterval且回调执行时间 > 间隔周期，将引发“任务堆积”或跳过执行（取决于实现）； - 建议改用
setTimeout链式调用：每次任务结束再设下一次，可显式控制节奏并捕获异常。
Worker Threads 中的定时器行为完全不同
注意区分：Cluster 的 Worker 是进程，Worker Threads 的 Worker 是线程。在 Worker Thread 内部使用 setTimeout：
- 它运行在独立的 V8 实例和事件循环中，不影响主线程定时器；
- 但线程内仍遵循单线程规则——一个耗时同步操作同样会拖慢其内部定时器；
- 线程间无法直接共享定时器对象，也不应跨线程传递
setTimeout返回的 ID； - 如需协同调度，必须通过
parentPort.postMessage()和消息机制协调，而非共享定时器实例。
