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