我需要从不同的代理向单个进程发送大量短消息。
来自 10 个代理的大约 10-15 2-3 Kb 消息/秒。
一些代理在同一台机器上运行，而另一些则在同一 VLAN 中的不同机器上运行。
要求是消息生成和主服务内开始处理它之间的最小延迟。峰值的最大值50ms是可以接受的（尽管不是理想的）。
我计划使用 NetMq 进行传输。
Q1： socket类型和协议的最佳配置是什么？
Q2：使用DEALER/ ROUTER，PUSH/PULL或PUSH/ROUTER设置更好吗？
Q3：我应该 IPC在同一台机器上为代理使用套接字还是TCP对两种类型的代理都足够快？
Q4：我需要在同一个上下文中创建TCP和IPC套接字还是创建一个单独的上下文？
ZeroMQ 是一个可扩展的正式通信模式框架。它提供了一组智能对象，并向设计师隐藏了许多内部细节（这非常有益）。
ZeroMQ 专为消息传递而设计
与传输无关，这意味着大多数用例不关心{ inproc: | ipc: | tcp: | pgm: | epgm: }交付发生的特定传输类 ( )
低延迟优化（作为“包含电池”的原则）
您似乎错过的关键是，主要区别在于您的应用程序应建立在 ZeroMQ 原型的 BEHAVIOUR 之上，它使用用例隐喻名称PUSH/PULL(对任何好的设计都很重要。
如果糟糕的设计决策使软件使用“错误”（没有很好地选择）ZeroMQ 原型，则延迟只会飙升，其BEHAVIOURAL - MODEL反过来将不可避免地引入处理/等待/阻止工作流的需要模型，只是由于误解了内部行为REQ/REP作为示例等。
这样，可实现的最低延迟来自智能设计，而不是来自 ( *)MQ 库。
ZeroMQ 在近乎实时的系统设计方面拥有精湛的技艺，可以将其最好的真正服务融入您的代码中，但是不要指望糟糕的系统架构仅通过链接几个 ZeroMQ 就能获得几乎没有的神奇速度和延迟-套接字方法。
.Context( nIOthreads )一个普遍的良好做法是隔离设计特征，以便能够验证它们各自对最终标准的影响。如果存在最小的整体端到端延迟，则可能需要增加 IO 线程的数量， 通过方法实例化并由localhost应用程序使用。.Context()
即使对于 Raspberry Pi 处理器，每秒 10 x 15 x 3kB 也不是什么大问题。
更重要的是，这一唯一步骤是否会比其他设计妥协和/或其他 IO 工作负载相关活动带来任何重大改进。
测试一下。
然而，在一组人为的学术环境下“体内”测试它，而不是“体外”。然后您将获得不失，因为您的“周围”架构已经实现，并且您在设计的操作方式的上下文中进行测量。
好的开始是用 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：缺少优化目标为“最佳”的标准。没有标准/指标，只有一个通用规则是有效的——最好的就是这样一个，它完全符合规范并在给定的时间和预算内工作正常且稳定。