我的架构中有一个 ROUTER 套接字和多个 DEALER 套接字。
有些DEALER套接字只会发送数据，有些只接收数据，有些则可以混合使用。
我有一个场景，我有一个DEALER套接字，它以极快的速度发送数据。此数据由另一个DEALER接收，它将尽可能快地处理此数据。发送速率总是高于接收速率。
在我当前的设置中， ZMQ_SNDHWM 套接字上的ROUTER会被接收客户端点击，并会以静默方式丢弃消息。我不希望情况如此。
处理这种情况的最佳方法是什么？
我在另一个端口上查看了DEALER->DEALER，但这可能很难维护，具体取决于创建的会话数量，每个会话可能需要一个端口。
我能想到解决这个问题的另一种方法是做一些管道接收，其中接收DEALER套接字将告诉发送方它何时可以接收但这似乎增加了很多复杂性整体协议和更多的状态管理。它似乎也失败了能够自然阻挡DEALER插座的能力，这在我的情况下确实是我需要的; DEALER套接字永远不必与任何其他套接字通信。
答案 0 :(得分：1)
在distributed-system中，乐观的信念和期望没有多少空间。在很多帖子中，我提倡，在可能的情况下，不要依赖阻塞状态，因为你的代码失控，你不能做任何关于离开这样一个状态的事情，但是如果有的话，祈祷很快就会有消息传来。
相反承担责任，端到端，distributed-system意味着您还需要设计策略如何在“远程”死亡和类似情况中生存，这些情况超出了您的范围 - 控制域，但您的代码设计无权从中抽象出来。
90年代后期已经为分布式系统展示了许多流量控制策略，所以这绝对不是一个新领域。
增加蠕虫盒大小无助于管理未受控制/未受管理的事件流。虽然 ZMQ_???HMW + ZMQ_???BUF 可能会以某种方式帮助调整非残酷案件，但是如果有更多空间可能会暂时推迟未来的主要弱点受控制的消息流，但问题就像是在交火射击中间闭着眼睛保持静止。这样的特工可能存活下来，但它的生存不是因为它的设计聪明，而是偶然的运气。
令牌传递似乎是如何限制流量以便在最慢的节点上保持可接受/可处理的最便宜的方式。增加这样的节点处理性能可以通过使用静态，递增扩展或完全自适应池代理来完成，因此即使这个已知的瓶颈仍然可以管理并且在您的设计控制之下。
最高层的稳健性在于使distributed-system的设计能够适应虚假的突发事件（无论是消息还是.connect()次尝试）。因此，设计师无需选择构建模块，也有责任在所有生存策略中进行设计。不这样做会使您的系统容易受到容量导向的攻击向量或其他未处理的漏洞利用漏洞的攻击。</ p>