【消息队列】什么是消息队列

本文最后更新于2020年11月26日,可能由于时间等因素导致内容失效,请自行辨别或联系作者。

前言

本文是MQ系列的第一篇,做为一个刚刚工作不久的萌新,日常的开发任务由简单的增删改查接口,渐渐转变为了涉及MQ的逻辑。但仅仅是会用MQ已经满足不了我了,有这么好的机会自然想掌握的更深入一点。于是,准备从零开始,一点点的学习RocketMQ,从基本概念,到安装部署使用,再到源码学习……

当然,做为一个萌新,文章中可能会出现一些错误的地方,欢迎各位大佬一起讨论、指正。同时,对于引用的出处,我也会放到文章的最后。

什么是消息队列

消息队列,一般我们简称为MQ,也就是Message Queue的缩写。而队列,是一种先进先出的数据结构。

那么消息队列,就是存放消息的一种先进先出的数据结构,名词理解起来应该不难。

为什么要用消息队列

解耦

假设有一个系统A,会产生一条关键的数据,例如:订单信息、用户信息等。此时,有很多系统,都需要用到系统A的这个数据,假设目前有B、C两个系统需要,那就需要系统A把数据分别发送给这两个系统。

对应的伪代码,可能是这样的

过几天后,系统D跑来说自己也要这个数据,那好,再发给系统D

又过了几天,系统B说,我们不要了,别发给我们了;再过几天,系统C说,那个,我们只需要上午十点到下午四点产生的订单,其他的别发给我们哈…

系统A在发送时,还要考虑,如果发送的某个系统服务挂了咋办?重试?补发?又是一大堆逻辑…

最后,求:系统A程序员的心里阴影面积?还不提桶跑路么?

使用消息队列后,系统A就完全不需要管上面这些问题了,它只需专注自己的核心功能就行,对于其他系统来说,系统A的核心功能就是“产生关键数据”。整体结构,就变成了下图所示

系统A产生了订单后,把相关信息发送到消息队列中,至于哪些系统需要用到这个数据,它一点都不需要关心。同时,对于其他系统关于订单信息的差异化处理,系统A也完全不需要管,由不同的系统,自己去实现即可。哪怕时其他系统服务挂了,对系统A来说,也一点影响都没有。这样一来,就达到了解耦的目的。

异步

还是上面的例子,对于系统A,产生一个订单信息,可能只需要50ms,但发送给其他系统,可能远不止50ms,假设要200ms,那发送给三个系统,就是600ms,那对于系统A来说,一共需要花650ms,而其中的600ms其实对自己来说,是无关紧要的。

如果引入消息队列,系统A只需要把订单信息发送到队列即可,可能花费50ms,那一共也才100ms。至于其他系统要花多少时间,不是系统A需要考虑的问题。

削峰/限流

特别是对于一些电商类的项目,平时请求可能每秒最多也就1K,但是一到大促/活动,请求量就会成倍的增加,假设每秒5K。每秒5K的请求,直接到数据库,对于一般的Mysql来说,早就被这流量打死了,整个系统直接崩溃。

如果引入消息队列,那不论每秒多少请求,我们都直接放到消息队列中,而其他系统,根据自己的能力,从队列中获取信息,这样就不会让系统直接崩溃了。

消息队列有哪些缺点

系统可用性降低

随着引入消息队列,万一MQ挂了,那对于系统A的这部分功能,就直接崩溃了。

系统复杂度提升

增加了消息队列后,会引申出其他的一些问题,例如:是否会重复消费?消息会不会丢失?丢失了怎么办?怎么保持顺序性?失败了是否需要重试?等等…

一致性问题

对于一些复杂的场景,需要不同系统都返回成功,才算真正的成功,那假设系统B、系统C返回成功了,但偏偏系统D返回失败,那到底算成功还是失败?这条数据的结果在不同的系统里可能就不一致了。

如何解决这些缺点

萌新段位不够,这里只是简单的谈一下。

首先是关于选型,消息队列有好几种,不同的类型,侧重点是不同的,根据具体的业务需求,进行选择,部署也肯定需要集群部署;

其次是对于一些大型公司来说,一般都会自己开发或者二次开发开源的消息队列,对于上述的问题,可以着重进行解决;

最后,还可以引入一些分布式框架,来解决数据的一致性问题。

参考

什么是消息队列?

为TA充电
共{{data.count}}人
人已赞赏
Java编程语言

图仓——一个集成图片上传、分发、管理的图片仓库

2020-11-14 23:31:26

消息队列编程语言

【消息队列】本地部署RocketMQ

2020-11-26 22:17:27

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
今日签到
有新私信 私信列表
搜索