如何限制与ZeroMQ发布者端点的总并发订阅者连接？

Question

在Linux系统上使用ZeroMQ构建pub-sub服务时，有没有办法强制实施并发用户限制？

例如，我可能想在资源有限的系统上创建ZeroMQ发布服务，并希望通过设置与tcp发布者端点的100个并发连接的限制来防止系统过载。达到该限制后，ZeroMQ订户的所有后续连接尝试都将失败。

我知道ZeroMQ没有提供有关连接/断开连接的通知，但我一直在寻找可能允许此类限制的套接字选项 - 到目前为止，没有运气。

或者这是否应该在其他级别处理，可能在协议内？

Answer 1

是的，ZeroMQ是一个Can-Do消息传递框架：

除了琐碎的形式通信模式框架元素（库原语）之外，ZeroMQ背后最强大的能力是开发自己的消息系统的能力。

在你的情况下，它足以通过一些额外的东西丰富场景...... SUB -process - ＆gt; PUB -process message-flow-channel ，以便允许PUB - 侧进程计算一些 {{1并行连接的进程实例 - 允许断开连接（将步骤委托给“ SUB - 进程端的suicide移动”，作为经典 SUB -process，故意无需管理订阅的工具。另外，为节点间信令添加一些动态，以开始重新计数和/或为 PUB - 进程侧配备自我广告机制来推送keepAliveSIG- s到SUB - 并且期望这个信令是一个弱且仅提供信息的指示，因为存在许多真实世界的冲突，其中分散的节点根本无法传递“保证传递”消息和一个设计良好，分布式，低延迟，高性能的系统必须很好地应对这一现实，并将自我修复状态恢复策略设计和内置于自己的行为中。

（图片由imatix / ZeroMQ提供）

请假设ZeroMQ库是用于设计酷分布式系统的非常强大的LEGO工具箱，而不是现成的/包含电池的，僵硬的，准<强大的>解决方案 - 只是为了少数学术案例（好吧，它可能被认为是这样，但只是为了一些不用脑子的生活，而我们的生活更加丰富多彩。戏弄，不是吗？）

那么，“怎么样？”

值得，绝对值得花几天时间阅读Pieter Hintjens的书籍和书籍。几个星期的时间让我们开始设计ZeroMQ全功率的设计。

只需几个python附加习惯（PUB早期设置，并且不会忘记 zmq.Context() finally:）

你一定会喜欢这个聪明的世界。

Answer 2

我无法通过配置 ZMQ来自动限制连接...但是，您还有其他选择可以完成您正在寻找的内容对于。也许＆＃34;传统＆＃34;实现这一目标的方法是使用第二套网络通信＆＃34;套接字......从订阅者到发布者可能是REQ/REP，要求获得连接权限。

您也可以选择，具体取决于您的ZMQ版本（我从未使用过它，我在5分钟的搜索时间内找不到它，所以我不知道最近的情况您的版本必须是）使用XPUB/XSUB套接字，可以完成双向通信。您可以与XSUB连接，发送订阅请求，然后收到肯定或否定响应（您可能必须使用您的订阅者主题直接与单个订户进行通信，我不确定），并做出相应的反应。

无论哪种方式，您都允许在两个系统之间进行某种连接，然后根据情况允许或终止它。这可能不是完全理想的，因为你必须花费一点开销来处理你拒绝的连接......让我们说你在100个客户端已经饱和了突然得到100个新的订阅请求......你可能会或者可能无法应对那种突发流量。

您可以测试其他通信媒介中的开销......就像您可以发布一个Web服务，该服务指示客户端可以首先检查的订户状态，但是让客户端以这种方式连接可能不会更好。

如果您完全处于资源限制之下，则必须设置第二台服务器来处理订阅者状态：

• 服务器1是您的发布商。您可以使用PUB套接字和REP套接字进行设置。
• 服务器2是您的状态服务器。它有一个REQ套接字。让它订阅像＆＃34; system-status＆＃34;或者某些这样的事情。它还具有与新订户进行通信的机制，可以是ZMQ套接字或Web服务或其他任何用户。
• 客户端将从您的状态服务器请求状态。状态服务器将向您的发布者发送请求，该请求将增加其订阅者数量并成功回复，或保持其订阅者计数并以失败回复。此成功或失败将传达回订户，订户将使用该信息进行连接或不连接。
• 必须以类似的方式传达断开连接......并且您必须使用某种心跳循环来确认客户不是灾难性故障的受害者。

这样，您的发布商就可以自行选择是否有资源。如果您只想设置一个静态编号，您甚至不需要状态服务器和发布者之间的连接，您可以只依靠状态服务器......但只是为了确保网络的整体健康状况那么最好不要采用那种简单化的路线。

无论如何，这些只是一些想法来实现你正在寻找的东西。与实际解决方案相比，ZMQ为您提供了制作解决方案的选项。