这可能看起来像一个愚蠢的问题，但我对ZeroMQ关于REQ and REP等同步套接字的术语感到很困惑。
根据我的理解，当客户端发送消息然后它阻塞时发生同步通信，直到响应到达。如果ZeroMQ实现了同步通信，那么只有.send()方法对于同步套接字就足够了。
我认为ZeroMQ的同步套接字术语仅指在最后一条消息的响应到来之前无法发送更多消息，但“发送者”仍然可以异步地继续处理（做更多的事情）。
这是真的？
在这种情况下，有没有直接的方法来使用ZeroMQ实现同步通信？
编辑：当我想在远程进程（如RPC）中调用方法时，同步通信是有意义的。如果我想在远程进程中执行一系列命令，并且每个命令都需要前一个命令的结果来完成其工作，那么异步通信不是最佳选择。
要使用ZMQ实现同步框架，您几乎可以使用ZMQ来完成它;你可以将高水位标记设为1.不幸的是，它并不完全;你想要的是一个外出队列长度为0.更不幸的是，将高水位标记设置为0被ZMQ解释为无限...
因此，唯一的选择是在ZMQ之上实现同步传输协议。这不是很难做到的。两端之间的对话将是“我可以发送吗？”，“是的，你现在可以发送”，“好在这里”，“好的，我已收到它”（两端都返回来电）（或至少程序版本）。这设置了所谓的执行渲染 - 两端都知道它们都达到了某个执行点。
从技术上讲，你正在做的是采用ZeroMQ（演员模型）并将其变成更像是沟通顺序进程的东西。
RPC
说了这么多，从你的编辑我认为你可能会考虑Cap'n Proto。这是一个C ++序列化技术，有一个巧妙的RPC技巧。如果从一个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示例最好地更新您的帖子，并详细说明您实现的特定目标是什么。