一、什么是RabbitMQ？
答：RabbitMQ简称MQ是一套实现了高级消息队列协议的开源消息代理软件，简单来说就是一个消息中间件。是一种程序对程序的通信方法，其服务器也是以高性能、健壮以及可伸缩性出名的Erlang语言编写而成。
二、RabbitMQ是干什么的？
答：RabbitMQ简单来说就是一个消息队列中间件，用来保存消息和传递消息的一个容器。在此过程中充当一个中间人的作用。
而队列的主要目的就是提供正确的路由来保证消息的传递；如果发送消息时消费者不可用的话，默认情况下该消息将会一直被存储在队列中，直到消费者消费为止。
那么同时呢，如果设置了消息存活的时间，即消息的有效期。在此有效期间消息如果还没有被消费的话，那么该消息就会变成死信，由死信交换机接收。而绑定死信交换机的队列则称为死信队列。
三、RabbitMQ的常见作用有那些？
答：RabbitMQ的常见作用有三种，分别是服务间解耦、实现异步通信、流量削峰。
主要实现了消费者和生产者之间的解耦，发送异步消息，高并发访问解决流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。
常见的应用常见有：用户订单，库存处理；用户注册，发送手机短信邮件；商品秒杀和抢购等...
场景一：用户订单，库存处理。【服务间解耦】
使用MQ前：系统正常时，用户下单，订单系统调用库存系统进行删减操作，操作成功，将成返回消息，提醒下单成功。系统异常时，库存系统将无法访问，导致订单删减操作无法执行，最终导致下单失败。
使用MQ后：订单系统和库存系统之间不在互相影响，独立运行，达到了应用解耦的目的。订单系统只需要将下单消息写入MQ,就可以直接执行下一步操作。这时即使库存系统出现异常也不会影响订单系统的操作，且下单的库存删减记录，将会被永久保存到MQ中，直到库存系统恢复正常，从MQ中订阅下单消息，进行消费成功为止。
场景二：用户注册，发送手机短信，邮件。【实现异步通信】
使用MQ前：整个操作流程，全部在主线程完成。点击用户注册 --》 入库添加用户 --》发送邮件 --》发送短信。每一步都需要等待上一步完成后才能执行。且每一步操作的响应时间不固定，如果请求过多，会导致主线程请求耗时很长，响应慢，甚至会导致死机的情况出现，严重影响了用户的体验。
使用MQ后：主线程只需要处理耗时较低的入库操作，然后把需要处理的消息写进MQ消息队列中，然后由不同的独立的邮件系统和发短信系统，同时订阅消息队列中的消息进行消费。这样通过消息队列作为一个中间人去保存和传递消息，不仅仅耗时低消耗的资源也很少且单个服务器能够承受的并发请求将更多。
场景三：商品秒杀和抢购。【流量削峰】
流量削峰是消息队列中常用的场景 一般在秒杀或团购活动中使用广泛。
使用MQ前：对于秒杀、抢购活动，用户访问所产生的流量会很大，甚至会在同一时间段出现上万上亿条请求，这股瞬间的流量暴涨，我们的应用系统配置是无法承受的，会导致系统直接崩溃死机。
例如：A系统平时每秒请求100个，系统稳定运行； 但是晚上8点有秒杀活动 ，每秒并发增至1万条 ，系统最大处理每秒1000条 于是导致系统崩溃。
使用MQ后：我们在大量用户进行秒杀请求时，将那个巨大的流量请求拒在系统业务处理的上层，并将其转移至MQ中，而不是直接涌入我们的接口。在这里MQ消息队列起到了缓存作用。
例如：100万用户在高峰期，每秒请求5000个，将这5000个请求写入MQ系统每秒只能处理2000请求，因为MySQL只能处理2000个请求 ; 系统每秒拉取2000个请求 不超过自己的处理能力即可。
四.工作模式及原理
RabbitMQ的5大核心概念：Connection（连接）、Channel（信道）、Exchange（交换机）、Queue（队列）、Virtual host（虚拟主机）。
介绍这些概念之前，我们先看一张图，图中展示的是RabbitMQ的工作模型，根据这张图，下面理解起来就比较容易了
其中，中间的Broker表示RabbitMQ服务，每个Broker里面至少有一个Virtual host虚拟主机，每个虚拟主机中有自己的Exchange交换机、Queue队列以及Exchange交换机与Queue队列之间的绑定关系Binding。producer（生产者）和consumer（消费者）通过与Broker建立Connection来保持连接，然后在Connection的基础上建立若干Channel信道，用来发送与接收消息。
Connection（连接）
每个producer（生产者）或者consumer（消费者）要通过RabbitMQ发送与消费消息，首先就要与RabbitMQ建立连接，这个连接就是Connection。Connection是一个TCP长连接。
Channel（信道）
Channel是在Connection的基础上建立的虚拟连接，RabbitMQ中大部分的操作都是使用Channel完成的，比如：声明Queue、声明Exchange、发布消息、消费消息等。
看到此处，你是否有这样一个疑问：既然已经有了Connection，我们完全可以使用Connection完成Channel的工作，为什么还要引入Channel这样一个虚拟连接的概念呢？因为现在的程序都是支持多线程的，如果没有Channel，那么每个线程在访问RabbitMQ时都要建立一个Connection这样的TCP连接，对于操作系统来说，建立和销毁TCP连接是非常大的开销，在系统访问流量高峰时，会严重影响系统性能。
Channel就是为了解决这种问题，通常情况下，每个线程创建单独的Channel进行通讯，每个Channel都有自己的channel id帮助Broker和客户端识别Channel，所以Channel之间是完全隔离的。
Connection与Channel之间的关系可以比作光纤电缆，如果把Connection比作一条光纤电缆，那么Channel就相当于是电缆中的一束光纤。
Virtual host（虚拟主机）
Virtual host是一个虚拟主机的概念，一个Broker中可以有多个Virtual host，每个Virtual host都有一套自己的Exchange和Queue，同一个Virtual host中的Exchange和Queue不能重名，不同的Virtual host中的Exchange和Queue名字可以一样。这样，不同的用户在访问同一个RabbitMQ Broker时，可以创建自己单独的Virtual host，然后在自己的Virtual host中创建Exchange和Queue，很好地做到了不同用户之间相互隔离的效果。
Queue（队列）
Queue是一个用来存放消息的队列，生产者发送的消息会被放到Queue中，消费者消费消息时也是从Queue中取走消息。
Exchange（交换机）
Exchange是一个比较重要的概念，它是消息到达RabbitMQ的第一站，主要负责根据不同的分发规则将消息分发到不同的Queue，供订阅了相关Queue的消费者消费到指定的消息。那Exchange有哪些分发消息的规则呢？这就要说到Exchange的4种类型了：direct、fanout、topic、headers。
在介绍这4种类型的Exchange之前，我们先来了解一下另外一个比较重要的概念：Routing key，翻译成中文就是路由键。当我们创建好Exchange和Queue之后，需要使用Routing key（通常叫作Binding key）将它们绑定起来，producer在向Exchange发送一条消息的时候，必须指定一个Routing key，然后Exchange接收到这条消息之后，会解析Routing key，然后根据Exchange和Queue的绑定规则，将消息分发到符合规则的Queue中。
接下来，我们根据上面的流程再来详细介绍下4种类型的Exchange。
1、direct
direct的意思是直接的，direct类型的Exchange会将消息转发到指定Routing key的Queue上，Routing key的解析规则为精确匹配。也就是只有当producer发送的消息的Routing key与某个Binding key相等时，消息才会被分发到对应的Queue上。
比如我们现在有一个direct类型的Exchange，它下面绑定了三个Queue，Binding key分别是ORDER/GOODS/STOCK：
然后我们向该Exchange中发送一条消息，消息的Routing key是ORDER：
按照规则分析，这条消息应该被路由到MY_EXCHANGE_ORDER_QUEUE这个Queue。消息发送成功之后，我们去Queues中查看，发现确实只有MY_EXCHANGE_ORDER_QUEUE这个QUEUE接收到了一条消息。
进入这个队列，通过getMessage取出消息查看，确实是我们刚才手动发送的那条消息。
所以，direct类型的Exchange在分发消息时，必须保证producer发送消息的Routing key与Exchange和Queue绑定的Binding key相等才可以。
2、fanout
fanout是扇形的意思，该类型通常叫作广播类型。fanout类型的Exchange不处理Routing key，而是会将发送给它的消息路由到所有与它绑定的Queue上。
比如我们现在有一个fanout类型的Exchange，它下面绑定了三个Queue，Binding key分别是ORDER/GOODS/STOCK：
然后我们向该Exchange中发送一条消息，消息的Routing key随便填一个值abc：
然后我们向该Exchange中发送一条消息，消息的Routing key随便填一个值abc：
然后我们向该Exchange中发送一条消息，消息的Routing key随便填一个值abc：
所以，fanout类型的Exchange不管Routing key是什么，它都会将接收到的消息分发给所有与自己绑定了的Queue上。
3、topic
topic的意思是主题，topic类型的Exchange会根据通配符对Routing key进行匹配，只要Routing key满足某个通配符的条件，就会被路由到对应的Queue上。通配符的匹配规则如下：
● Routing key必须是一串字符串，每个单词用“.”分隔；
● 符号“#”表示匹配一个或多个单词；
● 符号“*”表示匹配一个单词。
例如：“*.123” 能够匹配到 “abc.123”，但匹配不到 “abc.def.123”；“#.123” 既能够匹配到 “abc.123”，也能匹配到 “abc.def.123”。
比如我们现在有一个topic类型的Exchange，它下面绑定了4个Queue，Binding key分别是 .ORDER、GOODS.、#.STOCK、USER.#。
然后我们向该Exchange中发送一条消息，消息的Routing key为：USER.ABC.ORDER。
按照规则分析，USER.ABC.ORDER这个Routing key只可以匹配到 “USER.#” ，所以，这条消息应该被路由到MY_TOPIC_USER_QUEUE这个Queue中。消息发送成功之后，我们去Queues中查看，发现结果符合我们的预期。
进入这个QUEUE，通过getMessage取出消息查看，确实是我们刚才手动发送的那条消息。
4、headers
日常工作中，以上三种类型的Exchange已经能够满足我们基本上所有的需求了，headers模式并不经常使用，我们只需要对headers Exchange有一个基本的了解就可以了。
headers Exchange中，Exchange与Queue之间的绑定不再通过Binding key绑定，而是通过Arguments绑定。比如我们现在有一个headers类型的Exchange，下面通过不同的Arguments绑定了三个Queue：
producer在发送消息时可以添加headers属性，Exchange接收到消息后，会解析headers属性，只要我们上面配置的Arguments中的所有属性全部被包含在Headers中并且值相等，那么这条消息就会被路由到对应的Queue中。
比如我们向上面的Exchange中发送一条消息，消息的Headers中添加“x=1”：
根据规则，只有queue1这个队列满足x=1的条件，queue2中的y=2条件不满足，所以，消息应该只被路由到queue1队列中。
消息发送成功后，我们可以看到queue1确实收到了消息：并且这条消息就是我们刚才手动发送的消息：
然后我们再发送一条消息，消息的headers中有两个属性：x=1，y=2：
根据规则，queue1的x=1的条件满足，queue2的x=1、y=2的条件满足，queue3的y=2的条件满足，所以，这三个Queue应该都能够收到这条消息。消息发送成功后，结果符合预期：
这条消息就是我们刚才手动发送的消息：
