我需要从不同的代理向单个进程发送大量短消息。
来自 10 个代理的大约 10-15 2-3 Kb 消息/秒。
一些代理在同一台机器上运行，而另一些则在同一 VLAN 中的不同机器上运行。
要求是消息生成和主服务内开始处理它之间的最小延迟。 50ms 在峰值处的最大值是可以接受的（尽管不是理想的）。
我打算使用 NetMq 进行传输。
Q1：最好的套接字类型和协议配置是什么？
Q2：使用 DEALER/ROUTER、PUSH 是否更好 >/PULL 或 PUSH/ROUTER 设置？
Q3：我应该为同一台机器上的代理使用IPC套接字还是TCP对于两种类型的代理都足够快？
Q4：我需要在同一上下文中创建TCP 和IPC 套接字还是创建单独的上下文？
【问题讨论】：
ZeroMQ 是一个可扩展的正式通信模式框架。它提供了一组智能对象，并向设计师隐藏了很多内部细节（这非常有益）。
ZeroMQ 专为消息传递
而设计Transport-不可知论，这意味着大多数用例并不关心交付发生在哪个特定的 Transport-class ({ inproc: | ipc: | tcp: | pgm: | epgm: })
低延迟优化（作为“包括电池”的原则）
您似乎错过了关键的一点是，主要区别在于您的应用程序应建立在 ZeroMQ 原型的 BEHAVIOUR 之上，该行为使用用例隐喻名称 (@987654323 @ )，但是理解哪一个对于任何好的设计都非常重要。
延迟只会在糟糕的设计决策导致软件使用“错误”（未精心选择）ZeroMQ-archetype（其 BEHAVIOURAL-MODEL 将反过来引入处理/等待/阻止工作流模型的不可避免的需要，只是由于对 REQ/REP 的内部行为的误解作为示例，并且一样的。
这样，可实现的最低延迟来自智能设计，而不是来自 (*)MQ 库。
ZeroMQ 在近乎实时的系统设计方面拥有精湛的技艺，可以将其最好的真正服务融入您的代码中，但是不要指望糟糕的系统架构仅仅通过链接几个链接就能获得接近零的神奇速度和延迟ZeroMQ 套接字方法。
.Context( nIOthreads )
一个普遍的良好做法是隔离设计特征，以便能够验证它们各自对最终标准的影响。如果存在最小的整体端到端延迟，则可能需要增加 IO 线程的数量，由localhost 应用程序通过.Context() 方法实例化和使用。
每秒 10 x 15 x 3kB 即使对于 Raspberry Pi 处理器也不是什么大问题。
更重要的是，与其他设计妥协和/或其他 IO 工作负载相关的活动相比，这一唯一步骤是否会带来任何重大改进。
测试一下。
但是在一组人为的学术环境下“in-vivo”测试它，而不是“in-vitro”。然后，您将获得不失，因为您的“周边”架构已经实现，并且您在设计的操作方式的上下文中进行测量。
最好的起点是用 Pieter HINTJEN 的书 "Code Connected, Volume 1" (asPdf) 进行一周的动手测试。在那里，您讨论了精彩的深入知识库和代码示例，这将帮助您继续前进。
让基于优点的事实成为焦点：
A4： 不，本书尽可能强调zmq.Context() 是一个单例，并且在架构/设计/测试证明它有益的情况下，zmq.Context() 实例可能具有不仅仅是一个 I/O 线程来处理低级别的特定流量模式（没有来自用户代码方面的任何其他帮助/控制）。从这个意义上说，在已经实施和预测试的解决方案上线之前，推测这种潜在的好处是没有意义的。一旦解决方案运行起来，就可以增加这个参数并通过实验测量它对整体处理性能的可能影响。
始终提醒的一个很好的做法是，对强制套接字和上下文生命周期的优雅终止确实采取应有的注意，以避免肮脏的泄漏。这种做法是非常值得推荐的。
A3：是的，他们也可以使用 TCP-transport-class。在非 Windows 本地主机上，IPC 选项变得可行。速度问题应该是衡量的，而不是基于意见的。如果您的代码努力减少额外的 [us]-s 和 [ns]-s （zmq.Stopwatch 的分辨率下降到大约 30 纳秒），那么根据您的代码设计，您可能会期望一些避免 TCP 协议有线成帧组装/重新组装/解码的好处。常见的问题是，对于任何可衡量/可观察的加速，这可能会产生哪些额外成本。
A2： 太宽泛，无法回答。如果对处理架构/taskUnit 的工作流程只字不提，就无法认真回答 Q2。
A1：缺少将优化目标设为“最佳”的标准。没有标准/指标，只有一个通用规则是有效的——最好的就是这样一个，它完全符合规范并且在给定的时间和预算内工作正常且稳定。
【讨论】：