向Worker进程传递大量索引数据的最优方案咨询

现有方案优劣对比 #

• 方案1（消息传递）：数MB级数据的原生克隆开销在数秒级任务中占比可控，但Mongoose文档需先调用toObject()转成普通JS对象再传递。如果改用Transferable Objects（将数据序列化为ArrayBuffer后转移所有权），可彻底避免克隆开销，仅转移内存引用，这会大幅降低传递成本，是当前场景下的最优选择。
• 方案2（Worker独立连数据库）：每个Worker单独建立连接池会导致数据库连接数激增，容易触发连接上限。而且重复查询数MB数据的网络IO+数据库查询开销，远高于数据传递的成本，仅适合数据实时性要求极高且无法提前获取的场景，不推荐。
• 方案3（文件读写）：磁盘IO开销远大于内存级数据传递，还要处理文件唯一性、锁竞争等问题，会额外增加系统复杂度和延迟，完全不适用。

其他可行方案 #

• SharedArrayBuffer共享内存：将数据序列化为TypedArray后存入SharedArrayBuffer，所有Worker可直接访问同一块内存区域，无需数据传递。适合多Worker复用同一份索引数据的场景，但需注意用Atomics API保证线程安全，避免并发读写冲突。
• 主进程缓存+按需分片传递：如果索引数据可拆分，主进程缓存完整数据，Worker根据任务需求请求对应数据片段，减少单次传递的数据量，适合无需完整数据即可完成部分比对的场景。
• 本地缓存中间件（如Redis）：主进程将预处理后的索引数据存入Redis，Worker从Redis读取数据。Redis的内存读取速度远快于数据库，且可复用连接池，避免Worker重复建立数据库连接，适合数据需要跨进程复用且更新频率较低的场景。

内容的提问来源于stack exchange，提问作者Lee Morgan