从生活聊用消息队列的利弊
先思考几个问题:
- 为什么要选择消息队列?
- 消息队列有什么优点?
- 消息队列会带来哪些问题?
疫情当下,为了更好的防疫工作,食堂不再提供堂食,同学们需要把食物打包回公司吃,在公司吃跟堂食的区别是什么呢?
然后小豆需要统计产品线需要带饭的有哪些人,负责把饭菜统一打包带回来。产品线主要划分三部分:设计,开发和运维。
小豆每天用自己设计的统计表,带着小本本去三个部门获取人员名单。有一天新增了一个销售部,销售部也需要带饭,小豆赶紧加班修改统计表,然后跑销售部。
过两天开发说他们不需要了,你不用来了,这一晚接着加班修统计表。统计人开始濒临崩溃状态……
三天后,小豆去运维统计信息,发现运维部的二狗带薪蹲坑,掉厕所里面了,emmm……完了,统计工作卡到这里了……
这种问题该如何解决是好呢?
这个东西很简单,小豆可以在产品线专栏发布一个公告,把订餐的详细情况写上去,需要订餐的部门对这个订餐信息加个特别关注。
部门在每天收到信息后,把自己的订餐统计表反馈给小豆。如果部门不需要订餐了,那就取消对这个订餐信息的特别关注即可。如果新增加了部门,直接关注即可。
从此统计人再也不需要考虑每天要统计哪些部门了,你们爱吃吃不吃拉倒,不需要自己维护复杂的关系。
同样的,一个系统调用了多个系统,互相之间的调用比较复杂,维护起来很麻烦,这种不需要同步调用接口的情况,可以考虑是否通过MQ去进行系统的解耦。例如Pub/Sub
模型让统计人和其他部门解耦了。这是MQ第一个特点:解耦。
还是上面那个订餐的场景,小豆带着小本本去统计的时候,先去设计部花费了20分钟,接着去开发部统计信息花费了40分钟,最后去运维部统计信息花费了25分钟,那么总共耗时就是85分钟。
现在小豆在公告栏上发布信息,各部门在收到通知以后,然后填写统计表信息,这种异步操作是不是省了什么时间。
一个系统把需要其他系统处理的信息,放到MQ中,每个系统从MQ中消费对应的信息,然后自己执行需要的操作,这样是不是比一个系统顺序调用其他系统要优雅很多。这是MQ第二个特点:异步。
你是否还记得,曾经打疫苗还奖励几百块钱的时候,大家对打疫苗嗤之以鼻,很少有人去社区打疫苗。
直到有一天,发现了一个确诊病例,完了……
人们开始一窝蜂的往医院挤过去,在这种混乱的场景下,这社区小医院的能力本来就有限,面对这些暴增的人群……医院要被搞垮了。
这时候就需要一些优雅的方法解决问题,比如第二天的时候,工作人员用隔离带拉出来一条弯弯曲曲的队列。当大量用户再来的时候,咱们不急,咱们让他们先进去排个队,医院里面的工作人员慢慢处理,这样不至于一下子搞垮了。
同样的,大量的请求涌入系统的时候,超过系统的最大处理量,会直接导致整个系统的崩溃,大家都玩不了。咱们可以把请求放在MQ中,然后系统慢慢的处理请求,处理的时间可能会拉长。这是MQ的第三个特点:削峰。
那么思考一个问题,如果请求量太大,要把MQ挤爆了,这时候该怎么处理呢?想想大量的人在核酸检测的时候,都做了哪些操作
所有的知识,都需要结合实际的业务,思考哪些场景可以使用。如果你要是把百度搜索这样的请求放进削峰的MQ中,几分钟以后出来结果,哼哼……削不削峰咱不知道,我想把这系统削了。
看到这里,为什么使用MQ,以及它有什么优点已经不用再多说了。
既然这么好,我们是不是在能解决问题的时候无脑引入就可以了呢?
每一个系统,在引入一个技术的时候可能存在风险。
小豆跟心仪的开发部妹子,每天一起上下班,聊的很嗨。终于等到了情人节,然后小豆写了一封表白情书,没好意思直接送过,中间托二狗帮个忙送过去。结果二狗带薪蹲坑跟情书一起掉粪坑了……emmm……
当你引入的外部依赖越多,越容易出现问题,本来没有二狗,这事妥妥的成了,稳了!结果偏偏加个二狗进来,这下凉透了。
MQ挂了,整套系统可能崩溃了,咱们可以考虑跑路了。
所以缺点一:系统的可用性降低。
接着思考第二个问题,假如小豆给三个妹子分别写了一份情书,第一封给A妹子,第二封给B妹子,第三封给C妹子。嗯?这是?
然后让二狗帮忙传递过去,结果二狗把第三封弄丢了,然后把第一封情书给了B妹子,第二封情书给了A,emmm……
同样的,在MQ中,怎么保证消息不丢失,怎么保证消息传递的顺序是对的?引入新的技术,要考虑的问题也会增多。
所以缺点二:系统复杂度提高。
有一天部门要聚餐,大领导对同学们说,我们去XXX饭店干饭,大家没有意见的话我们就这么决定了。结果二狗带薪蹲坑去了,没听到这段,然后同事在二狗的小本本上留言了,这件事对二狗来说是待处理状态。
部门大哥把通知下发成功以后,直接反馈没啥意见。结果二狗回来以后,表示俺不同意。内部处理跟对外反馈结果不统一了,这下玩完了。
一个系统调用了多个系统,请求放入消息队列,发起请求的系统以为请求成功了。最后多个系统在操作数据库的时候,有一个系统事务失败了,怎么办呢?
这也是一个问题:数据的一致性问题。
消息队列是一种相对来说比较复杂的技术,引入以后需要考虑一些问题,有时候需要多思考一下新技术对系统整体架构的影响。但是该用的时候不能怂。关于这里提到的问题,我们后面一一处理。
生活远比想象中的有意思多了