ZeroMQ 中的回复可以是可选的吗？

Question

我正在 ZeroMQ 中实现Lamport's distributed MUTEX algorithm。

算法：

请求过程

1 ) 将其请求推送到自己的队列中（按时间戳排序）
2 ) 向每个节点发送请求。
3 ) 等待所有其他节点的回复。
4 ) 如果自己的请求在其队列的头部并且已经收到所有回复，则进入临界区。
5 ) 退出临界区后，将其请求从队列中移除，并向每个进程发送释放消息。

其他进程

1 ) 收到请求后，将请求推送到自己的请求队列中（按时间戳排序），并以时间戳进行回复。
2 ) 收到release消息后，将对应的请求从自己的请求队列中移除。

我正在考虑用 C 或 Java 编写解决方案，但问题的核心似乎与语言无关。

在我的问题中，我有三种消息类型，我们称它们为Request、Reply 和Release。 Request/Reply 消息非常适合 REQ/REP 模式，但 Release 消息是单向信号，不需要回复。我可以添加一个额外的 PUB/SUB 对，但是，据我了解，我将无法保证系统中的 FIFO 交付顺序，因为我最终会拥有两个并发 TCP 连接（这个假设是否正确？）。

我可以使用基本的无约束全双工通道。另一个 answer 建议使用 DEALER/ROUTER 对，但对于这样一个简单的问题来说，这似乎有点过头了。在文档中，DEALER/ROUTER在Advanced Request-Reply Patterns一章中有所描述，我的问题似乎不需要极端的解决方案。

如何解决我的问题？

Answer 1

“回复在 ZeroMQ 中可以是可选的吗？”

短版：可以。

只要设置正确.setsockopt( zmq.REQ_RELAXED, 1 )

---

加长版：

如果分布式系统确实应该获得健壮性，那么对于已定义的问题还有更多的问题需要解决。 REQ/REP 不必陷入基本上无法挽救的相互死锁，因为分布式 FSA 是 .REQ_RELAXED 设置的捷径，但 ZeroMQ 不为消息传递提供保证。这是尽力而为的传递，因此如果需要保证消息传递，您需要实现更高级别的协议握手。 设置 .setsockopt( zmq.REQ_CORRELATE, 1 ) 可能会有所帮助。