在以下场景中必须使用什么模式的ZMQ？

Question

我最近开始学习ZMQ（Python）。我必须承认，我发现很难理解 PUSH/PULL 和 DEALER/ROUTER 模式。

我的问题陈述如下：

1. N 客户的数量（例如100）将在10:00:00（小时：分：秒）发送请求（查询某些数据，访问资源等） AM
2. 服务器必须在上午10:00:00处理所有N请求。
3. 假设请求需要30秒才能完成，所有客户端（100）必须在上午10:00:30收到响应
4. 我应该使用什么样的ZMQ？

  

我理解REQ/REP是同步的，我无法使用该模式来解决特定问题。 （服务器一次只能处理一个请求）

请帮助我使用ZMQ开发客户端/服务器应用程序的示例程序/链接。 （服务器必须至少一次处理100个请求）

如果第二天请求数量增加，我能否使用ZMQ进行扩展？
如果是，怎么做？

Answer 1

您有 N 个客户端和1个服务器。
服务器将无法同时完成N个请求 。
显然，服务器可以使用crontab或其他调度机制在凌晨10:00:00开始处理N个请求。

适当的ZMQ模式似乎是 PUSH/PULL 。见http://zguide.zeromq.org/page:all

并导航至Figure 6 - Fair Queuing.

要回答缩放问题：您可以将服务器视为请求的单个入口点，服务器后面有一些（>= N）并行工作者。此体系结构显示在Figure 20 - Multithreaded Server。

中

该架构理论上可以解决并发问题，但有一些重要的评论：

1. 只有每个工作人员都有一个单独的CPU核心时，才能使用真正的并行执行（注意：它们可能使用tcp://地址分布在多台计算机上）。如果您有< N个核心可用，那么最终会使您的工作并行，并且操作系统会使其再次顺序。

2. 如果worker上的执行时间是I / O限制的（即数据库查询，文件系统访问等），请在较小的节点中剪切图形并仅使CPU绑定的任务并行。

   < / LI>

3. 单个服务器，即使它只向工作池发送请求，也是可扩展性限制。在设计的某一点上，您需要做出与CAP theorem相关的选择。

Answer 2

可扩展性：

是的， ZeroMQ 是一个强大的工具。在没有进入低级细节的情况下，与任何ZeroMQ相关的部分相比，您的方案在服务器端流程管理方面存在更多问题。

需要更多功率，ZeroMQ只需在模式的处理端添加适当的资源即可提高其处理能力，而客户端（请求者代码）代码无需更改SLOC

硬实时约束：

如果您的1-2-3原理图的时序允许在服务器端（并且我们说毫秒和微秒的不准确度，以满足30秒的硬实时并行性，这将直接对抗墙上的100 + 4-core / 8-core / MPPA-manycore处理器单元的处理任务），您的代码可以继续使用可扩展的负载均衡消息代理 [Figure 32]，可以同时解决 1-2-3计划。

如果努力达到10：00：30：000.000000毫秒的障碍，您的处理方必须分发 - 即 [worker] 进程的更多真实主机（不是任何VM）在任何类型的按需＆＃34;云供应虚构中）。

一台服务器根本不能使{strong> N*30[sec] 小于{ {1}} 30[sec]（不要忘记并发调度和消息处理流量开销的成本）。

真实世界系统架构必须包含更多＆＃34;电线＆＃34;：

如果你的代码努力投入生产，而不仅仅是学术界的例子，那么就必须做更多的工作，为现实世界的生产环境提供生存能力措施。

使用ZeroMQ进行逼真设计的好读物是Pieter HINTJEN的书＆＃34; Code Connected，Vol.1＆＃34; （查看我在ZeroMQ上的帖子，找到pdf-链接）。

另一个好读物来自ZeroMQ的共同之父Martin SUSTRIK，low-level truths about the ZeroMQ implementation details & scale-ability

_{后记： N > 2原始行为通信模式在现实世界中是危险的，因为它可以自我死锁通信进程对，以防传输（无论出于何种原因）丢失了一个数据包，并且＆＃34;摆式＆＃34;风格的消息传递不完整并永远锁定。}