使用ZeroMQ发送大型消息（高达千兆字节）的不足之处是什么？

Question

我发现人们不建议使用ZeroMQ发送大量邮件。但是我分割数据真的很头疼（它有点扭曲）。为什么不建议这是有一些具体原因？可以克服吗？

Answer 1

为什么不建议这样做？

资源......

即使是最好的零拷贝实现也必须有备用资源来将有效负载存储在几个主要独立的独立位置：

|<fatMessageNo1>|
|...............|__________________________________________________________ RAM
|...............|<fatMessageNo1>|
|...............|...............|__________________Context().Queue[peerNo1] RAM
|...............|...............|<fatMessageNo1>|
|...............|...............|...............|________O/S.Buffers[L3/L2] RAM

可以克服吗？

当然，不要发送Mastodon大小的GB +消息。可以使用任何类型的off-RAM表示，只发送一个轻量级引用，以允许远程对等方访问这样一个巨大的野兽。

通过评论添加了许多新问题：
_{（在StackOverflow中被视为不公平）}

  

_{我更关心的是传输失败：zeromq会做什么（它会尝试自动重新传输，对我来说是透明的等等）。 RAM并不是那么重要 - 服务器可以拥有足够的内容，我们编写的服务并不是为了同时拥有大量的客户端。我所谈论的数据是非常相互关联的（我们有分子/原子信息和它们之间的联系）所以不可能发送它的大块并使用它 - 我们需要它）） - Paul {{3 }}}

您可能已经意识到ZeroMQ正在Zen-of-Zero下工作，零保修也取而代之。

因此，ZeroMQ调度的消息将 传递＆＃34;通过＆＃34;没有错误，或根本没有交付。这是一个非常痛苦的保护程序，因为您的代码将原子地仅接收完全受保护的内容，因此任何折磨垃圾都不会到达您的目标后处理。更高级别的软协议握手允许人们保持控制，从而可以从更高级别的抽象中缓解未交付的案例，因此，如果您的设计适应和部署条件允许，可以利用蛮力并发送任何内容 - { {1}} - BLOBs ，如果其他人允许并且不介意的话，他们自己也有阻止本地和基础设施资源的风险（......但从未听过我的建议：o））

错误恢复自我修复 - 从丢失的连接和类似的现实问题 - 在配置，资源和超时允许的情况下处理，因此保留L1 / L2 / L3-ISO-OSI会带来很多麻烦用户应用程序程序员可以有效地隐藏图层问题。