ZeroMQ - 处理慢速接收器而不丢弃

Question

我有一个架构，其中有一个 ROUTER 套接字和多个 DEALER 套接字。

一些DEALER 套接字只会发送数据，一些只会接收数据，而另一些则可以混合使用两者。

我有一个场景，我有一个DEALER 套接字，它以极快的速度发送数据。此数据由另一个DEALER 接收，它将尽快处理此数据。发送速率总是高于接收速率。

在我当前的设置中，我的 ROUTER 套接字上的ZMQ_SNDHWM 被接收客户端命中，并且会静默丢弃消息。我不希望出现这种情况。

处理这种情况的最佳方法是什么？

我在不同的端口上查看了DEALER->DEALER，但这可能很难维护，具体取决于创建的会话数量，我可能每个会话必须有一个端口。

我能想到的解决这个问题的另一种方法是做一些流水线处理，其中接收的DEALER 套接字会告诉发送者它什么时候准备好接收，但这似乎给整个协议增加了很多复杂性以及更多的状态管理。它似乎也破坏了能够自然阻塞DEALER 套接字的能力，这正是我在这种情况下所需要的； DEALER 套接字永远不必与任何其他套接字通信。

Answer 1

不依赖阻塞，越不依赖资源不受控制的使用

在distributed-system 中，没有多少空间可以容纳乐观的信念和期望。在许多帖子中，我提倡尽可能不要依赖阻塞状态，因为您的代码会失控，并且您无法做任何事情来离开这种状态，但如果有的话，请祈祷消息很快就会到来。

宁可承担端到端的责任，这在distributed-system 中意味着您还需要设计策略如何在您的域范围之外的“远程”死亡和类似情况下生存 -不受控制，但您的代码设计无权从中抽象。

---

即使不愿意，明确的流程管理也是可行的方法

90 年代后期已经展示了许多分布式系统的流量控制策略，因此这绝对不是一个新领域。

增加蠕虫盒大小无助于管理不受控制/不受管理的事件流。虽然 ZMQ_???HMW + ZMQ_???BUF 可能有助于以某种方式调整非残酷的情况，其中有更多的空间可能会暂时推迟不受控制的消息流的主要弱点，但问题就像在交火射击中闭着眼睛静止不动。这样的代理可能会存活下来，但它的存活并不是因为它的设计巧妙，而是一种偶然的运气。

令牌传递似乎是限制流量以在最慢的节点上保持可接受/可处理的最便宜的方式。可以通过使用静态、增量扩展或完全自适应池代理来提高这种节点处理性能，因此即使这个已知的瓶颈仍然可以管理并在您的设计控制之下。

稳健性的最高层是使您的distributed-system 的设计能够抵御虚假突发事件（无论是消息还是.connect() 尝试）。因此，除了选择构建块之外，设计师还有责任设计所有的生存策略。不这样做会使您的系统容易受到容量导向的攻击向量或这些已知弱点漏洞的其他类型的未经处理的利用。