中间件-消息队列
消息队列中间件是分布式系统中重要的组件,主要解决应用耦合、异步消息、流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。
目前在生产环境,使用较多的消息队列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ等。
消息队列应用场景:异步处理、应用解耦、流量削锋、日志处理和消息通讯。
以上概念是转自https:–//kb.cnblogs.com/page/569026/。
在此次熟悉项目中,其中有一部分是关于Middlewares。这。。之前咱也没见过啊,于是百度一番。但是关于中间件的介绍多种多样,但是与项目中胡匹配度却不高。但是在一次偶然的机会中,发现其中一个模块MessageQueue(我一想这不就是消息队列的意思嘛,哈哈哈,正好就百度到上面的链接,人家说的还蛮清楚的,至少理解了消息队列是啥,手动点赞。),依赖项是RabbitMQ(5.1.0)。
以下是针对以上链接内容我自己的理解,仅供我自己日后参考,可信度不高,希望大神补充。--------------------------------------------------------------
首先消息队列的应用场景:
-
异步处理:
其中提及串行方式和并行方式,这两者本身在效率方面就是并行方式效率高一些。那为啥异步处理能比并行方式处理效率还高呢??明明人家都并行处理的说呢,哭唧唧。在理解消息队列后,顿悟!原来加入消息队列以后,直接将有用的信息写入消息队列,就直接返回执行结果啦,个人理解就是先将信息放在消息队列中,不-用等到真的接收到实时的操作返回结果,这种情况下只消耗了将消息写进消息队列的时间,那是板上钉钉的快多啦!!(也许到这里有人会有疑问,那返回结果可咋办呢,哈哈哈哈,好巧,我也有这个疑问。后来了解到,可以在消息队列中设置规则,比如消息队列里消息过期时间啊,设置一个标志用来接收订阅方返回的消息呀啥的,真鸡智!) -
应用解耦:
这个大家应该很容易理解,因为爱网购的网狗们就比较熟悉这个。我们在淘宝下单应该都没失败过吧,如果失败了就是心里大骂180遍,想花钱都不行!!!仔细想想,万一我们下单的时候马爸爸的库存系统崩了,是不是真的下不了单呢,那肯定不能,那损失可大了。所以顺着原作者思路走,确实是这个理儿,下单归下单,库存归库存。用户下单以后,即使当时库存系统崩了,但是订单信息我们写入消息队列啦,不用管库存啥的啦,马爸爸一点都不方的,咱再从消息队列多转储几次就好啦!!等到库存系统正常减少以后,返回一个信息到消息队列就好啦!!多完美的剁手旅程!! -
流量削锋
马爸爸搞秒杀活动啦!!但是相信大家都会经历过进不了购物页面,或者进去了不小心退出来就再也进不去的场景吧,嗯,是的,痛心疾首!!现在我算是知道了商家的小九九。原来可能利用了消息队列直接拒绝了我们的消息请求呢!这个仇我记住了!!服务器在接收我们这些小白用户的请求后,将我们的请求写入了消息队列,如果消息队列中消息数量超过最大数量,不幸运的我们就被直接拒绝啦,或者直接跳到错误界面。。。不过现在想想好像还没有直接进入过错误界面,可能是出于用户体验的考虑,直接跳转到空白页面了吧。。。太惨了,每一次抢不到的秒杀都是人间悲剧!! -
日志处理
大量日志传输的情况我是真的没有遇到过,毕竟人家还太小没遇到过这种大风大浪。不过顺着上面这几种情况的思路想想,无非就是,先把信息找个仓库先存着呗,以后再让仓库再慢慢转发,这个仓库就是消息队列啦!!此处解释堪称完美!! -
消息通讯
没想到消息队列这么好用,原作者提到消息队列一般都内置了高效的通信机制,因此可以用在纯的消息通讯(ps:我是真的没理解纯的是啥意思!!一脸问号!)。实现点对点消息队列、聊天室等。
点对点通讯:两个人共用一个消息队列。
聊天室通讯:好多人共用一个消息队列。
以上应用场景讲完------
(以上是有拖延症的我一个星期前写的了,啊,时光飞逝。。项目做着做着就只关注逻辑层面,项目架构慢慢的又忽视研究了。)
关于项目中使用到的RabbitMQ,这里不做更详细的描述,毕竟作者只是看着跟项目中匹配并跟着看了一遍,没有自己的一点理解,各位可以自行看?链接理解。
终于结束了,希望日后进步的自己可以对这边的不明不白做更详细的补充,这也是我写博客的初衷,记录自己项目的磕磕绊绊与懵懂触动,留待以后恍然大悟。之前上学老师就经常说,现在不懂没关系,以后接触的多了再联想一下就会柳暗花明!