Node.js微服务同步操作优化：避免事件循环阻塞方案咨询

我们有一个由30个Node.js Pod组成的微服务，每秒处理300次请求。今日请求峰值时，DataDog指标显示高延迟与高CPU占用。通过DataDog APM分析发现，asyncFunc1与asyncFunc2函数执行耗时占比达43%（墙钟时间2.43秒）。

原代码中，asyncFunc2的99%请求会命中内存缓存，但因使用await触发了不必要的微任务，在高并发下大量微任务优先于事件循环任务执行，影响性能。我编写了preventMicroTasksInSyncOperations函数，先同步处理所有内存缓存请求，仅对未命中的请求批量调用Redis，以此避免微任务产生。请问该优化方案是否合理？

原代码 #

await asyncFunc1(items);
const asyncFunc1 = async (items: SomeInterface[]) => {
  const response = await Promise.all(
    items.map(async (item) => {
      const response2 = await asyncFunc2(item);
      return response2;
    })
  );

  return response;
};

const asyncFunc2 = async (item: SomeInterface) => {
  const key = item.key;
  const inMemoryData = getInMemoryDataSync(key); // get cached data in memory - 99% data is cached.
  if (inMemoryData) {
    return JSON.parse(inMemoryData);
  }

  const redisData = await redisRepository.getData(key);
  if (redisData) {
    addInMemoryDataSync(redisData); // add cached data in memory
    return JSON.parse(redisData);
  }

  return null;
};

优化后代码 #

const preventMicroTasksInSyncOperations = async (items: SomeInterface[]) => {
  const response = [];
  const keysToFetch = [];

  items.forEach((item) => {
    const key = item.key;
    const inMemoryData = getInMemoryDataSync(key); // get cached data in memory - 99% data is cached.
    if (inMemoryData) {
      response.push(JSON.parse(inMemoryData));
    } else {
      keysToFetch.push(key);
    }
  });

  await Promise.all(
    keysToFetch.map(async (key) => {
      const redisData = await redisRepository.getData(key);
      if (redisData) {
        addInMemoryDataSync(redisData); // add cached data in memory
        response.push(JSON.parse(redisData));
      }
    })
  );

  return response;
};

await preventMicroTasksInSyncOperations(items);

回答 #

这个优化方案非常合理，且针对性极强，完全命中了原代码的性能瓶颈：

原代码的核心问题 #

原代码中，asyncFunc2被定义为异步函数，哪怕99%的场景是直接返回内存缓存的同步结果，只要进入该函数就会生成一个Promise实例；再加上await关键字的使用，会触发大量不必要的微任务调度。在高并发场景下，这些微任务会抢占事件循环的主线程时间，导致其他业务任务被延迟处理，同时CPU会因为频繁的微任务调度和上下文切换而出现高占用。

优化方案的优势 #

1. 彻底消除高命中场景的微任务开销：先通过同步循环批量处理所有内存缓存命中的请求，完全避开了Promise创建和微任务调度的开销，这部分操作的性能开销几乎可以忽略不计。
2. 大幅降低微任务数量：仅对1%缓存未命中的key发起Redis请求，微任务的数量直接降到原有的1%，极大减轻了事件循环的调度压力，能有效缓解高并发下的延迟和CPU占用问题。
3. Redis请求仍保持高效并行：用Promise.all并行处理未命中的Redis请求，没有牺牲IO操作的效率。

可以进一步优化的细节 #

• 结果顺序一致性：原代码中Promise.all会严格按照items的顺序返回结果，但优化后Redis请求的结果是异步push到response中的，可能导致最终结果的顺序与原items不一致。如果业务依赖结果顺序，建议调整实现：比如在第一步时为每个位置预留索引，拿到Redis结果后放到对应位置。
• Redis批量请求优化：如果你的Redis客户端支持批量获取（如mget命令），可以将keysToFetch作为批量参数传入，一次IO操作就能获取所有未命中的数据，比Promise.all并行单个请求的效率更高，还能减少网络开销。

内容的提问来源于stack exchange，提问作者Daniel Cohen