Q1:与这里解释的默认进程间通信相比,使用向子进程发送消息到底有什么区别?ZeroMQ
Q2:对于孩子的直接沟通,哪个更合适?(更快)
Q3:文档说:Creates an IPC channel
,它使用什么样的IPC
?TCP
? 插座?
在最初的那一刻说明一个很好的观点 -ZeroMQ
没有经纪人
ZeroMQ
A1:使用发送消息和发送消息的区别IPC
好吧,这样说来,ZeroMQ
专注于许多不同的好处,而不仅仅是发送消息和扩大规模的能力(两者都有帮助)。
ZeroMQ
引入(良好的可扩展性)正式沟通模式这就是说,核心应用程序侧的重点是针对哪些 ZeroMQ 库模式原语可以用于直接满足参与代理之间实际需要的行为模型(一个PUB
+ 多SUB
-s / 多PUB
-s + 许多交叉连接的SUB
-s )
或
如何组成更复杂的、特定于应用程序的信号平面(使用可用ZeroMQ
的构建块行为原始套接字原型 + 设备 + 应用程序逻辑,为信号平面添加功能提供有限状态机或事务引擎)。
IPC
提供了一个愚蠢的基于 O/S 的服务,没有行为这很好,如果在纯 O/S 上下文中理解(即“包括电池”不是这种情况)。
尽管如此,任何更高级别的消息传递支持和其他重要功能(如公平队列、循环调度、在任何/所有传输类上的多路复用传输无关服务组合{ inproc:// | ipc:// | tcp:// | pqm:// | ... }
、毫秒调整的多通道轮询器、零复制消息移交和许多其他智能功能)将由您自己设计/实现(正是这种情况,为什么将 ZeroMQ 放入游戏中,而不是必须这样做,不是吗?非常感谢,Martin SUSTRIK 和 Pieter HINTJENS 的团队)
要查看有关此主题的更大图景 >>>更多参数,一张简单的信号平面图片和指向 Pieter HINTJENS 必读书籍的直接链接。
如果对 a 的妹妹感兴趣ZeroMQ
,nanomsg
可以查看 Martin SUSTRIK 的更轻量级的框架nanomsg.org >>>
。
快,快,快……
有关最小开销(读作具有很高的速度潜力)零拷贝(读作有效的开销避免)的灵感,请阅读有关inproc://
线程间消息传递的传输类:
IPC
.IPC
本身就是一个传输类。如果通过通道在进程之间正确传输,则无需重新包装/对齐/组装/CRC/封装/调度|解码\CRC-recheck\demap ...原始IPC
数据到更高抽象的数据包中,是吗?TCP
localhost
IPC
使用 ZeroMQ 之类的消息队列使您能够横向扩展至多台机器,而子进程通信仅在本地进行,并且只能横向扩展以利用该机器上的硬件。
拥有消息代理会变慢,因为它依赖于 TCP,而子进程通信使用管道或标准 I/O。哪个更快,因为它避免了 TCP 和网络堆栈的开销。虽然我会说这里的速度优势可以忽略不计,特别是如果您计划扩展到多台机器。
还值得注意的是,ZeroMQ 可以使用 unix_sockets,并提供与child_process
核心模块提供的非常相似的其他形式的 IPC。虽然它可能会更难使用。
在需要跨多台机器横向扩展之前,将 ZeroMQ 与 unix_sockets 或管道一起使用也许不是一个坏主意。
好吧,在您链接到的情况下,我们正在谈论两个相互竞争的协议。一个是通用的(ZMQ),另一个是绑定到 NodeJS。引用关于 IPC 的文章,您链接到“不支持以任何方式访问 IPC 通道 fd,而不是 process.send() 或将 IPC 通道与不是 Node.js 实例的子进程一起使用。”
一般来说,IPC(进程间通信)可以指许多不同的协议,包括 ZMQ。ZMQ 是一种 IPC 机制。还有其他较低级别的机制,例如 PIPE 和 UDP 套接字。我使用过 PIPE 和 UDP 套接字,发现即使在简单的两方情况下,更高级别的协议(例如 ZMQ)也几乎总是更好,因为 PIPE 和 UDP 存在两个问题:
缓冲和分块。
缓冲:操作系统不断创建缓冲区来存储在进程之间发送的消息部分。这些缓冲区必须被刷新。您最终不得不编写一堆难以正确编写的繁琐代码,既要刷新消息,又要读取和拼接在一起,部分发送的消息。
分块:UDP 具有可变的最大消息大小,介于 500 和 65000 字节之间。直接使用 UDP 时,您必须处理这些最大大小并分块您的消息。ZMQ 自动处理分块,您不必摆弄它。ZMQ 中没有最大消息大小(嗯,在 ZMQ 的情况下,消息必须适合内存)。