【绝对有收获】看看MQ?必须告诉你为什么要使用MQ消息中间件(图解版)

欢迎关注文章系列 ,关注我
《提升能力,涨薪可待》
《面试知识,工作可待》
《实战演练,拒绝996》
也欢迎关注公 众 号【Ccww笔记】,原创技术文章第一时间推出
如果此文对你有帮助、喜欢的话,那就点个赞呗,点个关注呗!

《提升能力,涨薪可待》-为什么要使用MQ消息中间件

image

场景一:系统解耦

假设你有个系统A,这个系统A会产出一个核心数据,现在下游有系统B和系统C需要使用这个数据。

首先想到最简单,系统A就是直接调用系统B和系统C的接口发送数据给他们就好了

image

但是现在要是来了系统D、系统E、系统F、系统G,等等,十来个其他系统都需要这份核心数据呢?


image

这是可能会出现开发人员最头疼的、尴尬的问题?

image

先是来一个人找他要求发送数据给一个新的系统H,系统A的同学要修改代码然后在那个代码里加入调用新系统H的流程。
一会那个系统B是个陈旧老系统要下线了,告诉系统A的同学:别给我发送数据了,接着系统A再次修改代码不再给这个系统B。

那我们现在该怎么做呢?系统的耦合性那么高,这真是牵一发而动全身,小需求需要大改动,何必呢?2

image

现在我们主角要来了,可以使用MQ消息中间件,让我们系统之间耦合度降低。

image

现在我们只需要将系统A自己的一份核心数据发送到MQ中间件中,下游哪个系统感兴趣自己去消费即可。

这样能达到一次编译不必改,谁爱谁去改,反正我不改。

image

总结:通过 MQ 消息中间件的使用,重构系统之间的耦合,让系统具备高度的可扩展性。

场景二:异步调用

假设你有一个系统调用链路,是系统A调用系统B,一般耗时20ms;系统B调用系统C,一般耗时200ms;系统C调用系统D,一般耗时2s

image

用户一个请求过来巨慢无比,就像走过长长的套路一样

image

因为走完一个链路,需要耗费:

20ms + 200ms + 2000ms(2s) = 2220ms,

也就是2秒多的时间。但是实际上,链路中的系统A调用系统B,系统B调用系统C,这两个步骤起来也就220ms。

这时候主角大佬又慢慢的过来了,这都搞不定,不是很简单吗?

实现思路就是系统A -> 系统B -> 系统C,直接就耗费220ms后直接成功了。

然后系统C就是发送个消息到MQ中间件里,由系统D消费到消息之后慢慢的异步来执行这个耗时2s的业务处理。通过这种方式直接将核心链路的执行性能提升了10倍。


image

总结:

  • 1)对用户来说,比同步时更加快捷,用户体验非常好。(让用户以为自己抢到了,欺骗ing )
  • 2)对系统访问压力来说,异步因为没有真正执行,不会造成某时刻对系统的访问压力剧增,而是放入队列,慢慢去消费!

场景三:流量削峰

假设你有一个系统,平时正常的时候每秒可能就几百个请求,系统部署在8核16G的机器的上,正常处理都是OK的,每秒几百请求是可以轻松抗住的。
比如秒杀活动

在秒杀活动在高峰期一下子来了每秒钟几千、万请求,弹指一挥间出现了流量高峰。


image

如果时候出现机器宕机,公司损失可是大大的,这是你是不是该准备好被老板痛骂,甚至可能要say goodbye

image

可能想到的解决的方式,线上部署了很多台机器,一多制胜的方法:

image

但是,假设除了秒杀活动达到瞬时高峰,其它时间基本为每秒就几百请求,如果你线上部署了很多台机器,就是为了这次秒杀活动,这有点浪费机器资源。

image

所以这时,MQ大哥又出现了,不怕,这不是还有我吗?

image

在所有机器前面部署一层MQ,平时每秒几百请求大家都可以轻松接收消息。
一旦到了瞬时高峰期,一下涌入每秒几千的请求,就可以积压在MQ里面,然后那一台机器慢慢的处理和消费。

总结:削峰从本质上来说就是更多地延缓用户请求,以及层层过滤用户的访问需求,遵从“最后落地到数据库的请求数要尽量少”的原则。

总结

解耦与复用

系统A要发送一个消息到多个系统,如果此时每增加一个系统,系统A都需要通过修改源码来增加接口,此时耦合非常高,但是如果中间使用消息队列的话,系统只需要发送一次到消息队列,别的系统就能复用该信息,当增加或删除系统调用接口的时候,不需要额外的更新代码。

异步

用户调用一个接口的时候,可能该接口调用了别的方法。例如:用户注册的时候,后台可能需要调用:查询数据库,插入数据库,发送邮件,发送用户指南等等...

但是用户可能并不需要后台将所有的任务执行完毕,那么此时在初入数据口后面加入mq队列,用户就能很快得到注册成功的响应而去做一些别的事情。mq的机制又能保证最终的一致性,所以使用起来很安全很稳定。

削峰

何为削峰,就是当系统压力过大的时候,让系统压力减小。如何做?

比如,平时可能数据库的读写每秒几百,在流量高峰期,系统的访问达到了每秒10000。此时由于加入了消息队列,所以不会出现激增的访问导致系统奔溃。

削峰并不会让用户的等待时间减少,所以一般会跟异步搭配来使用

最后MQ还有其他场景,通知、数据分发等等,能体现使用MQ中间件的好处。

也欢迎关注公 众 号【Ccww笔记】,原创技术文章第一时间推出

image

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,222评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,455评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,720评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,568评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,696评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,879评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,028评论 3 409
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,773评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,220评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,550评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,697评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,360评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,002评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,782评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,010评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,433评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,587评论 2 350