什么是RabbitMQ

首先了解什么是MQ？

MQ全称 Message Queue（消息队列），是在消息的传输过程中保存消息的容器。多用于分布式系统之间进行通信。消息队列就是所谓的存放消息的队列。 消息队列解决的不是存放消息的队列的⽬的，解决的是通信问题。

MQ的优点：解耦、异步、削峰填谷

解耦：使用 MQ 使得应用间解耦，提升容错性和可维护性

系统的耦合性越高，容错性就越低，可维护性就越低。

以电商系统为例，如果我们系统要做分布式、微服务，我们就会独立几个单独的系统，比如一个订单系统，一个库存系统，一个支付系统，一个物流系统这些系统之间有互相调用的关系，订单系统要付钱就需要调用支付系统，订单支付成功后就要去减少库存，就要调用库存系统，订单支付成功后还要发货就需要调用物流系统。这种情况下就是系统的耦合性太高了。当我们系统之间独立出来几个不同的模块或系统之后，它们之间需要进行远程调用，耦合性就会升高，容错性就会降低，如果其中一个系统出现问题，那么其他系统也会出现问题。

那么，我们在一个系统和其他系统之间加一个MQ，这样不管是谁将消息发送到MQ，就会有MQ进行消息的分发，，哪个系统需要数据就自己去 MQ 里面消费。生产者不知道谁会消费以及具体怎么消费，消费者也不知道消息是谁生产的。使用 MQ 使得应用间解耦，提升容错性和可维护性。

异步提速：通过消息队列异步处理可以提高系统性能，减少响应所需时间，提升用户体验和系统吞吐量（单位时间内处理请求的数目）。

在同步的情况下A系统需要先去调用B系统，B系统执行完成后，再去调用C系统，C系统执行完成后再调用D系统，这个时间是累加的，响应时间就会变得很长。

添加了MQ以后，执行一条请求，把请求发送到MQ，当其他系统需要执行这条请求时，这些系统各自从MQ拿消息进行消费就可以了，提升用户体验和系统吞吐量（单位时间内处理请求的数目）。

削峰填谷：

每个系统会在某个瞬间或者某个时刻请求突然增多，比如A系统最多处理1000个请求，可能平时只有1000个请求，突然上新的新的商品，请求突然增多，一下进了5000个请求，这种情况下，请求的量就达到了一个峰值，那么我们就需要削峰，使用MQ，将到来的请求先放入队列里面，然后再消费者端以一定的速度去消费它们，这个速度以你的服务器的执行效率决定，当有超过服务器QPS的请求过来时，不能处理的请求都积压在了MQ中，虽然可能会导致请求的响应变慢，但是不至于打垮服务器。

MQ 的缺点

1 系统可用性降低

系统引入的外部依赖越多，系统稳定性越差。一旦 MQ 宕机，就会对业务造成影响。

如何保证MQ的高可用？使用集群

2系统复杂度提高

MQ 的加入大大增加了系统的复杂度，以前系统间是同步的远程调用，现在是通过 MQ 进行异步调用。

如何保证消息不被丢失等情况？可以使用分布式事务解决数据一致性问题。

常见MQ产品

ActiveMQ：基于JMS,单机吞吐量：万级，消息延迟：毫秒级
RabbitMQ：基于AMQP协议，erlang语言开发，稳定性好,单机吞吐量：万级，消息延迟：微秒级
RocketMQ``：基于JMS，阿里巴巴产品，目前交由Apache基金会，单机吞吐量：十万级，消息延迟：毫秒级
Kafka：分布式消息系统，高吞吐量单机吞吐量：十万级，消息延迟：毫秒级，以大数据为主

其实现在主流的消息中间件就4种：kafka、ActiveMQ、RocketMQ、RabbitMQ

RabbitMQ相关概念

Publisher - ⽣产者：发布消息到RabbitMQ中的Exchange

Consumer - 消费者：监听RabbitMQ中的Queue中的消息

Broker：接收和分发消息的应用，RabbitMQ Server就是 Message Broker，也就是我们的RabbitMQ服务器

Virtual host：出于多租户和安全因素设计的，在RabbitMQ中可以创建出多个虚拟消息服务器VirtualHost。

Connection：publisher／consumer 和 broker 之间的 TCP 连接

channel-信道： 网络信道，几乎所有操作都在channel中进行，channel是消息读写的通道。客户端可以建立多个channel，每个channel表示一个会话任务 ， 信道有特定的功能，比如创建交换机，创建队列。

Exchange - 交换机：和⽣产者建⽴连接并接收⽣产者的消息 ，并且不能保存消息。

Queue - 队列：Exchange会将消息分发到指定的Queue，Queue和消费者进⾏交互 ，队列是可以保存消息的。

Routes - 路由：交换机以什么样的策略将消息发布到Queue。生产者发消息的时候，可以给消息贴一个标签，为了让指定的消费者接收消息。

首先是生产者,通过连接,连接到MQ,他要和MQ进行通讯,他就要在连接里创建通道,然后就有了信道,然后通过创建好的信道把消息发送给虚拟机里的交换机,然后交换机在把这个消息给到队列.队列就是我们最终存放消息的地方,同时,我们的消费者也创建了一个和MQ的连接,然后再连接里创建了信道,然后通过信道把队列里面的消息给拿回来进行一个消费.

什么是消息的可靠性投递

保证消息一定能发到消息队列中

• 细节- 保证mq节点成功接受消息- 消息发送端需要接受到mq服务端接收到消息的确认应答- 完善的消息补偿机制，发送失败的消息可以再感知并二次处理
• RabbitMQ消息投递路径- 生产者-->交换机-->队列-->消费者- 通过两个点的控制，保证消息的可靠性投递- 生产者到交换机 confirmCallback- 交换机到队列 returnCallbakc
• 建议- 开启消息确认机制以后，保证了消息的准确送达，但由于频繁的确认交互，RabbitMQ的整体效率变低，吞吐量下降严重，不是非常重要的消息不建议用消息确认机制