最全面透彻的RabbitMQ指南
概念
RabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件（亦称面向消息的中间件）。RabbitMQ服务器是用Erlang语言编写的，而集群和故障转移是构建在开放电信平台框架上的。所有主要的编程语言均有与代理接口通讯的客户端库。
RabbitMQ是一套开源（MPL）的消息队列服务软件，是由 LShift 提供的一个 Advanced Message Queuing Protocol (AMQP) 的开源实现，由以高性能、健壮以及可伸缩性出名的 Erlang 写成。
AMQP
AMQP 其实和Http一样 都是一种协议， 只不过 Http是针对网络传输的， 而AMQP是基于消息队列的
AMQP 协议中的基本概念
**Broker: **
接收和分发消息的应用，我们在介绍消息中间件的时候所说的消息系统就是Message Broker。
**Virtual host: **
出于多租户和安全因素设计的，把AMQP的基本组件划分到一个虚拟的分组中，类似于网络中的namespace概念。当多个不同的用户使用同一个RabbitMQ server提供的服务时，可以划分出多个vhost，每个用户在自己的vhost创建exchange／queue等。
「Connection:」
publisher／consumer和broker之间的TCP连接。断开连接的操作只会在client端进行，Broker不会断开连接，除非出现网络故障或broker服务出现问题。
**Channel: **
如果每一次访问RabbitMQ都建立一个Connection，在消息量大的时候建立TCP Connection的开销将是巨大的，效率也较低。Channel是在connection内部建立的逻辑连接，如果应用程序支持多线程，通常每个thread创建单独的channel进行通讯，AMQP method包含了channel id帮助客户端和message broker识别channel，所以channel之间是完全隔离的。Channel作为轻量级的Connection极大减少了操作系统建立TCP connection的开销。
「Exchange:」
message到达broker的第一站，根据分发规则，匹配查询表中的routing key，分发消息到queue中去。常用的类型有：direct (point-to-point), topic (publish-subscribe) and fanout (multicast)。
**Queue: **
消息最终被送到这里等待consumer取走。一个message可以被同时拷贝到多个queue中。
「Binding:」
exchange和queue之间的虚拟连接，binding中可以包含routing key。Binding信息被保存到exchange中的查询表中，用于message的分发依据。
Exchange的类型
「direct :」
这种类型的交换机的路由规则是根据一个routingKey的标识，交换机通过一个routingKey与队列绑定 ，在生产者生产消息的时候 指定一个routingKey 当绑定的队列的routingKey 与生产者发送的一样 那么交换机会吧这个消息发送给对应的队列。
「fanout:」
这种类型的交换机路由规则很简单，只要与他绑定了的队列， 他就会吧消息发送给对应队列（与routingKey没关系）
「topic:」
(因为*在这个笔记软件里面是关键字，所以下面就用星替换掉了)这种类型的交换机路由规则也是和routingKey有关 只不过 topic他可以根据:星,#（ 星号代表过滤一单词，#代表过滤后面所有单词， 用.隔开）来识别routingKey 我打个比方 假设 我绑定的routingKey 有队列A和B A的routingKey是：星.user B的routingKey是: #.user
那么我生产一条消息routingKey 为：error.user 那么此时 2个队列都能接受到， 如果改为 topic.error.user 那么这时候 只有B能接受到了
「headers:」
这个类型的交换机很少用到，他的路由规则 与routingKey无关 而是通过判断header参数来识别的， 基本上没有应用场景，因为上面的三种类型已经能应付了。
执行过程
1.客户端连接到消息队列服务器，打开一个Channel。
2.客户端声明一个Exchange，并设置相关属性。
3.客户端声明一个Queue，并设置相关属性。
4.客户端使用Routing key，在Exchange和Queue之间建立好绑定关系。
5.客户端投递消息到Exchange。
Exchange接收到消息后，就根据消息的key和已经设置的Binding，进行消息路由，将消息投递到一个或多个队列里。有三种类型的Exchanges：direct，fanout，topic，每个实现了不同的路由算法：
消息的ack机制
默认情况下，如果Message 已经被某个Consumer正确的接收到了，那么该Message就会被从queue中移除。当然也可以让同一个Message发送到很多的Consumer。
如果一个queue没被任何的Consumer Subscribe（订阅），那么，如果这个queue有数据到达，那么这个数据会被cache，不会被丢弃。当有Consumer时，这个数据会被立即发送到这个Consumer，这个数据被Consumer正确收到时，这个数据就被从queue中删除。
消息持久化
RabbitMQ支持消息的持久化，也就是数据写在磁盘上，为了数据安全考虑，大多数用户都会选择持久化。消息队列持久化包括3个部分：
1.Exchange持久化，在声明时指定durable => 1
2.Queue持久化，在声明时指定durable => 1
3.消息持久化，在投递时指定delivery_mode => 2（1是非持久化）
若Exchange和Queue都是持久化的，那么它们之间的Binding也是持久化的；而Exchange和Queue两者之间有一个持久化，一个非持久化，就不允许建立绑定。
特性
可伸缩性：集群服务
消息持久化：从内存持久化消息到硬盘，再从硬盘加载到内存
支持的操作系统
1、Linux
2、WindowsNT到10
3、VxWorks
4、macOS
5、FreeBSD
6、Windows Server2003到2016
7、Solaris
8、TRU64
支持的编程语言
1、Swift
2、Java
3、Elixir
4、Python
5、JavaScript
6、Objective-C
7、Go
8、Ruby
9、C#
7、Ruby
8、PHP
使用场景
-
解耦（为面向服务的架构（SOA）提供基本的最终一致性实现）
-
异步提升效率
-
流量削峰，流量削峰也是消息队列中的常用场景，一般在秒杀或团抢活动中使用广泛
优缺点
在特殊场景下有其对应的好处，解耦、异步、削峰。
「缺点」
1、系统的可用性降低
系统引入的外部依赖越多，系统越容易挂掉。
2、系统的复杂性提高
引入了MQ之后，需要考虑的问题也变得多了，如何保证消息没有重复消费？如何保证消息不丢失？怎么保证消息传递的顺序？
3、一致性问题
A系统发送完消息直接返回成功，但是BCD系统之中若有系统写库失败，则会产生数据不一致的问题。这就涉及到分布式事务的问题。