ZeroMq插座设计

Question

我需要从不同的代理向单个进程发送大量的短消息 。

来自10个代理的大约10-15 2-3 Kb消息/秒。

一些代理在同一台计算机上运行，​​而其他代理则在同一VLAN中的不同计算机上运行。

要求是在生成消息与开始在主要服务内部进行处理之间的最小延迟 。 峰值最大50ms是可以接受的（尽管不是必需的）。

我计划使用NetMq进行传输。

Q1：套接字类型和协议的最佳配置是什么？

问题2：使用DEALER / ROUTER ， PUSH / PULL还是PUSH / ROUTER设置更好 ？

问题3：我应该在同一台计算机上为代理使用 IPC套接字，还是对于两种类型的代理来说TCP足够快？

Q4：我需要在同一上下文中创建TCP和IPC套接字还是创建单独的上下文？

Answer 1

主题：消息传递，传输，延迟

ZeroMQ是一个可扩展的正式通信模式框架。 它提供了一组智能对象，并向设计师隐藏了很多内部细节（这是非常有益的）。

ZeroMQ专为消息传递而设计

与传输无关的，这意味着，大多数交付用例都不在乎特定的传输类（ { inproc: | ipc: | tcp: | pgm: | epgm: } ）上

优化了低延迟 （作为“包含电池”的原则）

您似乎错过了的关键是，主要区别在于以下事实：您的应用程序应建立在ZeroMQ原型的BEHAVIOUR之上，该行为使用用例隐喻名称（ PUSH/PULL ）表示，但理解这对于任何好的设计都非常重要。

延迟只会天空火箭，如果设计决策不佳使得软件使用“错误”（没有得到很好的选择）ZeroMQ-原型，其行为学-MODEL又将引入unevitable需要处理/等待/阻止一个工作流程例如，由于REQ/REP内部行为被误解等原因。

这样，可实现的最低延迟就来自智能设计，而不是（ * ）MQ库。

ZeroMQ在接近实时的系统设计中具有精湛的工艺，将使其最适合您的代码中的真正服务，但是不要指望糟糕的系统架构仅通过连接一些ZeroMQ就能获得几乎没有的魔术般的速度和延迟。 -socket方法。

在.Context( nIOthreads )

通常的良好做法是隔离设计特征，以便能够验证其对最终标准的影响。 如果需要最小的整体端到端延迟，则可能有步骤增加localhost应用程序通过.Context()方法实例化和使用的IO线程数。

即使对于Raspberry Pi处理器，每秒10 x 15 x 3kB也不是什么大问题。

更为重要的是，这一唯一步骤是否会比其他设计妥协和/或其他IO工作负载相关活动带来任何重大改进。

测试一下。

但是 ，请在一组人为的学术环境下对它进行“ 体内 ”测试，而不是“体外”测试。 然后，您便获得了成功，而没有损失，因为您的“周围”架构已经实现，并且可以在设计的操作方法的上下文中进行测量。

接下来要去哪里？

最好的出发点是花一个星期进行一次Pieter HINTJEN的书“ Code Connected，Volume 1” (asPdf)的动手测试。 在这里，您已经讨论了出色的深度知识库和代码示例，这将帮助您继续前进。

---

让基于优点的事实成为焦点：

解答4：否，本书着重强调了zmq.Context()是单例的情况，并且在架构/设计/测试证明其有益的情况下，zmq.Context（）实例可能不止一个I / O-线程来处理低级别的特定流量模式（ 无需用户代码方面的任何其他帮助/控制）。 从这个意义上讲，在已经实施并经过预测试的解决方案投入使用之前，推测这种潜在的好处是没有意义的。 一旦解决方案开始运行，就可以增加该参数并通过实验测量其对整体处理性能的影响。

始终提醒您的最佳做法是，在执行套接字和上下文生命周期的正常终止时要采取适当的措施，以免产生脏泄漏。 这种做法超出了建议。

A3：是的，也可以对它们使用TCP-transport-class。 在非Windows localhost上，可以使用IPC选项。 速度问题应该被衡量，而不是基于意见。 如果您的代码争夺要减少额外的[us] -s和[ns] -s（zmq.Stopwatch的分辨率降低到大约三十亿分之一秒），那么根据您的代码设计，您可能会期望一些避免使用TCP协议有线框架组装/重新组装/解码，可以带来一些好处。 常见的问题是，对于任何可测量/可观察到的提速，这可能会产生哪些额外费用。

A2：回答范围太广。 如果不对处理体系结构/ taskUnit的工作流程一言不发，就没有认真的答案Q2。

A1：缺少优化目标为“ 最佳 ”的条件。 没有条件/指标，只有一条通用规则才是有效的-最好的规则是任何这样的规则，它完全符合规格并且在给定的时间和预算内可以稳定良好地工作。