为什么要使用消息中间件?
1. 系统解耦
假设一个订单在整个交易系统会经历如下两个步骤:
A:订单创建
B:订单出库
整个过程,如下图所示:
但是现在有了新需求,我们需要在统计订单的创建数据,便于在双11的时候用于分析实时系统下单总销量,就像天猫双11大屏幕那样展示当前时刻的单量和销售额。你想到了一个方案对创建订单的接口进行了一系列的更改,改完后有来了一个新功能,现在我们不仅要统计总销量,还要统计每个省份的销量,于是乎你又不得不去更改下单接口。而下单接口对整个系统来说又是非常重要的一个接口,一旦更改势必影响甚广。显然这种方法是不可取的。
而现在你可以尝试使用消息中间件来对系统进行解耦操作了。订单的实时销售数据统计从创建之中分离出来,采用消息异步进行处理,既能不影响订单的创建,通过及时的消息消费与流式框架处理,使之接近实时的销售数据展示。
再则又有新的功能。公司能够支撑多承运商发货了,我们不用更改订单的发货功能,而是与订单创建类似的实现方式利用消息进行系统解耦
通过引入消息中间件后对原系统的架构无任何影响,无需更改之前的任何代码。同时通过队列的方式还可以对消息进行并行处理,通过主题模对同一个消息进行不同的处理。
2. 异步调用
我们再回到订单创建使用消息中间件之前,订单创建接口假如有如下步骤:
整个订单创建接口总耗时 100 + 500 + 300 ,发现订单落库只需要1/9的时间,其它大部分时间用在了发送短信和增加积分上面。但是这两个步骤对于整个订单的创建来说是非必须的,且并不是一定要求下单后立刻给用户发送短信和增加用户积分。
通过消息中间件进行异步调用后:
订单创建接口现在只需要100ms+发送消息耗时,同时发送短信和增加积分是异步进行处理的不影响下单的接口性能,极大的提高了用户下单功能的体验。
3. 流量削峰
假设你有一个系统,平时正常的时候每秒可能就几百个请求,但是在双11的时候,每秒钟几千上万的请求,瞬时出现了流量高峰,此时你的选择是要搞10台机器,抗住每秒成千上万请求的瞬时高峰吗?而且仅仅为了双11的那几天,如果你线上部署了很多台机器,那么每台机器就处理每秒几十个请求就可以了,这不是有点浪费机器资源吗?
此时我们就可以用MQ中间件来进行流量削峰。所有机器前面部署一层MQ,平时每秒几百请求大家都可以轻松接收消息。
一旦到了瞬时高峰期,一下涌入每秒几千的请求,就可以积压在MQ里面,然后那一台机器慢慢的处理和消费。
等高峰期过了,再消费一段时间,MQ里积压的数据就消费完毕了。
ps:以上部分内容来源于网络