RabbitMQ(一)初识消息队列(MQ)

  • Post author:
  • Post category:其他




一、什么是消息队列(MQ)

消息队列中间件是分布式系统中重要的组件,主要解决

应用解耦,异步消息,流量削锋

等问题,实现高性能,高可用,可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ

推荐文章:

面试官问我:什么是消息队列?什么场景需要他?用了会出现什么问题?

可以简单的了解消息队列的作用和应用场景


什么是消息队列?



二、消息队列的使用背景

微服务间通讯有同步和异步两种方式:

同步通讯:就像打电话,需要实时响应。

异步通讯:就像发邮件,不需要马上回复。

两种方式各有优劣,打电话可以立即得到响应,但是你却不能跟多个人同时通话。发送邮件可以同时与多个人收发邮件,但是往往响应会有延迟。
在这里插入图片描述



同步通信的缺点

微服务中同步通信的优点:时效性较强,可以立即得到结果

但存在下面的问题:

  • 耦合度高:每次加入新的需求,都要修改原来的代码

  • 性能和吞吐能力下降:调用者需要等待服务提供者响应,如果调用链过长则响应时间等于每次调用的时间之和。

  • 有额外的资源消耗:调用链中的每个服务在等待响应过程中,不能释放请求占用的资源,高并发场景下会极度浪费系统资源

  • 有级联失败问题:如果服务提供者出现问题,所有调用方都会跟着出问题,如同多米诺骨牌一样,迅速导致整个微服务群故障



消息队列的应用背景

一开始 我们的业务非常简单,只有一个支付系统

后来,我们要添加几个业务(如,积分系统、短信系统)

传统的做法有两种 1.串行的方式;2.并行方式

串行方式

在这里插入图片描述

附:串行方式存在如下问题:耦合度高、性能下降、级联失败;

这里只添加了3个服务就导致服务慢了许多,我们能不能考虑同时进行上述的几个操作呢?

2、并行方式(多线程)

在这里插入图片描述

使用这种方式,虽然响应时间也减少了,提高了性能,但是还存在其他相应的问题

耦合度高、资源浪费、级联失败

耦合度高:耦合性越高,容错率越低,可维护性就越低

场景1:每次想要给订单系统增加新的子系统,那么需要修改订单系统的代码?

每次添加一个业务,你要调用一个接口,然后重新发布系统

场景2:假如你的积分系统挂掉了,导致整个订单系统出现了问题(事实上,你在购买东西的时候,只要订单系统正常完成,积分系统即使宕机,也可以先让订单完成,后续再修复积分系统,完成之前的订单的相应操作;否则,任意一个系统宕机都会导致整个系统崩溃,这样子系统的容错率非常低)而且当整个系统崩溃,你不清楚是哪个业务出现了问题,排查起来非常困难,可维护性非常低

有额外的资源消耗:调用链中的每个服务在等待响应过程中,不能释放请求占用的资源,高并发场景下会极度浪费系统资源

事实上,当用户进行支付时,首先进行判断是否支付成功

如果支付成功(收钱成功),我们可以直接响应用户,告知其支付完成,然后在后台进行其他业务的操作(这些操作用户不是必须立刻就要知道,你只需告知用户支付完成,几秒后再告知用户积分等其他情况),这就是我们的异步通信。

当然,用户支付失败则不进行后续的其他业务的操作了

3、异步通信

引入消息队列,将不是必须的业务逻辑,异步处理(可以将支付服务和非必须的业务解耦)

在这里插入图片描述

此时,支付服务只需要 完成自身的支付操作+告知MQ消息队列

然后就能立刻响应用户:订单完成,至于其他业务执行的如何,不在支付服务考虑范围(因此响应用户的速度提高了)消息队列里面的业务可以后续慢慢完成

备注:Broker是什么?(上面的MQ就是一种Broker)

为了解除事件发布者与订阅者之间的耦合,两者并不是直接通信,而是有一个中间人(Broker)。发布者发布事件到Broker,不关心谁来订阅事件。订阅者从Broker订阅事件,不关心谁发来的消息。

MQ就是一种常见Broker软件
在这里插入图片描述

在事件模式中,支付服务是事件发布者(publisher),在支付完成后只需要发布一个支付成功的事件给Broker(事件中带上订单id)

优惠券等其他服务是事件订阅者(Consumer),订阅者会监听“支付成功”的事件,监听到事件后完成自己业务即可。

使用消息队列进行异步处理有如下的好处:

1、解耦合:支付服务不再负载调用各种服务,而是只发送一个支付成功事件给Broker(中间人)(这里的Broker为MQ)就可以随意的增加业务和取消业务而不修改支付服务,每个服务都可以灵活插拔,可替换(通过MQ的订阅者取消订阅/监听即可)

2、异步提速:无需等待订阅者处理完成,响应更快速

3、故障隔离:服务没有强依赖,不担心级联失败问题(其他服务失败不会导致支付服务也失败)

4、流量削峰:不管发布事件的流量波动多大,都由Broker(MQ)接收,订阅者可以按照自己的速度去处理事件

5、调用间没有阻塞,不会造成无效的资源占用(解决了并行方式的缺点)

通过消息队列进行异步处理也有缺点:

  • 架构复杂了,业务没有明显的流程线,不好管理
  • 需要依赖于Broker(MQ)的可靠、安全、性能

消息队列专栏文章:

消息队列专栏文章:


RabbitMQ(一)初识消息队列(MQ)


RabbitMQ(二):RabbitMQ的安装(Linux、基于docker安装)及其插件安装


RabbitMQ(三):RabbitMQ快速入门(SpringBoot)


RabbitMQ(四):RabbitMQ高级特性

文章整理自:

黑马教学视频



版权声明:本文为m0_53142956原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。