问用于大型消息的电子IPC的替代方案

EN

我有一个React/Electron分裂成2个进程(还有更多的进程)--一个前端，一个后端，还有很多潜在的“审查员”窗口。它们都是通过使用剩余电子商店的Redux连接的，它使用IPC保持所有实例的同步，主进程是“主”节点，呈现器被发送给不同的操作。后端处理大量图像和XML (可能有数百个)，并将它们发送到Redux存储，从而导致整个事件挂起。前端需要缩略图，其他两个窗口都需要解析的XML数据。

最初，我将每个项目作为自己的Redux操作发送，结果产生了类似的200个动作，从而冻结了它。我还试着把这些东西弄得乱七八糟，每2秒发送一次，这很好，直到性能开始下降。然后，我将其更改为批处理过程，每种类型的处理--缩略图或解析XML --对一组文件执行一个操作，这将产生2个48 in和37 in或类似的有效负载，这更好，但仍然会将所有操作冻结几秒钟。

我在主进程中放置了一个小的间隔计数器，以查看它是主进程还是渲染器挂，并且似乎主要过程是冻结的，大概是在接收和重新发送这些大消息时(当然，这不是建立因果关系的一种非常可靠的方法)。所以我不太确定该如何重组事情来停止冻结主要的过程。我们有两个想法：

1. 将缩略图和XML数据抽象到Redux的另一个部分，它不会由IPC同步，相反，后端有一个小型的本地websocket服务器，它可以直接与请求数据的进程通信，这将把数据放入自己的Redux中，而不是同步它。这也许可以用WebWorkers来完成吗？这样可以避免向主进程发送大的有效负载，并且web工作人员应该避免冻结渲染器。
2. 合作伙伴的想法是拥有一个可能被读/写到的本地数据库，其他窗口可能需要得到通知，并可能将其存储在组件状态而不是Redux中。由于引入了更多的I/O操作，需要维护该文件，以及一些额外的修补程序通知需要该文件的组件，写入操作已经完成，因此我不太喜欢这样做，以便读取相同的数据。

IPC目前都是异步完成的，尽管它仍然阻塞。

这一切都是基于这样的印象:冻结渲染器的大消息是唯一的问题，而不是Redux用它做的事情，这也可能是真的，但是，将它从同步的同步中删除，如解决方案1中所述，将会涵盖这两个问题。

如果有人对如何更好地构造这个结构有任何想法，我会非常感激的。