MQ概述

MQ全称 Message Queue(消息队列),是在消息的传输过程中保存消息的容器。多用于分布式系统之间进
行通信。

分布式系统之间进行通信:

远程调用:各系统间直接通过远程调用的方式;

借助第三方完成系统通信:

在这里插入图片描述

上面A系统用来发送消息的为:生产者

B系统用来接收消息的为:消费者

MQ为:中间键

小结
⚫MQ,消息队列,存储消息的中间件
⚫分布式系统通信两种方式:直接远程调用 和 借助第三方 完成间接通信
⚫发送方称为生产者,接收方称为消费者

MQ的优势和劣势

优势:

⚫应用解耦
⚫异步提速
⚫削峰填谷

劣势:

⚫ 系统可用性降低
⚫ 系统复杂度提高
⚫ 一致性问题

优势:

1.应用解耦:

我们先看一幅图:

在这里插入图片描述

客户通过订单系统下单;

上面的订单系统与其他系统是直接通过远程调用连接的:

1、如果库存系统产生了异常,那么订单系统下单的时候整个程序就执行不了,可能导致订单系统也出现一些问题,最后导致下单失败————容错性低

2、假如在程序中添加或删除系统的时候需要程序员不停的修改订单系统————可维护性低

远程调用缺点:系统的耦合性越高,容错性就越低,可维护性就越低。

再看一幅图:

在这里插入图片描述

还是用户通过订单系统下单:

上面是通过借助第三方完成系统间通信的:

1、只需要订单系统给MQ发送一条消息,这时就可以给用户放回消息“下单成功”

2、库存系统、支付系统等等会分别从MQ中取数据,在自己的系统中消费;

3、如果库存系统异常,订单系统不会受到影响,应为订单系统和库存系统已经通过MQ隔离开了

4、库存系统修复完之后,再从MQ中区数据,最终数据正常运行;————系统容错性提高

5、如果程序要添加系统,只需要被添加的系统从MQ中取数据运行就完成了————系统可维护性提高

优点:使用 MQ 使得应用间解耦,提升容错性和可维护性。

2.异步提速

首先查看直接远程调用

在这里插入图片描述

我来描述一下上面的流程:

1、用户点击下单,订单系统去到数据库查询数据用时20ms,然后依次调用库存系统,支付系统,物流系统各300ms;

一个下单操作耗时:20 + 300 + 300 + 300 = 920ms
用户点击完下单按钮后,需要等待920ms才能得到下单响应,太慢!

通过MQ:

在这里插入图片描述

通过异步提速的流程:

客户点击订单系统,订单系统查询db用时20ms,订单发信息给MQ用时5ms,订单下单成功;

用户点击完下单按钮后,只需等待25ms就能得到下单响应 (20 + 5 = 25ms)。
提升用户体验和系统吞吐量(单位时间内处理请求的数目)。

3.错峰填谷

在这里插入图片描述

如果一个系统A系统:每秒最大处理请求是1000个请求。当商家搞活动的时候,就会有很多用户点进来,请求就会瞬间增多,每秒5000个,这个时候A系统就会崩溃了;

在这里插入图片描述

如果我们再客户和A系统之间添加一个中间键MQ就可以解决这个问题;

再们添加MQ之后流量访问变化如下图所示:

在这里插入图片描述

使用了 MQ 之后,限制消费消息的速度为1000,这样一来,高峰期产生的数据势必会被积压在 MQ 中,高峰
就被“削”掉了,但是因为消息积压,在高峰期过后的一段时间内,消费消息的速度还是会维持在1000,直
到消费完积压的消息,这就叫做“填谷”。
使用MQ后,可以提高系统稳定性。**

MQ优势小结

⚫应用解耦:提高系统容错性和可维护性
⚫异步提速:提升用户体验和系统吞吐量
⚫削峰填谷:提高系统稳定性

劣势

⚫系统可用性降低
系统引入的外部依赖越多,系统稳定性越差。一旦 MQ 宕机,就会对业务造成影响。如何保证MQ的高可用?
⚫系统复杂度提高
MQ 的加入大大增加了系统的复杂度,以前系统间是同步的远程调用,现在是通过 MQ 进行异步调用。如何
保证消息没有被重复消费?怎么处理消息丢失情况?那么保证消息传递的顺序性?
⚫一致性问题
A 系统处理完业务,通过 MQ 给B、C、D三个系统发消息数据,如果 B 系统、C 系统处理成功,D 系统处理
失败。如何保证消息数据处理的一致性?

小结

既然 MQ 有优势也有劣势,那么使用 MQ 需要满足什么条件呢?

① 生产者不需要从消费者处获得反馈。引入消息队列之前的直接调用,其接口的返回值应该为空,这才让明
明下层的动作还没做,上层却当成动作做完了继续往后走,即所谓异步成为了可能。
② 容许短暂的不一致性。
③ 确实是用了有效果。即解耦、提速、削峰这些方面的收益,超过加入MQ,管理MQ这些成本。

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐