Node-Cron导致NodeJS服务繁忙无法响应请求的解决方案

当前实现会导致服务繁忙的核心原因有4点：

• cron表达式* * * * * *为每秒触发1次，执行频率过高，且每次执行都通过无过滤条件的collection.find()拉取集合全量文档到内存，集合数据量稍大就会产生极高的内存占用和IO开销，直接阻塞Node.js事件循环。
• forEach中传入的async回调不会被外层等待，所有文档的处理逻辑会被瞬间推入任务队列，若activity通知方法包含数据库/网络IO操作，会产生无上限的并发请求，直接打满Node.js处理能力，导致其他API请求无法被调度。
• 无任务重入防护：上一轮任务还未执行完成时，下一轮每秒触发的cron任务会直接启动，不断堆积处理任务，最终耗尽服务资源。
• 无业务去重逻辑：符合条件的文档每轮cron执行都会触发一次通知，既浪费资源也会产生重复通知的业务bug。

1. 数据库层优化（核心降本手段） #

• 为查询条件字段创建复合索引：在status、date、通知状态字段上建复合索引，让数据库直接过滤符合条件的文档，避免全表扫描，索引创建为一次性操作，无需每次任务执行：

await collection.createIndex({ status: 1, date: 1, notified: 1 })

• 过滤逻辑下推到数据库：不要拉取全量文档到Node层再判断状态、日期，直接在查询语句中写好过滤条件，同时通过投影只查询业务必需的字段，减少数据传输和内存占用。
• 用游标分批读取：数据量较大时不要一次性加载所有匹配文档到内存，通过MongoDB游标分批拉取，每批处理完再拉下一批。

2. 任务逻辑优化 #

• 调整cron执行频率：业务只需要判断日期是否过期，无需每秒执行，调整为每天凌晨业务低峰期执行即可，比如每天2点执行的cron表达式为0 0 2 * * *，可根据业务精度要求调整到小时级，完全不需要秒级触发。
• 加任务重入锁：设置任务运行标记，上一轮任务未执行完成时，直接跳过本轮触发，避免任务堆积。
• 原子更新防重复通知：处理文档前先通过原子操作给文档打上「通知中」的标记，只有原子更新成功的文档才触发通知，处理完成后标记为「已通知」，从根本上避免重复发送。
• 限流处理：通知发送逻辑控制并发数，不要瞬间发起所有通知请求，避免打满数据库/第三方通知服务的连接。

3. 优化后可直接参考的代码 #

let isTaskRunning = false;
// 每天凌晨2点执行，可根据业务需求调整频率
cron.schedule('0 0 2 * * *', async () => {
  // 上一轮任务没跑完直接跳过
  if (isTaskRunning) return;
  isTaskRunning = true;

  try {
    const today = new Date();
    today.setHours(0, 0, 0, 0);
    const batchSize = 20; // 每批处理20条，可根据服务器配置调整

    // 用游标分批拉取符合条件的文档：状态为Active、日期早于等于今天、未发送过通知
    const cursor = collection.find(
      {
        status: "Active",
        date: { $lte: today },
        notified: { $ne: true }
      },
      { projection: { _id: 1 } } // 只拿需要的_id字段，减少数据传输
    ).batchSize(batchSize);

    // 逐批处理
    for await (const doc of cursor) {
      // 原子更新打标记，防止重复处理
      const updateRes = await collection.updateOne(
        { _id: doc._id, notified: { $ne: true } },
        { $set: { notifying: true } }
      );
      // 没更新到说明已经被其他任务处理过，跳过
      if (updateRes.modifiedCount === 0) continue;

      try {
        // 发送通知
        await activity(doc._id, "Reminder For status", "doc", [], doc._id, null, null, null);
        // 通知发送成功标记为已通知
        await collection.updateOne(
          { _id: doc._id },
          { $set: { notified: true, notifying: false, notifiedAt: new Date() } }
        );
      } catch (notifyErr) {
        // 通知发送失败，重置标记方便下轮重试
        await collection.updateOne(
          { _id: doc._id },
          { $set: { notifying: false } }
        );
        console.error(`send notify failed for doc ${doc._id}`, notifyErr);
      }
    }
  } catch (taskErr) {
    console.error('cron task run failed', taskErr);
  } finally {
    // 任务结束重置标记
    isTaskRunning = false;
  }
});

4. 大流量场景额外优化 #

如果集合文档量达到百万级以上，建议将定时通知任务从处理API请求的主Node服务中拆分出来，单独部署为独立的任务服务，实现资源隔离，就算任务执行占用资源，也不会影响线上正常接口的响应。

内容的提问来源于stack exchange，提问作者Fida Khan