消息总线与组播

我正在开发一个由几个模块组成的应用程序，要求它们彼此共享信息。示例：发布/订阅场景，其中模块发布一些信息（例如状态变量），并且对特定信息感兴趣的模块将其获取。或者是一个请求/答复场景，感兴趣的模块会明确询问有关信息并得到答复。

我一直在研究不同的消息总线实现，即D-bus，ØMQ，RabbitMQ和QPID（后两者基于AMQP）。但是后来有人指出，为什么不尝试使用一些复杂而繁重的消息总线实现，我为什么不简单地使用多播来解决问题。

缺乏经验来查看多播是否真的可以解决我的问题，并了解这两种解决方案的优缺点，因此，我恳请专家帮助我。非常感谢。

我有在大型，大量生产环境中同时使用消息总线和多播的经验，并与几位经验丰富的网络工程师就这些问题进行了交谈，我可以说，除非广播到非常多的广播电台，否则应避免像瘟疫一样多播。节点（数百个）。

如果要使用多播，则必须了解它是不可靠的协议。邮件可能会丢失，可以重复，等等。您需要花费大量时间来在多播之上获取可靠性协议（重试，重复检测，重新发送），以使其有用。有一个很好的轶事，关于我正在尝试寻找多播命令机器人坦克的陆军测试标准...基本上，当您向一系列坦克发送“向右转90度，向右转90度，开火”时，其中一些仅收到右转消息，而其他一些则收到3，这是混乱的秘诀。

根据您需要共享的信息种类，有几种选择。

如果他们共享配置信息，请查看类似于Zookeeper的信息。它可靠，轻巧且易于使用。共享状态的最新值始终可用并保持不变。使用消息总线，您仍然需要具有重新发送协议，以防模块由于故障而错过上一个配置消息。

关于消息总线，它们可能很复杂。但是，我不必将ZeroMQ放在该类别中。它可以模拟消息总线，但是更多的是点对点机制。我没有在生产中使用它，但是我进行的研究和原型制作非常有利。

另一个选择可能是分布式数据网格，例如Oracle Coherence，GridGain，GigaSpaces等。同样，这是另一个要安装和维护的应用程序，因此您的复杂性增加了，但是数据网格有很多用途。

另一个MQ选项是HornetMQ。我没有使用过它（我们内部使用了两个商业的MQ，即Sonic和MQ系列），但是我看到了一些有利的比较。

D-Bus似乎已针对单台机器上的通信进行了优化，如果您正在进行对等，群集或其他类似操作，则FAQ建议您在其他地方查找。警告：我从未使用过D-Bus，所以我基本上是在反省我刚刚阅读的信息。