我正在一个项目中，在这个项目中，我在多个线程中使用单个zmq_push套接字，其中每个线程连续发送数据包。另一方面，我有一个继续接收的Zmq_Pull套接字。...我希望这个过程更快，我的应用程序通过zmq push发送数据包的速度很快，但是我怀疑我的接收速度是否更快。 ..每个线程发送数据的另一件事是唯一的，基于每个线程数据，我在接收方的不同线程中进行处理....如何使此过程更快。我相信，与其在Recv端在每个数据包上循环，不如在每个线程上都需要这样做……有关如何执行此操作的任何答案？
答案 0 :(得分：0)
要使您的接收器端具有更大的吞吐量，请添加多个具有各自线程或进程的PULL套接字
然后使用PULL和PUSH套接字创建zmq_proxy进程。这非常简单，只需几行代码http://api.zeromq.org/4-3:zmq-proxy
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
| PUSH | | PUSH | | PUSH | | PUSH |
| | | | | | | |
+------+---+ +---------++ +-+--------+ +--+-------+
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| v v |
| |
| +------------+ |
| | | |
+-----------------> | PULL | <---------------+
| |
+------------+
| zmq_proxy|
+------------+
| PUSH |
+--------------------+ +----------------+
| +-----+------+ |
| | |
| | |
| | |
| | |
| | |
+-----v----+ +-----v----+ +---v------+
| | | | | |
| PULL | | PULL | | PULL |
| | | | | |
+----------+ +----------+ +----------+
注意：：如果您想要更智能的负载平衡，则需要使用提供反馈的插座，例如ROUTER / DEALER。 http://zguide.zeromq.org/page:all#The-Load-Balancing-Pattern
答案 1 :(得分：0)
问：如何使此过程更快？
A：我们需要同时进行和处理
如果您认为ZeroMQ概念对您来说并不陌生，并且在以后的工作中可能很难掌握，那么您可能想回顾一下[ The principles of the ZeroMQ hierarchy in less than a five seconds ] 中的关键概念功能/ p>
a）总是可以通过实例化具有Context( nIoTHREADs )
nIoTHREADs >> 1 来提高与通信相关的处理能力。
b），在经过技术验证的需求下，可以通过设计效率很高的本地进程间消息传递基础结构来减轻每个处理线程的负担（以减轻来自线程的通信负担，使用从每个处理线程到“中央”数据抽取Communicator的无协议栈inproc://通信通道的特定处理）（Context实例可以在线程之间共享，而Socket实例可能不是-这是ZeroMQ零禅（通过设计）。这样，每个处理线程都不会阻塞或隔离宝贵的资源，从而可为“中央”数据泵Communicator的更高容量提供可用资源，并且可以将工作负载中与通信相关的部分“委托”到“中央”数据泵，在处理线程中使用最轻巧的“一劳永逸”哲学，同时使Communicator可以处理和管理所有潜在的智能功能，例如用于丢弃消息的应用程序级ACK / NACK信令，即时服务容量扩展和每个性能调优工程师都希望拥有许多相似的功能。
c），在技术上表明需要的情况下，可以使用PULL-接收器池来提高接收侧（PULL端）的性能，将 PUSH -面简化为.connect()到每个'em。 PUSH侧Context实例的内部机制将需要为多个传出IO通道配置良好的（配置合理的）配置，但是，如果远程侧的PULL-ers'处理性能是阻碍因素，这种增加和可扩展的池容量是解决之道-当然，显然PULL侧资源已经与发送方并置在同一硬件节点上，情况并非如此已经处于可用处理能力的上限（ZeroMQ的思维方式一直在相当分散，而不是在单个本地硬件/ OS上并置处理代理程序-这是Zen-of-Zero传播的自由和< sub>几乎线性性能可伸缩性）。