业务体系部队苦熬大,采用微服务的设计思路,分布式的部署方法,拆分了很多服务。随着体量增加,很多中间件不够用,决定引入消息队列中间件。
————————————————————————————
你在什么场景用到消息队列?
————————————————————————————
三个经典场景,一说到消息队列就要想到异步,削峰,解耦。
异步:
本来下单系统只需下单字符,那么随着体量增大,需要加上许多小功能。比如发短信,优惠券减免,积分抵消等等,每个小功能都会增加时间。
全部加起来下单花个几十秒,用户体验就是失败的,那么怎么解决呢?
这就要用到异步了

那么为什么不用线程做呢,不是一样吗?
-线程需要调用接口,没加一个都要调用接口重新发布系统。而且全部加载到一起会耦合,排查问题也麻烦.
但是用到消息队列问题就迎刃而解了。
首先,下单,就把支付成功的消息告诉别的系统,他们收到了就去处理,你自己走完流程就行了

其他的靠接入的系统,我负责监听就行了。
削峰
把请求放到队列里,能接受多少请求就看服务器能力了。
虽然可能回避平常慢一点,但是不至于服务器崩溃。等高峰过去就没那么大压力了。
像平常流量很低,但是比如双十一流量瞬间涌进来,这时候把速度放慢,给个提示页面。
缺点:
前面讲的都是有点,但是总不可能十全十美吧。
1.系统复杂性
本来很简单的系统,我凭空介入了一个中间件,那么我就要去维护,使用中还要考虑兼容问题,消息丢失等。
2.数据一致性
刚才讲了把支付成功的消息告诉别的系统,那么我怎么知道他有没有完成我交代的事呢?
所有服务(优惠券抵用,积分抵用,短信发送)全部完成我才能确认交易成功,这边就需要用到分布式事务了(暂时不动,下次了解)
3.稳定性
中间件万一突然挂了,那么我的系统不是直接崩盘了吗?
几款MQ

这篇文章引用自b站up主三太子敖丙的文章,写下来用于自己记录一些java的知识点。如有侵权,我立刻删除!
这个是原文章地址:
https://www.bilibili.com/read/cv5086583
网友评论