使用 ZeroMQ 发送大型消息（高达千兆字节）有哪些缺点？
What are down sides of using ZeroMQ for sending large messages (up to gigabytes)?
我发现人们不推荐使用 ZeroMQ 发送大消息。但是拆分数据真的让我很头疼（有点扭曲）。为什么不推荐这样做有一些具体原因吗？能克服吗？
为什么不推荐这个？
资源...
即使是最好的 Zero-Copy 实施也必须有备用资源来将有效载荷存储在几个主要独立的单独位置：
|<fatMessageNo1>|
|...............|__________________________________________________________ RAM
|...............|<fatMessageNo1>|
|...............|...............|__________________Context().Queue[peerNo1] RAM
|...............|...............|<fatMessageNo1>|
|...............|...............|...............|________O/S.Buffers[L3/L2] RAM
能克服吗？
当然，不要发送 Mastodon-sized-GB+ 条消息。可以使用任何类型的 off-RAM 表示并仅发送一个轻量级引用以允许远程对等方访问这样一个巨大的野兽。
通过评论添加了许多新问题：
（在 Whosebug 中被认为是 un-fair）
I was concern more about something like transmission failure: what will zeromq do (will it try to retransmit automatically, will it be transparent for me etc). RAM is not so crucial - servers can have it more than enough and service that we write is not intended to have huge amount of clients at the same time. The data that I talk about is very interrelated (we have molecules/atoms info and bonds between them) so it is impossible to send a chunk of it and use it - we need it all)) – Paul
您可能已经意识到 ZeroMQ 在 Zen-of-Zero 下工作，其中 zero-warranty 也占据了一席之地。
因此，ZeroMQ 分派的消息将 传送 "through" error-free，或者根本不传送。这是一个很棒的 pain-saver，因为您的代码将仅自动接收 fully-protected 内容，因此任何受折磨的垃圾都不会到达您的目标 post-processing。更高级别的 soft-protocol 握手允许一个人保持控制，从而能够从更高级别的抽象中缓解 non-delivered 案例，因此如果您的设计能力和部署条件允许， 可以利用蛮力强制发送任何-[TB]-BLOBs，如果其他人允许并且不介意的话，自己承担阻塞本地和基础设施资源的风险（......但从不听从我的建议：o） )
Error-recovery self-healing - 来自 lost-connection(s) 和类似的 real-life 问题 - 在配置、资源和超时允许的情况下处理，所以有很多麻烦保持 L1/L2/L3-ISO-OSI 层问题对 user-apps 程序员有效隐藏。
我发现人们不推荐使用 ZeroMQ 发送大消息。但是拆分数据真的让我很头疼（有点扭曲）。为什么不推荐这样做有一些具体原因吗？能克服吗？
为什么不推荐这个？
资源...
即使是最好的 Zero-Copy 实施也必须有备用资源来将有效载荷存储在几个主要独立的单独位置：
|<fatMessageNo1>|
|...............|__________________________________________________________ RAM
|...............|<fatMessageNo1>|
|...............|...............|__________________Context().Queue[peerNo1] RAM
|...............|...............|<fatMessageNo1>|
|...............|...............|...............|________O/S.Buffers[L3/L2] RAM
能克服吗？
当然，不要发送 Mastodon-sized-GB+ 条消息。可以使用任何类型的 off-RAM 表示并仅发送一个轻量级引用以允许远程对等方访问这样一个巨大的野兽。
通过评论添加了许多新问题：
（在 Whosebug 中被认为是 un-fair）
I was concern more about something like transmission failure: what will zeromq do (will it try to retransmit automatically, will it be transparent for me etc). RAM is not so crucial - servers can have it more than enough and service that we write is not intended to have huge amount of clients at the same time. The data that I talk about is very interrelated (we have molecules/atoms info and bonds between them) so it is impossible to send a chunk of it and use it - we need it all)) – Paul
您可能已经意识到 ZeroMQ 在 Zen-of-Zero 下工作，其中 zero-warranty 也占据了一席之地。
因此，ZeroMQ 分派的消息将 传送 "through" error-free，或者根本不传送。这是一个很棒的 pain-saver，因为您的代码将仅自动接收 fully-protected 内容，因此任何受折磨的垃圾都不会到达您的目标 post-processing。更高级别的 soft-protocol 握手允许一个人保持控制，从而能够从更高级别的抽象中缓解 non-delivered 案例，因此如果您的设计能力和部署条件允许， 可以利用蛮力强制发送任何-[TB]-BLOBs，如果其他人允许并且不介意的话，自己承担阻塞本地和基础设施资源的风险（......但从不听从我的建议：o） )
Error-recovery self-healing - 来自 lost-connection(s) 和类似的 real-life 问题 - 在配置、资源和超时允许的情况下处理，所以有很多麻烦保持 L1/L2/L3-ISO-OSI 层问题对 user-apps 程序员有效隐藏。