RabbitMQ基本使用一(简单介绍)

💕💕 我是一名在互联网捡破烂的程序员,随着我们的体系越来越庞大,就电商项目来看,我们的系统也是越来越多,整个体系拆分成多个系统,系统之间的耦合度降低了很多。

那么今天我们来讲一讲RabbitMQ的基本应用。

官方网站

一、介绍:

RabbitMQ是一个消息代理:它接收和转发消息。你可以把它当成一个邮局:当你把邮寄的邮件放在邮筒里时,你可以确定Mailperson先生或女士最终会将邮件发送给你的收件人。在这个类比中,RabbitMQ是一个邮政邮箱,一个邮局和和一个邮递员

RabbitMQ和邮局的主要区别是,它不处理纸张,而是接受,储存和转发二进制的数据、消息

RabbitMQ和消息一般使用的一些专业术语

  • 生产只意味着发送。发送消息的程序是生产者:

  • 队列是位于RabbitMQ内的邮政信箱的名称。尽管消息流经RabbitMQ和应用程序,但他们可以只储存在队列中。队列中仅受主机内存和磁盘限制的约束,它本质上是一个大型消息缓冲区。许多生产者可以发送消息,以进入一个队列,许多使用者可以尝试从一个队列接收数据。这就是我们表示队列的方式:

  • 消息与接收的含义相似。使用者是一个程序,它主要等待接收消息:

请注意,生产者、使用者和代理不必驻留在同一个主机上。因此,生产者、使用者和代理不必驻留在同一个主机上。事实上,在大多数应用中,它们没有。应用程序也可以同时是生产者和消费者

二、为什么要用消息队列

当系统中出现 生产消费的速度或稳定性等因素不一致的时候,就需要消息队里,作为抽象层,弥合双方的差异。消息是在两台计算机间传送的数据单位。消息可以非常简单,例如只包含文本字符串;也可以是复杂对象,可能包含嵌入对象。消息被发送到队列中,消息队列是在消息的传输过程中保存信息的容器

举几个例子

  1. 业务系统触发送短信申请,但短信发送模块速度跟不上,需要将来来不及处理的消息暂存一下,缓冲压力。就可以把短信发送申请丢到消息队列,直接返回用户成功,短信发送模块在可以慢慢去消息队列处理。

  2. 调用远程系统下订单成本较高,且因为网络等因素,不稳定,那就一批一批的发送。

  3. 任务处理类的系统,先把用户发起的任务请求接收过来存到消息队列中,然后后端开启多个应用程序从队列中去任务进行处理

三、使用消息队列有什么好处

  • 提高系统响应速度

    使用消息队列,生产者一方,把消息往队列里面一扔,就立马返回,响应用户了。无需等待结果。

    处理结果可以让用户稍后自己来取,如医院去化验单。也可以让生产者订阅(如:留下手机号码或让生产者时间listener接口,监听队列),有了结果通知。获得约定将结果放在某处,无需通知

  • 提高系统稳定性

    考虑电商项目下单,发送数据给生产者系统的情况。电商系统和生产系统之间的网络有可能掉线,生产系统可能会因维护等原因暂停服务。如果不是用消息队列,电商系统数据发布不出去,顾客无法下单,影响业务开展。两个系统间不应该如此紧密耦合。应该通过消息队里解耦。同时让系统更健壮、稳定。

  • 异步化、解耦、流量消峰

    • 异步:

    假设一个场景:A系统接收一个请求,需要在自己本地写库,还需要在BCD写三个系统写库,自己本地写库要3ms。BCD三个系统分别写库要300ms、450ms、200ms。最终请求总延时3+300+450+200=950ms,接近1s,用户感觉搞个东西,慢的很。用户通过浏览器发起请求,等待1s,这几乎是不可能就收的。

一般互联网类的企业,对与用户直接的操作,一般要求是每个请求都必须在200ms以内完成,对用户几乎是无感知的

如果使用MQ,那么A系统连续发送3条消息到MQ队列中,加入耗时5ms,A系统从接受一个请求到返回响应给用户,总时长是3+5=8ms,对于用户而言,其实感觉上就是点个按钮,8ms以后就直接返回了。

  • 解耦:

    看这么个场景。A系统发送数据到BCD系统,通过接口调用发送。如果E系统也要这个数据呢?那如果C系统现在不要了呢?A系统负责人几乎崩溃。。。。

    在这个场景中,A系统跟其他各种乱七八糟的系统严重耦合,A系统产生一条比较关键的数据,很多系统都需要A系统将这个数据发送过来。A系统要时时刻刻考虑BCDE四个系统管理该咋办?要不要重发,要不要把消息存起来?头发都白了呀!

    如果使用MQ,A系统产生一条数据,发送到MQ里面去,哪个系统需要数据自己去MQ里面消费。如果新系统需要数据,直接从MQ里面消费即可;如果某个系统不需要这条数据了,就取消对MQ消息的消费即可。这样下来,A系统压根儿就不需要考虑要给谁发数据,不再需要维护这个代码,也不需要人间是否调用成功、失败超时等情况。

    总结:通过一个MQ,Pub/Sub发布订阅消息这么一个模型,A系统就跟其他系统彻底解耦了。

    面试技巧:你需要去考虑一下你负责的系统中是否有类似的场景,就是一个系统或者一个模块,调用了多个系统或模块,互相之间的调用很复杂,维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的,如果使用MQ给它异步化解耦,也是可以的,你就需要去考虑在你的项目里,是不是可以运用这个MQ去进行系统的解耦。

  • 流量消峰

    每天0:00到12:00,A系统风平浪静,每秒并发请求数量就50个。结果每次一到12:00~13:00,每秒并发请求的数量突然会暴增到5k+条。但是系统是直接基于MySQL的,大量的请求涌入MySQL,每秒对MySQL执行约5k条SQL。

    一般的MySQL,扛到每秒2k个请求就差不多了,如果每秒请求到5k的话,可能会把MySQL直接个打死了,导致系统崩溃,用户也就没法再使用系统了。

    但是高峰期一过,到了下午的时候,就成了低峰期,可能也就1w的用户同时在网站上操作,每秒中的请求数量可能也就50个请求,对整个系统几乎没有任何压力

    如果使用MQ,每秒5k个请求写入MQ,A系统每秒中最多处理2k个请求,因为MySQL每秒中最多处理2k个请求。A系统从MQ中慢慢拉取请求,每秒中就拉取2k个请求,不要超过自己每秒处理的最大请求数量就可以,这样下来,哪怕是高峰期的时候,A系统也绝对不会挂掉。因为MQ在最前端对流量进行蓄洪,下游的系统只跟MQ打交道。而MQ每秒中5k个请求进来,就2k个请求出去,结果就导致在中午高峰期,可能有几十万甚至几百万的请求积压在MQ中

    这个短暂的高峰期积压是OK的,因为高峰期过来之后,每秒钟就50个请求进MQ,但是A系统依然会按照每秒2k个请求的速度在处理。所以说,只要高峰期一过,A系统就会迅速将积压在MQ的消息处理掉

四、使用消息队列有什么缺点

  • 系统可用性降低

    系统引入的外部依赖越多,越容易挂掉。本来你就是A系统调用BCD三个系统的接口就好了,ABCD四个系统还好好的,没啥问题,你偏要加一个MQ进来,万一MQ挂了咋整?整个系统崩溃了,不就完了?如何保证消息队列的高可用,可以查看。。。

  • 系统复杂度提高

    硬生生价格MQ进来,你怎么保证消息没有被重复消费怎么处理消息丢失的情况?问题一大堆

  • 一致性问题

    A系统处理完了直接返回成功了,人都以为你这个请求成功了,但是问题是,要是BCD三个系统哪里,BD两个系统写库成功了,结果C系统写库失败,咋整?你者数据就不一致了

    参考链接

OK,这一期的消息队列介绍就到这里,感谢你的浏览。你是最亮的仔。。。。