这可能看起来是一个愚蠢的问题，但我真的对 ZeroMQ 关于同步套接字的术语感到困惑，例如REQ and REP。
据我了解，同步通信发生在客户端发送消息然后阻塞，直到响应到达。如果 ZeroMQ 实现了同步通信，那么只有 .send() 方法对于同步套接字就足够了。
我认为 ZeroMQ 的同步套接字术语仅指在最后一条消息的响应到达之前无法发送更多消息，但“发送方”仍然可以继续异步处理（做更多事情）。
这是真的吗？
在这种情况下，是否有任何直接的方法可以使用 ZeroMQ 实现同步通信？
编辑：当我想在远程进程（如 RPC）中调用方法时，同步通信是有意义的。如果我想在远程进程中执行一系列命令，并且每个命令都需要前一个命令的结果来完成其工作，那么异步通信不是最佳选择。
【问题讨论】：
标签： asynchronous zeromq synchronous
要使用 ZMQ 实现同步框架，您几乎可以仅使用 ZMQ 来实现；您可以将高水位标记设置为 1。不幸的是，这还不是。你想要的是一个 0 的外出队列长度。更不幸的是，将高水位标记设置为 0 被 ZMQ 解释为无穷大......
所以唯一的选择是在 ZMQ 之上实现一个同步传输协议。这不是很难做到。两端之间的对话将类似于“我可以发送吗？”，“是的，你现在可以发送”，“好的，这里是”，“好的，我收到了”（两端都返回给调用者）（或至少的程序版本）。这设置了所谓的执行会合 - 两端都知道它们都到达了某个执行点。
从技术上讲，您正在做的是采用 ZeroMQ（Actor 模型）并将其转变为更像通信顺序流程的东西。
RPC
说了这么多，从你的编辑我想你可能会考虑Cap'n Proto。这是一种具有简洁 RPC 技巧的 C++ 序列化技术。如果一个 RPC 调用的返回是另一个 RPC 调用的输入，您可以提前以某种方式将它们链接在一起（参见here）。
【讨论】：
ZeroMQ 更多的是思考分布式系统（类似多代理）以及如何使用这种智能信号/消息传递框架来设计软件的概念。
这是 ZeroMQ 的核心目标，让设计人员在应用程序领域保持思考，让所有低级的脏工作真正操作起来，而不需要设计人员过多关心。
如果最近刚开始使用 ZeroMQ，在讨论细节之前可以先享受short read about a ZeroMQ global view first,。
阅读并理解 ZeroMQ 层次结构的概念后，从细节开始会更简单：
假设本地 Context() 实例是一个数据泵送引擎，并考虑到 REQ/REP 可扩展的正式通信原型模式，故事是现在实际上是一个关于分布式有限状态自动机网络的故事。
本地进程，仅操作分布式REQ/REP 通信原型的一侧，影响远程进程接收或不接收从本地进程传递到 ZeroMQ 传递服务的消息的权力为零。在公平的信念中指定的接收者。本地进程对远程进程的响应意图的影响越小，所以欢迎来到分布式多代理游戏领域。
REQ 和 REP 的正式行为都必须满足其 { local |分布式模式 }- 预期的行为——REQ 先问，REP 然后回答，以遵守约定的承诺。关键是，这种行为是分布在一对节点之间的，而且在某些情况下，网络事件可能会使分布式 FSA 陷入无法挽救的相互死锁（人们可能会经常在 zeromq 找到更多关于此的帖子)。
因此，您的本地REQ 代码强制.send()-s 并且没有义务停止而不做任何合理的事情，直到REP-side .recv( zmq.NOBLOCK )-s 或没有（没有人有任何形式的保证一个远程节点根本存在，同样，一个人必须让自己准备好预测和处理所有情况，远程方永远不会响应，所以从分布式多代理生态系统的性质出现了许多“新”挑战）。
有一些聪明的方法可以处理这种新型的分布式混乱和不确定性，最好使用.poll() 和.send() 和.recv() 方法的非阻塞形式，因为这些方法可以让用户编码仍然能够及时处理所有预期和意外事件。
一个人也可以操作相当多的共存 ZeroMQ 连接，以便在分布式系统设计中优先考虑和专门化多代理交互的每个和任何形式，即使在故障恢复和类似的高级设计中也是如此鲁棒性概念，其中每个交互的异步性质避免了与远程（甚至可能尚未存在）代理进行任何类型的协调或同步的需要，该代理主要是一个自治实体，拥有自己的控制域，所以再次，主要与本地代理可能“期望”的内容异步，任何其他形式的“影响”越小，而是尝试向“那里”发送消息“电报”。
对于（几乎）同步通信，人们可能会采取步骤和措施来减少（主要是分布式的）异步控制循环——最好用 MCVE 示例和详细信息来更新您的帖子要实现的特定目标。
【讨论】：