rabbitmq实战篇 - 使用场景_rabbitmq实战场景

---

前言

rabbitmq 秒杀场景实现 本文仅自己学习使用,如有雷同勿喷

---

一、为什么要使用MQ？

RabbitMQ的常见作用有三种，分别是服务间解耦、实现异步通信、流量削峰。

主要实现了消费者和生产者之间的解耦，发送异步消息，高并发访问解决流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。

常见的应用常见有：用户订单，库存处理；用户注册，发送手机短信邮件；商品秒杀和抢购等…

二、RabbitMQ的应用场景有那些？

1.用户订单，库存处理。【服务间解耦】

使用MQ前：系统正常时，用户下单，订单系统调用库存系统进行删减操作，操作成功，将成返回消息，提醒下单成功。系统异常时，库存系统将无法访问，导致订单删减操作无法执行，最终导致下单失败。

使用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个请求 不超过自己的处理能力即可。

使用MQ前：

使用MQ后：

---

参考文字

https://blog.csdn.net/zsy3757486/article/details/126941322?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522168239257916800213094724%2522%252C%2522scm%2522%253A%252220140713.130102334…%2522%257D&request_id=168239257916800213094724&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2_alltop_positive~default-1-126941322-null-null.142^v86insert_down28,239^v2insert_chatgpt&utm_term=rabbitmq%E4%BD%BF%E7%94%A8%E5%9C%BA%E6%99%AF&spm=1018.2226.3001.4187