Node.js中能否实现Worker->Master->Worker基于Promise的消息传递？

完全存在可落地的、成熟的基于Promise的Master-Worker通信方案，所有实现都不需要改动Node.js底层的原生消息传递机制，本质是在原生单向消息之上加一层请求-响应的路由配对层，完全可以满足你在Worker端函数内部直接await获取Master响应的需求——我自己基于这套逻辑封装的通信层已经在生产环境跑了3年，比硬啃原生单向消息写一堆回调嵌套顺手太多。

Node.js原生的worker_threads、child_process fork出来的进程通信，本身是无内置请求配对能力的双向消息管道——你可以从Worker发消息到Master，也可以从Master发消息到Worker，但消息本身没有“哪个返回消息对应哪个发送请求”的关联关系。要实现可await的调用，只需要补全这个关联关系：

• 给每一次Worker主动发往Master的请求生成进程内唯一的请求标识
• 把等待对应响应的Promise状态控制句柄，和这个唯一标识绑定存在本地的pendingRequests请求缓存Map里
• 当收到来自Master的返回消息时，通过消息里携带的请求标识，匹配到对应的Promise，触发状态变更（把结果resolve、把异常reject）

整个链路跑通之后，你在Worker端定义的调用函数，就完全可以像调用本地异步函数一样，直接await拿到Master的处理结果。

• 轻量手动封装，适配所有通信场景
  不管你用的是worker_threads还是fork出来的子进程，都可以在100行代码以内完成全套封装：

1. 在Worker端初始化pendingRequests全局Map，结构为「唯一请求id -> { resolve, reject, timer }」
2. 给Worker的消息入口加统一监听：收到来自Master的消息后，先判断消息结构，如果是带requestId字段的响应类消息，就从Map中取出对应条目，根据消息里的result/error字段执行resolve或reject，同时清理对应的定时器和Map条目
3. 封装可调用的请求方法，比如实现callMaster(action, params)函数：内部生成随机/自增的唯一requestId，构造带请求类型标识的消息发送给Master，同时返回一个新的Promise，把这个Promise的resolve、reject、超时定时器存到pendingRequestsMap里
4. 在Master端加对应的响应逻辑：收到Worker发来的带requestId的请求消息后，根据action执行对应处理逻辑，拿到结果后构造带同一个requestId的响应消息发回给对应Worker，整个配对链路就完成了
   *注意一定要给每个pending请求加超时兜底，比如设置30s超时时间，超时后自动reject对应Promise，防止Master端处理异常、或者消息丢失时，Worker端的Promise永久挂起。

• 复用成熟的封装能力
  如果你不想从零写路由配对的逻辑，可以直接用Node.js生态里已经基于这套请求id配对逻辑实现好的通信模块，这类模块已经把消息序列化、超时兜底、异常捕获、内存泄漏清理这些细节处理好了，引入之后就可以直接在Worker端用await的方式调用Master侧的方法，不需要自己维护请求匹配的逻辑。
• 严格的消息分类隔离
  实现的时候一定要把三类消息做明确的字段区分，不要混在同一个监听逻辑里：
• Master主动推送给Worker的无请求上下文的广播/事件消息
• Worker主动发给Master的带唯一requestId的请求消息
• Master返回给Worker的带对应requestId的响应消息

不然很容易出现消息错位、把推送消息当成响应消息触发错误的Promise状态变更的问题。

• 请求id不需要追求全集群全局唯一：每个Worker的请求缓存Map是独立存在Worker进程内存里的，如果多个Worker同时向Master发请求，哪怕生成的requestId重复也没关系，只要在单个Worker的消息队列里不冲突就行，不需要为了全局唯一引入额外的分布式协调成本
• 及时清理缓存条目：不管是正常收到响应、请求超时、Worker进程被销毁的场景，都要把对应缓存Map里的条目删掉，不然长期运行很容易造成内存泄漏
• 注意消息序列化的限制：Node.js的Worker通信是走结构化克隆算法的，传递的参数不要带函数、闭包、DOM这类无法被克隆的内容，不然会直接导致消息发送失败

内容的提问来源于stack exchange，提问作者Ivan Kolyhalov