RabbitMQ使用场景的介绍

1.RabbitMQ简介

MQ 称为消息队列。消息队列 (RabbitMQ消息队列) 是一种应用程序到应用程序的通信方法。应用程序通过读取和写入进入和离开队列的消息(应用程序的数据)进行通信，而无需专用连接来链接它们。消息传递是指程序之间通过消息中的数据进行通信，而不是直接相互调用进行通信。直接调用通常用于远程过程调用等技术。队列是指通过队列进行通信的应用程序。队列的使用消除了同时执行接收和发送应用程序的要求。

RabbitMQ 是一个开源的消息队列系统，使用 Erlang 语言开发，基于 AMQP 协议实现。AMQP的主要特点是面向消息、队列、路由(包括点对点和发布/订阅)、可靠性和安全性。AMQP 协议在企业系统中使用较多。对于对数据一致性、稳定性和可靠性要求较高的场景，对性能和吞吐量的要求是次之。

2.RabbitMQ使用场景

(1)解耦(为面向服务的架构(SOA)提供基本的最终一致性实现)

场景描述：用户下单后，订单系统需要通知库存系统。传统的做法是订单系统调用库存系统的接口。

传统模式的缺点：

如果库存系统无法访问，库存的订单减少将失败，导致订单失败

订单系统与库存系统的耦合

介绍消息队列：

订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，成功返回用户订单

库存系统：订阅订单信息，通过pull/push方式获取订单信息，库存系统根据订单信息进行库存操作

如果：下单时库存系统无法正常使用。不影响正常下单，因为下单后，订单系统写入消息队列，不再关心其他后续操作。实现订单系统和库存系统的应用解耦

为了保证库存肯定有，可以将队列大小设置为库存数量，或者用其他方法解决。

基于消息的模型关注的是“通知”而不是“处理”。

短信、邮件通知、缓存刷新等操作使用消息队列进行通知。

消息队列和RPC的区别和对比：

RPC：异步调用，及时获取调用结果，具有强一致性结果，关心业务调用处理结果。

消息队列：两个异步RPC调用，将调用的内容转储到队列中，选择合适的时间进行投递(移峰流量控制)

(2)异步提高效率

场景描述：用户注册后需要发送注册邮件和注册短信。传统方式有两种： 1. 串口方式;2.并联模式

1)串口方式：成功将注册信息写入数据库后，发送注册邮件，然后发送注册短信。以上三项任务完成后，返回客户端

2)并行模式：注册信息成功写入数据库后，注册邮件与注册短信同时发送。以上三项任务完成后，返回客户端。与串行的区别在于并行方式会增加处理时间.

消息队列的引入将不需要业务逻辑，异步处理。重构结构如下：

(3)流量削峰

流量削峰也是消息队列中常见的场景，一般用在秒杀或者群抢活动中

应用场景：系统其他时间，系统A每秒有100个请求，系统可以稳定运行。系统每晚8点都有高峰活动，每秒并发请求数增加到10000，但系统最大处理能力每秒只能处理1000个请求，所以系统崩溃，服务器下跌降落。

以往架构：大量用户(100万用户)通过浏览器在晚上8点高峰同时参与秒杀活动。大量请求涌入我们的系统。高峰期达到每秒 5000 个请求。大量请求命中 MySQL。估计每秒会执行3000条SQL。但是，一般的 MySQL 每秒可以处理 2000 个请求。如果达到3000个请求，MySQL可能会直接瘫痪，系统无法使用。然而，在高峰期之后，它变成了低峰期。可能只有10000个用户访问系统，每秒请求数只有50个左右，整个系统几乎没有压力。

引入MQ：在100万用户的高峰期，每秒大约有5000个请求。将这 5000 个请求写入 MQ。系统A每秒只能处理2000个请求，因为MySQL每秒只能处理2000个请求。要求。系统 A 从 MQ 缓慢拉取请求，每秒拉取 2000 个请求，不超过它每秒可以处理的请求数。MQ，每秒有5000个请求进来，但出去的请求只有2000个，所以在高峰期(近一个小时)，可能会有几十万甚至几百万的请求积压在MQ中。

3.引入消息队列的优缺点

优势

优点是上述场景在特殊场景下都有相应的好处，比如解耦、异步、削峰。

坏处

降低系统可用性

系统引入的外部依赖越多，系统就越容易挂机。原来只是A系统调用了BCD的三个系统接口，ABCD的四个系统就可以正常运行，不会报错。引入MQ之后，虽然ABCD系统没有出错，但是MQ挂掉之后整个系统也会崩溃。

增加系统复杂性

MQ引入后，需要考虑的问题更多。如何保证消息不被重复消费?如何保证消息不丢失?如何保证消息传递的顺序?

一致性问题

系统A直接发送消息并返回成功，但是如果BCD系统出现系统写库失败，就会出现数据不一致的情况。

概括

所以综上所述，消息队列是一个非常复杂的架构。引入它有很多优点，但必须做出各种额外的技术解决方案和架构，以避免它带来的缺点。MQ系统的引入复杂度提高了一个数量级，但在某些场景下，复杂度是十倍一百倍，仍然需要MQ。