消息队列的应用场景

1、解耦（为面向服务的架构(SOA)提供最终一致性）

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

传统模式的缺点：
1.假如库存系统无法访问，则订单系统访问库存系统失败，从而导致订单失败
2.订单系统与库存系统耦合

引入消息队列

订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户下单成功
库存系统：订阅下单的消息，采用拉去/推送的方式获取下单信息。库存系统根据下单信息，进行库存操作
假如：在下单时，库存系统不能正常使用，也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心后续其他操作，实现订单系统与库存系统的解耦

基于消息的模型，关系的是通知，而非处理。
短信、邮件通知、缓存书信等操作使用消息队列进行通知。

2、异步提升效率

场景说明：用户注册后，需要发送注册邮件和注册短信。传统的做法有两种：串行和并行
1、穿行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。完成以上三个任务后，返回给客户端。
2、并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信，完成以上三个任务后，返回给客户端。并行方式可以提高处理时间，提升效率。
3、引入消息队列，将不是必须的业务逻辑做异步处理。用户注册信息写入数据库成功后再，写入消息到消息队列，发送邮件和短息的服务从消息队列获取到消息后异步完成短息和邮件的发送。

3、流量削峰

流量削峰也是消息队列的常用场景，一般再秒杀或者团抢活动中广泛使用

应用场景：系统其他时间A系统每秒请求量就100个，系统可以稳定运行。系统每天晚间八点有秒杀活动，每秒并发请求量增至1万条，但是系统最大的处理能力只能每秒处理1000个请求，于是系统崩溃，服务器宕机。

之前架构：大量用户（100万用户）通过浏览器在晚上八点高峰期同时参与秒杀活动。大量的请求涌入我们的系统中，高峰期达到每秒钟5000个请求，大量的请求打到MySQL上，每秒钟预计执行3000条SQL。但是一般的MySQL每秒钟扛住2000个请求就不错了，如果达到3000个请求的话可能MySQL直接就瘫痪了，从而系统无法被使用。但是高峰期过了之后，就成了低峰期，可能也就1万用户访问系统，每秒的请求数量也就50个左右，整个系统几乎没有任何压力。

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