使用ZeroMQ实现消息总线 [英] Implementing a message bus using ZeroMQ
问题描述
我必须开发一条消息总线，以使进程相互发送，接收消息.当前，我们正在Linux上运行，以期稍后移植到其他平台.
I have to develop a message bus for processes to send, receive messages from each other. Currently, we are running on Linux with the view of porting to other platforms later.
为此，我使用基于TCP的ZeroMQ.模式是带有转发器的PUB-SUB.我的总线是作为一个单独的进程运行的，所有客户端都连接到SUB端口以接收消息，而PUB则发送消息.每个进程都通过唯一的标签订阅消息.来自进程的send调用将消息发送给所有人. receive调用将获取处理该进程的标记有该进程的标记的消息.一切正常.
For this, I am using ZeroMQ over TCP. The pattern is PUB-SUB with a forwarder. My bus runs as a separate process and all clients connect to SUB port to receive messages and PUB to send messages. Each process subscribes to messages by a unique tag. A send call from a process sends messages to all. A receive call will fetch that process the messages marked with the tag of that process. This is working fine.
现在我需要包装ZeroMQ的东西.我的客户只需要提供一个唯一的标签.我需要维护一个全局标签列表以及ZeroMQ上下文和套接字详细信息.当客户说
initialize_comms("name");总线需要检查该名称是否唯一，创建ZeroMQ上下文和套接字.同样，如果客户说receive("name");，则总线需要提取带有该标签的消息.
Now I need to wrap the ZeroMQ stuff. My clients only need to supply a unique tag. I need to maintain a global list of tags vs. ZeroMQ context and sockets details. When a client say,
initialize_comms("name"); the bus needs to check if this name is unique, create ZeroMQ contexts and sockets. Similarly, if a client say receive("name"); the bus needs to fetch messages with that tag.
总结我面临的问题；
- 是否有使用ZeroMQ提供的功能来实现这一目标?
- ZeroMQ是否是正确的工具，还是应该寻找nanomsg之类的东西?
- 具有转发器的PUB-SUB是否适合此模式?
- 或者，我在这里想念什么吗?
推荐答案
答案
-
是，
ZeroMQ能够满足这一需求
是.为此，ZeroMQ是一个正确的工具(而不是功能强大的低延迟组件工具箱).虽然nanomsg具有直接的总线原语，但核心分布式逻辑可以集成在ZeroMQ框架中
Yes. ZeroMQ is a right tool ( rather a powerfull tool-box of low-latency components ) for this. While nanomsg has a straight primitive for bus, the core distributed logic can be integrated in ZeroMQ framework
是&否.如上面给出的PUB-SUB可以用于仿真向总线广播"，并且建立在使用订阅密钥的SUB副作用上.必须重新考虑和设计逻辑的REST，以使整个制造范围符合您的计划(请参阅下面的内容).还请记住，ZeroMQ的初始版本将PUB/SUB原语作为在接收方完成的传入消息流的订阅过滤"，因此大规模设计应检查业务量/洪水/过程效率低下...
Yes & No. PUB-SUB as given above may serve for emulation of the "shout-cast"-to-bus and build on a SUB side-effect of using a subscription key(s). The WHOLE REST of the logic has to be re-thought and designed so as the whole scope of the fabrication meets your plans (ref. below). Also kindly bear in mind, that initial versions of ZeroMQ operated PUB/SUB primitive as "subscription filtering" of the incoming stream of messages being done on receiver side, so massive designs shall check against traffic-volumes / risk-of-flooding / process-inefficiency on the massive scale...
是. ZeroMQ是原始元素的调优基础(就讨论的体系结构而言，不是其功能和性能)，以构建更聪明，更健壮和更强大的功能.几乎线性可缩放的形式交流模式.一旦绘制了架构草图，就不要卡在PUB/SUB或PAIR基元上. 如果忘记了真正力量的来源，那么任何设计都将仍然很糟糕.
Yes. ZeroMQ is rather a well-tuned foundation of primitive elements ( as far as the architecture is discussed, not the power & performance thereof ) to build more clever, more robust & almost-linearly-scaleable Formal Communication Pattern(s). Do not get stuck to PUB/SUB or PAIR primitives once sketching Architecture. Any design will remain poor if one forgets where the True Powers comes from.
是迈向可扩展&扩展的下一步的好地方故障容错总线
因此，下一步可能要做的最好的办法就是恕我直言，以获取更多的全局视图，这对于尝试使用ZeroMQ进行编码的前几件事可能听起来很复杂，但是如果您 [已连接代码，第1卷] [可作为aspdf >>> http://hintjens.wdfiles.com/local--files/main%3Afiles/cc1pe.pdf]
Thus a best next step one may do is IMHO to get a bit more global view, which may sound complicated for the first few things one tries to code with ZeroMQ, but if you at least jump to the page 265 of the [Code Connected, Volume 1] [available asPdf >>> http://hintjens.wdfiles.com/local--files/main%3Afiles/cc1pe.pdf ], if it were not the case of reading step-by-step thereto.
有史以来最快的学习曲线是首先在图60 重新发布更新和图62 上拥有一个未公开的视图. strong> HA克隆服务器对以寻求一种可能的高可用性方法，然后返回其根源，元素和详细信息.
The fastest-ever learning-curve would be to have first an un-exposed view on the Fig.60 Republishing Updates and Fig.62 HA Clone Server pair for a possible High-availability approach and then go back to the roots, elements and details.
这篇关于使用ZeroMQ实现消息总线的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
