我正在开发一个由多个模块组成的应用程序，并要求它们相互共享信息。示例：发布/订阅场景，其中模块发布一些信息（例如状态变量），并且对特定信息感兴趣的模块获取它。或请求/回复场景，其中感兴趣的模块明确询问信息并得到答案。
我一直在研究不同的消息总线实现，即 D-bus ，ØMQ， RabbitMQ 和 QPID （后两者基于AMQP）。然而，有人指出，为什么我不使用多播来解决问题，而不是尝试一些复杂而繁重的消息总线实现。
缺乏体验，看多播能否真正解决我的问题，并了解这两个解决方案的优缺点，我请求专家帮助我。非常感谢。
答案 0 :(得分：5)
在大型，大批量生产环境中拥有消息总线和多播的经验，并与几位经验丰富的网络工程师讨论过这些问题，我可以说你应该避免像瘟疫这样的多播，除非你正在广播大量节点（数百个）。
如果你打算使用多播，你必须明白它是一个不可靠的协议。消息可能会丢失，可能会重复，等等。您需要花费大量时间在多播之上获取可靠性协议（重试，重复检测，重新发送），以使其有用。有一个很好的轶事，关于多播命令机器人坦克的军队测试，我正试图找到参考...基本上当你发送“右转90度，右转90度，火”到一排坦克其中一些只收到1个右转信息，其他人收到3个，这是混乱的秘诀。
根据您需要分享的信息种类，有几种选择。
如果他们正在共享配置信息，请查看Zookeeper之类的内容。它可靠，轻便，易于使用。共享状态的最新值始终可用并保持不变。使用消息总线，您仍需要重新发送协议，以防模块因丢失而丢失最后一条配置消息。
对于消息总线，它们可能很复杂。但是，我不会将ZeroMQ置于该类别中。它可以模拟消息总线，但它更像是一种点对点机制。我没有在生产中使用它，但我用它完成的研究和原型设计非常有利。
另一种选择可能是分布式数据网格，如Oracle Coherence，GridGain，GigaSpaces等。同样，这是另一个安装和维护的应用程序，因此您的复杂性也在增加，但数据网格有很多用途。
另一个MQ选项是HornetMQ。我没有使用它（我们在内部使用两个商用MQ，Sonic和MQ系列），但我看到了一些有利的比较。
D-Bus似乎针对单台机器上的通信进行了优化，如果你正在进行点对点，集群或其他类似的事情，FAQ建议寻找其他地方。警告：我从来没有使用过D-Bus，所以我基本上反复阅读的信息。
答案 1 :(得分：1)
您是否担心数据包/邮件被丢弃或丢失？消息总线可以处理或缓解这些问题，而默认情况下不会进行多播。