什么是消息队列?消息队列使用场景是怎样的?

简单粗暴一个例子搞定:

什么是消息队列?

小红是小明的姐姐。

小红希望小明多读书,常寻找好书给小明看,之前的方式是这样:小红问小明什么时候有空,把书给小明送去,并亲眼监督小明读完书才走。久而久之,两人都觉得麻烦。

后来的方式改成了:小红对小明说「我放到书架上的书你都要看」,然后小红每次发现不错的书都放到书架上,小明则看到书架上有书就拿下来看。

书架就是一个消息队列,小红是生产者,小明是消费者。

这就是消息队列。当然,也有侧重点,个人认为消息队列的主要特点是异步处理,主要目的是减少请求响应时间和解耦。所以主要的使用场景就是将比较耗时而且不需要即时(同步)返回结果的操作作为消息放入消息队列。同时由于使用了消息队列,只要保证消息格式不变,消息的发送方和接收方并不需要彼此联系,也不需要受对方的影响,即解耦和。

这带来的好处有:

1.小红想给小明书的时候,不必问小明什么时候有空,亲手把书交给他了,小红只把书放到书架上就行了。这样小红小明的时间都更自由。

2.小红相信小明的读书自觉和读书能力,不必亲眼观察小明的读书过程,小红只要做一个放书的动作,很节省时间。

3.当明天有另一个爱读书的小伙伴小强加入,小红仍旧只需要把书放到书架上,小明和小强从书架上取书即可(唔,姑且设定成多个人取一本书可以每人取走一本吧,可能是拷贝电子书或复印,暂不考虑版权问题)。

4.书架上的书放在那里,小明阅读速度快就早点看完,阅读速度慢就晚点看完,没关系,比起小红把书递给小明并监督小明读完的方式,小明的压力会小一些。

官方点说,这就是消息队列的四大好处:

1.解耦

每个成员不必受其他成员影响,可以更独立自主,只通过一个简单的容器来联系。

小红甚至可以不知道从书架上取书的是谁,小明也可以不知道往书架上放书的人是谁,在他们眼里,都只有书架,没有对方。

毫无疑问,与一个简单的容器打交道,比与复杂的人打交道容易一万倍,小红小明可以自由自在地追求各自的人生。

2.提速

小红选择相信「把书放到书架上,别的我不问」,为自己节省了大量时间。

小红很忙,只能抽出五分钟时间,但这时间足够把书放到书架上了。

3.广播

小红只需要劳动一次,就可以让多个小伙伴有书可读,这大大地节省了她的时间,也让新的小伙伴的加入成本很低。

4.削峰

假设小明读书很慢,如果采用小红每给一本书都监督小明读完的方式,小明有压力,小红也不耐烦。

反正小红给书的频率也不稳定,如果今明两天连给了五本,之后隔三个月才又给一本,那小明只要在三个月内从书架上陆续取走五本书读完就行了,压力就不那么大了。

当然,使用消息队列也有其成本:

1.引入复杂度

毫无疑问,「书架」这东西是多出来的,需要地方放它,还需要防盗。

2.暂时的不一致性

假如妈妈问小红「小明最近读了什么书」,在以前的方式里,小红因为亲眼监督小明读完书了,可以底气十足地告诉妈妈,但新的方式里,小红回答妈妈之后会心想「小明应该会很快看完吧……」

这中间存在着一段「妈妈认为小明看了某书,而小明其实还没看」的时期,当然,小明最终的阅读状态与妈妈的认知会是一致的,这就是所谓的「最终一致性」。

消息队列其中一种模式

那么,该使用消息队列的情况需要满足什么条件呢?

1.生产者不需要从消费者处获得反馈

引入消息队列之前的直接调用,其接口的返回值应该为空,这才让明明下层的动作还没做,上层却当成动作做完了继续往后走——即所谓异步——成为了可能。

小红放完书之后小明到底看了没有,小红根本不问,她默认他是看了,否则就只能用原来的方法监督到看完了。

2.容许短暂的不一致性

妈妈可能会发现「有时候据说小明看了某书,但事实上他还没看」,只要妈妈满意于「反正他最后看了就行」,异步处理就没问题。

如果妈妈对这情况不能容忍,对小红大发雷霆,小红也就不敢用书架方式了。

3.确实是用了有效果

即解耦、提速、广播、削峰这些方面的收益,超过放置书架、监控书架这些成本。

否则如果是盲目照搬,「听说老赵家买了书架,咱们家也买一个」,买回来却没什么用,只是让步骤变多了,还不如直接把书递给对方呢,那就不对了。

所以在软件的正常功能开发中,并不需要去刻意的寻找消息队列的使用场景,而是当出现性能瓶颈时,去查看业务逻辑是否存在可以异步处理的耗时操作,如果存在的话便可以引入消息队列来解决。否则盲目的使用消息队列可能会增加维护和开发的成本却无法得到可观的性能提升,那就得不偿失了。

本文分享自微信公众号 - Linyb极客之路(gh_c420b2cf6b47)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-07-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏宋先生的Coding之旅

JMS--ActiveMQ的简单使用

消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流,并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型,它可以在分布式环境下扩展进程...

14030
来自专栏可持续开发

基础能力决定了程序员发展空间

现在的软件开发人员被戏称为码农,一定程度上面也反应了当前开发人员的技术水平,真正的软件开发不是敲敲代码那么简单。中国还有很多B端商业和工业行业软件都非常落后,智...

6320
来自专栏凯哥Java

RabbitMQ消息中间件技术精讲7 发送自定义属性消息

Auto Delete:如选yes,代表当最后一个监听被移除之后,该Queue会自动被删除

14730
来自专栏7DGroup

性能基础之大型网站技术架构模式

本文整理自《大型网站技术架构 核心原理与案例分析》一书,这本书应该算一本很强的内功秘籍,虽然没有实战教学,但是基础理论扎实了是很重要的,书中观点明确,设计的问题...

11010
来自专栏编程珠玑

进程间通信方式有哪些?

进程能够单独运行并且完成一些任务,但是也经常免不了和其他进程传输数据或互相通知消息,即需要进行通信,本文将简单介绍一些进程之间相互通信的技术--进程间通信(In...

36820
来自专栏物流IT圈

云架构师进阶攻略(1)-架构的三个维度和六个层面

第一个是IT架构,其实就是计算,网络,存储。这是云架构师的基本功,也是最传统的云架构师应该首先掌握的部分,良好设计的IT架构,可以降低CAPEX和OPEX,减轻...

16360
来自专栏Hadoop实操

从这个角度,我终于理解为什么需要Kafka这样的东西了!

我们都知道,数据库中的数据,只要应用程序员不主动删除,就可以任意次读写,多少次都行。数据库还对外提供了很漂亮的接口——SQL ——让程序员操作数据。

23640
来自专栏小闫笔记

python那些包

Anything's possible if you've got enough nerve.

14720
来自专栏Java Web

「消息队列」看过来!

当我试图用一则通俗的比喻来说明这个概念的时候,我想到一个有意思的比喻:如果把队列抽象成一个集合体,那么消息队列也就是一堆消息的集合。按照这个思路我想到了「杂志」...

9420
来自专栏猿GG编程

springboot项目整合rabbitmq学习第一步

rabbitmq在安装好之后就可以开始项目编码啦。springboot项目整合rabbitmq的也是很简单的。

25720

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励