文章摘要：本篇文章为RabbitMQ的入门文章，不像其他一些程序代码和应用实战性的文章会带着大家从一个“Hello World”的简单例子出发，在该篇幅中主要给大家讲下RabbitMQ消息队列的起源、为何要选择该款组件、几个主要的功能特性，让大家对该款消息队列组件有一个大概的认识
在说RabbitMQ之前有必要先来介绍下AMQP协议。AMQP，即Advanced Message Queuing Protocol，高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。
那么再来介绍下RabbitMQ本身。RabbitMQ是一个上面说的AMQP协议的开源实现，其服务器端用Erlang语言写的，支持多种客户端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。该消息队列主要用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。
一、为何要选型RabbitMQ
（1）RabbitMQ本身安装部署（单实例/集群）均较为简单，上手门槛低，功能丰富，符合AMQP标准；
（2）RabbitMQ的集群易于扩缩，可以根据实际的业务访问量，通过增减集群中节点实例的方式，达到弹性扩容、缩小的效果；
（3）企业级消息队列中间件，经过业界各个公司生产环境大量实践案例的验证，具有较高的可靠性；
（4）提供各种插件，比如RabbitMQ Management插件提供友好的Web页面管理；
（5）除了Web页面可以对RabbitMQ的单实例和集群的各种参数（Exchanges/Queues/Connections等）进行监控以外，其还提供Http的Api接口/JMX接口可以方便用户根据业务需求进行各种自定义的MQ级监控；
（6）支持消息持久化、支持消息确认机制、灵活的任务分发机制等，支持功能非常丰富；
（7）实现高可用性，可以在RabbitMQ集群中的机器上创建队列的镜像，使得在部分节点出问题的情况下队列仍然可用；此外，其warren和Shovel模式，可以实现故障转移能力和跨数据中心的异地复制；
二、RabbitMQ应用场景下的架构图
对于一般的童鞋来说，都是以自己用RabbitMQ消息队列为目标的（后面篇幅会对RabbitMQ产品云化的系统架构图加以详细描述），下面给出了RabbitMQ应用场景的系统架构图：
三、RabbitMQ消息队列基本概念
（1）RabbitMQ Server：也可以称为RabbitMQ Broker Server，其维护一条从Producer到Consumer的路线（Connection），保证数据能够按照指定的方式进行传输。
（2）Virtual Host虚拟主机，表示一批交换器、消息队列和相关对象的容器。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。每个 vhost 本质上就是一个 mini 版的 RabbitMQ 服务器，拥有自己的队列、交换器、绑定和权限机制（相当于是虚拟机和物理机的概念，可以起到租户用户隔离）。vhost 是 AMQP 概念的基础，必须在连接时指定，RabbitMQ 默认的 vhost 是 “/”；
（3）Connection： 连接，Producer和Consumer都是通过TCP连接到RabbitMQ Server的。一般我们会看到，在我们业务代码的起始为止就是建立这个TCP连接。
（4）Channels： 信道，它建立在上述的TCP连接中。数据流动都是在Channel中进行的。也就是说，代码开始处第一步是先建立TCP连接（上面（2）步骤），第二步就是建立这个Channel。
（5）Exchange：消息的生产者将消息发送到Exchange（交换器），由Exchange将消息路由到一个或多个Queue中（或者丢弃）。Exchange并不存储消息。RabbitMQ中的Exchange有fanout、direct、topic、headers四种类型，每种类型对应不同的路由规则。其中，headers 匹配 AMQP 消息的 header 而不是路由键，此外 headers 交换器和 direct 交换器完全一致，但性能差很多，目前几乎用不到了，所以一般在业务应用中只需要关注其他三种类型即可：
a.direct:消息中的路由键（routing key）如果和 Binding 中的 binding key 一致， 交换器就将消息发到对应的队列中。路由键与队列名完全匹配，如果一个队列绑定到交换机要求路由键为“dog”，则只转发 routing key 标记为“dog”的消息，不会转发“dog.puppy”，也不会转发“dog.guard”等等。它是完全匹配、单播的模式;
b.fanout:每个发到 fanout 类型交换器的消息都会分到所有绑定的队列上去。fanout 交换器不处理路由键，只是简单的将队列绑定到交换器上，每个发送到交换器的消息都会被转发到与该交换器绑定的所有队列上。很像子网广播，每台子网内的主机都获得了一份复制的消息。fanout 类型转发消息是最快的;
c.topic:交换器通过模式匹配分配消息的路由键属性，将路由键和某个模式进行匹配，此时队列需要绑定到一个模式上。它将路由键和绑定键的字符串切分成单词，这些单词之间用点隔开。它同样也会识别两个通配符：符号“#”和符号“”。#匹配0个或多个单词，匹配不多不少一个单词;
（6）Queue：队列，其为RabbitMQ的内部对象，用于存储消息。消息消费者就是通过订阅队列来获取消息的，RabbitMQ中的消息都只能存储在Queue中，生产者生产消息并最终投递到Queue中，消费者可以从Queue中获取消息并消费。多个消费者可以订阅同一个Queue，这时Queue中的消息会被平均分摊给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理。
（7）RoutingKey：生产者在将消息发送给Exchange的时候，一般会指定一个routing key，用于指定这个消息的路由规则。而这个routing key需要与Exchange Type及binding key联合使用才能最终生效。在Exchange Type与binding key固定的情况下（在正常使用时一般这些内容都是固定配置好的），我们的生产者就可以在发送消息给Exchange时，通过指定routing key来决定消息流向哪里。RabbitMQ为routing key设定的长度限制为255 bytes。
四、结论
看完以上对于RabbitMQ的特点描述即可知道，该款消息队列中间件主要考虑的是高可靠性、功能强大、易于管理，对于消息队列的吞吐量、消息积压、并发性能等特点都与Kafka这种适用于大数据、流计算处理、日志收集的消息队列组件（在特定场景下，比如日志收集，及时有消息丢失也能容忍的）有着不小的差距。个人觉得谁是最好的消息组件这个命题没有一个完整的结论，选择适合自己使用和业务需求的就行了。
