Brokered与非代理消息系统的优缺点
Joe*_*Joe 11 architecture message-queue
我正在尝试设计一个模块化的实时监控系统,因此可以为不同的硬件和网络进行分布,扩展/重新配置.
我很快得出结论,我需要某种分布式企业消息系统.但是有很多选择,每个选项都有优点和缺点,其中一些选项决定了不同的架构.我正在努力弄清楚我是否需要经纪人或无代理系统,我是否需要某些系统的消息可靠性(例如RabbitMQ)或者像ZeroMQ这样的系统的轻量级高吞吐量,或者"按顺序到达"卡夫卡的高吞吐量.
首先,这些架构是否有意义？
ZeroMQ类型"Brokerless"系统:
笔记:
每个"B部分"可以有许多"A部分",许多"B部分"进入"C部分"
好处:
- 高吞吐量,低出租率
- 轻松集成到组件中,轻量级部署(无需部署代理).
缺点
- 邮件无法保证送达.有些可能会掉线.这可能是橙色突出显示区域中的问题.它对GUI来说并不重要,但如果本地控制模块正在做决定,它可能需要所有信息.(考虑到这一点,只是最新的可能就足够了 - 没有必要用过时的数据做出决定).同样,如果A和B之间的网络出现故障,则历史记录将具有不完整的历史记录.这有多重要啊？
- 没有"发现".需要更多地管理组件之间的关系.
RabbitMQ类型Broker系统:
好处:
- 邮件保证交付.
- 发现通过经纪人管理.
缺点
- 慢得多,高延迟
- 更多部署和维护(经纪人/ RabbitMQ需要在机器上安装,它不仅仅是内置于模块中)
中间选项:
我看过卡夫卡.这是经纪人,因此发现得到了解决.然而,它似乎比RabbitMQ更轻量级,虽然它不保证交付(因此更快/更低的延迟)它确实维持秩序,RabbitMQ没有.它还可以缓冲消息 - 因此,如果出现网络问题,可以检索它们.
写下来之后,我不确定保证交付的重要性.如果控制模块收到消息,如果它是"旧"则无关紧要.如果历史学家有完整的历史,那将是伟大的 - 但它是否必不可少？
在ZeroMQ中实现我自己的"消息缓冲区"可能是一种选择,用于在发生故障时存储消息的网络通信.我有比RabbitMQ更多的控制权,并且可以在我需要它时通过更不可靠(通过网络)进行消息传递时实现它.
显然,权衡这些优点或缺点是我的工作.我的问题是:还有什么需要考虑的吗？并且确实为这两个选项的结构是否合理？
我计划将大多数实现都放在C#中,而且我目前在消息传递系统方面没有经验.
可靠性可能意味着不同的事情。zmq 的这个链接可能是我读过的最好的链接之一。但这里简要说明在发生硬件故障时的可靠性
Apache Kafka - 消息传递保证可能意味着不同的事情。请参阅消息传递语义。需要注意的是"Kafka's semantics are straight-forward. When publishing a message we have a notion of the message being "committed" to the log. Once a published message is committed it will not be lost as long as one broker that replicates the partition to which this message was written remains "alive". "
RabbitMQ 也提供了一些选项。阅读有关集群和 HA 的信息。但我个人认为 Apache Kafka 本质上（按设计）是一个分布式、分区、复制的提交日志服务，因此以更简洁的方式解决了这个问题。
ZMQ我对 zmq 的了解不够，无法做出明智的结论。但我认为 zmq 并没有试图解决可靠性问题。相反，它embeddable networking library为高性能、可扩展的集群应用程序提供了一个基础，以便通过消息相互交互。但是，据我所知，它并没有特别解决可靠地持久化消息（作为代理）的问题。Apache Kafka 似乎很好地填补了这一领域——它的性能非常好，但提供了实现可靠性的选项。
结论：我认为可靠性不仅仅是经纪人的责任。相反，它是构成您的应用程序的所有部分的集体责任。只有通过良好的设计和使用正确的技术才能实现可靠性、性能和可扩展性。