了解何时使用RabbitMQ

人们如何做出决定？在日常生活中，情绪往往是第一动力。但当人们需要承担长期后果时，不可能纯靠冲动行事。聪明者只会在心里有数后才会靠直觉做出决定。

如今市场上有数十种发送消息的技术，无数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的最佳场景，例如：

1. 您的应用程序需要使用现有协议的任意组合，如AMQP 0-9-1，STOMP，MQTT，AMQP 1.0。
2. 您需要基于每个消息（死信队列等）进行更精细的一致性控制/保证。但是，Kafka最近添加了更优的支持。
3. 您的应用程序需要点对点，请求/回复、发布/订阅，具有消息传递的多样性
4. 至消费者复杂的路由，使用强大的路由逻辑集成多个服务/应用程序
5. 在其他软件的帮助下，RabbitMQ还可以有效地解决上面几个Kafka强大的用例。当应用程序需要访问流历史时，RabbitMQ通常与Apache Cassandra一起使用，对于需要“无限”队列的应用程序，RabbitMQ通常与LevelDB插件一起使用，但这两种功能都不附带RabbitMQ本身。

开发经验

RabbitMQ正式支持Java，Spring，.NET，PHP，Python，Ruby，JavaScript，Go，Elixir，Objective-C，Swift - 通过社区插件与许多其他客户端的devtools一起支持。RabbitMQ客户端库已经成熟并且文档齐全。