您现在的位置是:网站首页>编程语言

消息队列的使用场景大概是怎样的?

编程语言阿文2019年4月14日414浏览

简介消息队列的使用场景是什么?我们整天说消息队列可以处理好多事情,可以提高系统的处理能力,但是消息队列的工作原理是什么?能处理哪一类事情?以下是我在社区看到比较一段比较经典容易懂的一个案例.如下

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

    我们整天说消息队列可以处理好多事情,可以提高系统的处理能力,但是消息队列的工作原理是什么?能处理哪一类事情?

    以下是我在社区看到比较一段比较经典容易懂的一个案例.如下

    小红是小明的姐姐。

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

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

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

    这带来的好处有

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

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

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

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


    消息队列的四大好处

        1.解耦.每个成员不必受其他成员影响,可以更独立自主,只通过一个简单的容器来联系。小红甚至可以不知道从书架上取书的是谁,小明也可以不知道往书架上放书的人是谁,在他们眼里,都只有书架,没有对方。毫无疑问,与一个简单的容器打交道,比与复杂的人打交道容易一万倍,小红小明可以自由自在地追求各自的人生。

        2.提速.小红选择相信「把书放到书架上,别的我不问」,为自己节省了大量时间。小红很忙,只能抽出五分钟时间,但这时间足够把书放到书架上了。

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

        4.削峰.假设小明读书很慢,如果采用小红每给一本书都监督小明读完的方式,小明有压力,小红也不耐烦。反正小红给书的频率也不稳定,如果今明两天连给了五本,之后隔三个月才又给一本,那小明只要在三个月内从书架上陆续取走五本书读完就行了,压力就不那么大了。

    使用消息队列也有其成本

        1.引入复杂度.毫无疑问,「书架」这东西是多出来的,需要地方放它,还需要防盗。

        2.暂时的不一致性.假如妈妈问小红「小明最近读了什么书」,在以前的方式里,小红因为亲眼监督小明读完书了,可以底气十足地告诉妈妈,但新的方式里,小红回答妈妈之后会心想「小明应该会很快看完吧……」这中间存在着一段「妈妈认为小明看了某书,而小明其实还没看」的时期,当然,小明最终的阅读状态与妈妈的认知会是一致的,这就是所谓的「最终一致性」。


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

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

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

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

    2.容许短暂的不一致性

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

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

    3.确实是用了有效果

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

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

除了这些之外,比较常用的就是起到消峰时需要用到:比如你的服务器一秒能处理100个订单,但秒杀活动1秒进来1000个订单,持续10秒,在后端能力无法增加的情况下,你可以用消息队列将总共10000个请求压在队列里,后台consumer按原有能力处理,100秒后处理完所有请求(而不是直接宕机丢失订单数据)。技术都是解决问题的,消息队列解决的是将突发大量请求转换为后端能承受的队列请求。

举个例子:

在KFC点餐

    我:"要一个香辣鸡腿堡,一份辣翅,一个可乐加冰,打包带走"。

    前台MM:"好的,一共45块钱"。

    我:付钱。

    前台MM:“你好,这是您的号码78号,请您在旁边等待,下一位!”。

    我:玩手机,刷微博, (1分钟过去...)

    前台MM:“76号顾客的好了!!”(3分钟过去...)

    前台MM:“77号顾客的好了!!”(4分钟过去...)

    前台MM:“78号顾客的好了!!”。

    我:拿着打包好的汉堡就走啦,别说可乐打包的挺人性化。

中间的流水线是消息队列。

生活中这种例子很多,比如我们在食堂排队打饭基本上一个人先选菜然后师傅打菜打饭 然后刷卡 换下一个人,这里速度就卡着打饭的人选菜速度,师傅打菜速度,结算速度上了。如果我们分开两队一队去选菜然后结账,然后拿着小票去打饭窗口,师傅根据小牌直接打饭打菜,不用等待你要选什么菜,算金额之类的。这样能提高好大一部分速度。



标签: 消息队列

很赞哦3

上一篇: 么有了

下一篇: 么有了

相似阅读

评论文明上网,理性发言0条评论