我必须开发一个消息总线，供进程相互发送和接收消息。目前，我们正在Linux上运行，并计划稍后移植到其他平台。
为此，我使用 TCP 上的 ZeroMQ。该模式是带有转发器的 PUB-SUB。我的总线作为一个单独的进程运行，所有客户端都连接到 SUB 端口来接收消息，并连接到 PUB 来发送消息。每个进程通过唯一的标签订阅消息。 Asend来自进程的调用向所有进程发送消息。 Areceive调用将获取该进程标记有该进程标签的消息。这工作正常。
现在我需要包装 ZeroMQ 的东西。我的客户只需要提供一个唯一的标签。我需要维护标签与 ZeroMQ 上下文和套接字详细信息的全局列表。当客户说，initialize_comms("name");总线需要检查该名称是否唯一，创建 ZeroMQ 上下文和套接字。同样，如果客户说receive("name");总线需要获取带有该标签的消息。
总结一下我面临的问题；
- 有没有办法使用 ZeroMQ 提供的设施来实现这一点？
- ZeroMQ 是正确的工具吗？还是我应该寻找像 nanomsg 这样的工具？
- 带有转发器的 PUB-SUB 是正确的模式吗？
- 或者，我在这里错过了什么吗？
Answers
-
Yes, ZeroMQ有能力满足这个需求
-
Yes. ZeroMQ是一个正确的工具（而是一个强大的低延迟组件工具箱）。尽管nanomsg具有直接的总线原语，核心分布式逻辑可以集成在ZeroMQ框架
-
是与否。上面给出的 PUB-SUB 可以用于模拟“喊叫广播”到总线并建立在使用订阅密钥的 SUB 副作用之上。整个逻辑的其余部分必须重新思考和设计，以便整个制造范围满足您的计划（参考下文）。另请记住，ZeroMQ 的初始版本将 PUB/SUB 原语操作为在接收方完成的传入消息流的“订阅过滤”，因此大规模设计应检查大规模的交通量/洪水风险/流程效率低下......
-
Yes. ZeroMQ而是一个经过良好调整的原始元素基础（就架构而言，而不是其功能和性能），以构建更聪明、更健壮且几乎可线性扩展的正式通信模式。绘制架构草图后，不要陷入 PUB/SUB 或 PAIR 基元。如果人们忘记了设计的初衷在哪里，那么任何设计都会很糟糕。真正的力量来自。
一个向可扩展和容错总线迈出下一步的好地方
因此，下一步可能要做的最好的一步是恕我直言，获得更多的全局视图，这对于尝试使用 ZeroMQ 进行编码的前几件事来说可能听起来很复杂，但是如果您至少跳到265页 https://hintjens.wdfiles.com/local--files/main:files/cc1pe.pdf of the 代码连接，第 1 卷 https://hintjens.wdfiles.com/local--files/main:files/cc1pe.pdf，如果不是逐步阅读的情况。
有史以来最快的学习曲线将是首先对事物有一个不公开的看法Fig.60 重新发布更新 and Fig.62 HA 克隆服务器对可实现可能的高可用性方法然后回到根源、元素和细节。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
