人们如何做出决定?在日常生活中,情绪往往是第一动力。但当人们需要承担长期后果时,不可能纯靠冲动行事。聪明者只会在心里有数后才会靠直觉做出决定。
如今市场上有数十种发送消息的技术,无数ESB和近100家iPaaS供应商。当然,如何挑选就成为了一个问题。需要批发一堆技术吗?还是对症下药?那么,正确的工具应该是什么?
这篇文章正是想给那些“无头苍蝇”们一些简单直接的建议,就从如今最时尚最受欢迎的RabbitMQ开始吧!两者都有自己的起源故事,设计意图,闪光点,集成功能和开发人员的切身体验。起源揭示了本软件的整体设计意图o。重要的是,本文中的目的是比较两者围绕消息中介的重叠用例,而不是Kafka擅长的“事件存储/事件源”用例。
起源
RabbitMQ是一个“传统”消息中介,可以实现各种消息传递协议。它是首批实现大量功能,客户端库,开发工具和质量文档的开源消息中介之一。RabbitMQ最初是为实现开放式线路协议AMQP而开发的。虽然Java具有像JMS这样的消息传递标准,但它对于需要分布式消息传递的非Java应用程序没有帮助,因为它严重限制了集成场景,微服务。随着AMQP的出现,跨语言的灵活性成为开源消息中介的真实存在。
建筑与设计
RabbitMQ作为通用的消息中介,采用点对点的方式,请求/回复各类通信样式。它使用智能中介/ “沉默的消费者”模型,专注于向消费者提供一致的消息传递,消费者的消费速度与中介跟踪消费者状态的速度大致相似。RabbitMQ是成熟的,在得到正确配置时表现良好,得到很多支持(客户端库Java,.NET,node.js,Ruby,PHP和更多语言),并且有许多可用的插件可以将它扩展到更多的用例和集成场景。
RabbitMQ中的通信可以根据需要同步或异步。发布者向中间站发送消息,消费者从队列中检索消息。通过交换将生产者与队列分离,可确保生产者不会受到硬编码决策的影响。RabbitMQ还提供了许多分布式部署方案(并且确切要求所有节点都能够解析主机名)。可以将多节点群集设置为群集联合,并且不依赖于外部服务(但某些群集形成插件可以使用AWS API,DNS,Consul等)。
要求和用例
RabbitMQ是一种通用的消息传递解决方案,通常用于允许Web服务器快速响应请求,而不是在用户等待结果时强制执行复杂的过程。它还可以将消息分发给多个接收者以供消费,或者在高负载(20k + / sec)下平衡负载。当您的需求超出吞吐量时,RabbitMQ可提供许多功能:可靠的交付,路由,联合,HA,安全性,管理工具和其他功能。让我们来看看RabbitMQ的最佳场景,例如:
- 您的应用程序需要使用现有协议的任意组合,如AMQP 0-9-1,STOMP,MQTT,AMQP 1.0。
- 您需要基于每个消息(死信队列等)进行更精细的一致性控制/保证。但是,Kafka最近添加了更优的支持。
- 您的应用程序需要点对点,请求/回复、发布/订阅,具有消息传递的多样性
- 至消费者复杂的路由,使用强大的路由逻辑集成多个服务/应用程序
- 在其他软件的帮助下,RabbitMQ还可以有效地解决上面几个Kafka强大的用例。当应用程序需要访问流历史时,RabbitMQ通常与Apache Cassandra一起使用,对于需要“无限”队列的应用程序,RabbitMQ通常与LevelDB插件一起使用,但这两种功能都不附带RabbitMQ本身。
开发经验
RabbitMQ正式支持Java,Spring,.NET,PHP,Python,Ruby,JavaScript,Go,Elixir,Objective-C,Swift - 通过社区插件与许多其他客户端的devtools一起支持。RabbitMQ客户端库已经成熟并且文档齐全。