为什么要使用消息中间件

为什么要使用消息中间件？

1. 系统解耦

假设一个订单在整个交易系统会经历如下两个步骤：
A:订单创建
B:订单出库
整个过程，如下图所示：

但是现在有了新需求，我们需要在统计订单的创建数据，便于在双11的时候用于分析实时系统下单总销量，就像天猫双11大屏幕那样展示当前时刻的单量和销售额。你想到了一个方案对创建订单的接口进行了一系列的更改，改完后有来了一个新功能，现在我们不仅要统计总销量，还要统计每个省份的销量，于是乎你又不得不去更改下单接口。而下单接口对整个系统来说又是非常重要的一个接口，一旦更改势必影响甚广。显然这种方法是不可取的。

而现在你可以尝试使用消息中间件来对系统进行解耦操作了。订单的实时销售数据统计从创建之中分离出来，采用消息异步进行处理，既能不影响订单的创建，通过及时的消息消费与流式框架处理，使之接近实时的销售数据展示。

再则又有新的功能。公司能够支撑多承运商发货了，我们不用更改订单的发货功能，而是与订单创建类似的实现方式利用消息进行系统解耦

通过引入消息中间件后对原系统的架构无任何影响，无需更改之前的任何代码。同时通过队列的方式还可以对消息进行并行处理，通过主题模对同一个消息进行不同的处理。

2. 异步调用

我们再回到订单创建使用消息中间件之前，订单创建接口假如有如下步骤：

整个订单创建接口总耗时 100 + 500 + 300 ，发现订单落库只需要1/9的时间，其它大部分时间用在了发送短信和增加积分上面。但是这两个步骤对于整个订单的创建来说是非必须的，且并不是一定要求下单后立刻给用户发送短信和增加用户积分。

通过消息中间件进行异步调用后：

订单创建接口现在只需要100ms+发送消息耗时，同时发送短信和增加积分是异步进行处理的不影响下单的接口性能，极大的提高了用户下单功能的体验。

3. 流量削峰

假设你有一个系统，平时正常的时候每秒可能就几百个请求，但是在双11的时候，每秒钟几千上万的请求，瞬时出现了流量高峰，此时你的选择是要搞10台机器，抗住每秒成千上万请求的瞬时高峰吗？而且仅仅为了双11的那几天，如果你线上部署了很多台机器，那么每台机器就处理每秒几十个请求就可以了，这不是有点浪费机器资源吗？

此时我们就可以用MQ中间件来进行流量削峰。所有机器前面部署一层MQ，平时每秒几百请求大家都可以轻松接收消息。
一旦到了瞬时高峰期，一下涌入每秒几千的请求，就可以积压在MQ里面，然后那一台机器慢慢的处理和消费。
等高峰期过了，再消费一段时间，MQ里积压的数据就消费完毕了。

ps:以上部分内容来源于网络