RabbitMQ的使用场景

RabbitMQ 简介

很多刚开始学习Java的小伙伴对RabbitMQ还不是很了解，RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由(包括点对点和发布/订阅)、可靠性、 安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。

MQ全称为Message Queue, 消息队列(MQ)是一种应用程序对应用程序的通信方法。应用程序通过读写出入队列的消息(针对应用程序的数据)来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过 队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。

解耦

当发送短信执行成功后页面才执行倒计时60秒，假如在发送短信时网速原因，导致短信一直被阻塞，那么倒计时也会被一直延迟，这样及其影响用户体验感。

这时候就可以使用RabbitMQ了，将发送短信和倒计时解耦，基于消息的模型，关心的是“通知”，而非“处理”。

像下订单、邮件通知、缓存刷新等操作都可以使用消息队列进行优化。

异步提升效率

场景说明：用户需发送短信验证码时，点击发送短信，第三方平台发送短信至用户手机成功，执行倒计时60秒。传统的做法有两种 1.串行的方式;2.并行方式：

(1)串行方式：将用户点击发送短信，第三方平台发送短信至用户手机成功，执行倒计时60秒。以上三个任务全部完成后，返回给客户端(响应150ms)。

(2)并行方式：在用户点击发送短信成功后，第三方平台发送短信的同时，执行倒计时60秒。与串行的差别是，并行的方式可以提高处理的时间(响应100ms)。

(3)引入消息队列，将不是必须的业务逻辑，异步处理(55ms)。改造后的架构如下：

流量削峰

流量削锋(流量错峰)也是消息队列中的常用场景，一般在秒杀或团抢活动中使用广泛。

应用场景：系统其他时间A系统每秒请求量就100个，系统可以稳定运行。系统每天晚间八点有秒杀活动，每秒并发请求量增至5000条，但是系统最大的处理能力只能每秒处理2000个请求(因为MySQL每秒只能处理2000个请求，MySQL的缺点：在海量数据处理与热数据时，效率会显著变慢)，于是系统崩溃，服务器宕机。

引入RabbitMQ：系统A从RabbitMQ中慢慢拉取请求，每秒就拉取2000个请求，不要超过自己每秒能处理的请求数量即可。RabbitMQ，每秒5000个请求进来，结果只有2000个请求出去，所以在秒杀期间(将近一小时)可能会有几十万或者几百万的请求积压在RabbitMQ中。这个短暂的高峰期积压是没问题的，因为高峰期过了之后，每秒就只有50个请求进入RabbitMQ了，但是系统还是按照每秒2000个请求的速度在处理，所以说，只要高峰期一过，系统就会快速将积压的消息消费掉。我们在此计算一下，每秒在RabbitMQ积压3000条消息，1分钟会积压18万，1小时积压1000万条消息，高峰期过后，1个多小时就可以将积压的1000万消息消费掉。

以上就是关于“RabbitMQ的使用场景”的介绍，如果您想了解更多相关知识，可以关注一下极悦的Java极悦在线学习，里面的课程内容丰富，由浅到深，适合没有基础的小伙伴学习，希望对大家能够有所帮助。