RabbitMQ应用场景解读汇总

一 消息队列在实际应用中常用的使用场景：

• 1异步处理
• 2应用解耦
• 3流量削锋
• 4消息通讯(分布式通讯--服务之间消息通过中间件转发)

二 消息中间件特性的解读和业务场景

一 、解耦：现场画个图来说明一下，A系统发送个数据到BCD三个系统，接口调用发送，那如果E系统也要这个数据呢？那如果C系统现在不需要了呢？现在A系统又要发送第二种数据了呢？A系统负责人濒临崩溃中。。。再来点更加崩溃的事儿，A系统要时时刻刻考虑BCDE四个系统如果挂了咋办？我要不要重发？我要不要把消息存起来？ 这就造成和各个子系统和A系统耦合度非常高,所有子系统依赖于A系统,由A系统负责接收和处理数据,而我们引入了消息中间件时,A只需要将消息发送给MQ就不用管了,后面MQ负责进行转发数据,如果需要新加接收消息的系统或者去除接收消息的系统只需要在中间件和子系统进行配置即可.

A系统和子系统直接耦合,各个子系统提乱七八糟的需求后A系统更改会十分麻烦

使用MQ的情况

二 、异步：现场画个图来说明一下，A系统接收一个请求，需要在自己本地写库，还需要在BCD三个系统写库，自己本地写库要3ms，BCD三个系统分别写库要300ms、450ms、200ms。最终请求总延时是3 + 300 + 450 + 200 = 953ms，接近1s，用户感觉搞个什么东西，慢死了慢死了。

图解不用MQ的处理流程和消耗时间

用消息队列后,我们仅仅需要把消息丢给消息队列就可以了,而不用考虑消息队列的处理流程,达到一个异步处理及时反馈的功能.

图解用MQ的流程和消耗时间

三 、削峰：每天0点到11点，A系统风平浪静，每秒并发请求数量就100个。结果每次一到11点~1点，每秒并发请求数量突然会暴增到1万条。但是系统最大的处理能力就只能是每秒钟处理1000个请求啊。。。尴尬了，系统会死。。。

图解不用MQ的大请求情况

图解用MQ的大请求经削峰后的情况