业务体系部队苦熬大，采用微服务的设计思路，分布式的部署方法，拆分了很多服务。随着体量增加，很多中间件不够用，决定引入消息队列中间件。
————————————————————————————
你在什么场景用到消息队列？
————————————————————————————
三个经典场景，一说到消息队列就要想到异步，削峰，解耦。

异步：

本来下单系统只需下单字符，那么随着体量增大，需要加上许多小功能。比如发短信，优惠券减免，积分抵消等等，每个小功能都会增加时间。
全部加起来下单花个几十秒，用户体验就是失败的，那么怎么解决呢？

这就要用到异步了

图片.png
那么为什么不用线程做呢，不是一样吗？
-线程需要调用接口，没加一个都要调用接口重新发布系统。而且全部加载到一起会耦合，排查问题也麻烦.

但是用到消息队列问题就迎刃而解了。
首先，下单，就把支付成功的消息告诉别的系统，他们收到了就去处理，你自己走完流程就行了

图片.png

其他的靠接入的系统，我负责监听就行了。

削峰

把请求放到队列里，能接受多少请求就看服务器能力了。
虽然可能回避平常慢一点，但是不至于服务器崩溃。等高峰过去就没那么大压力了。
像平常流量很低，但是比如双十一流量瞬间涌进来，这时候把速度放慢，给个提示页面。

---

缺点：

前面讲的都是有点，但是总不可能十全十美吧。

1.系统复杂性

本来很简单的系统，我凭空介入了一个中间件，那么我就要去维护，使用中还要考虑兼容问题，消息丢失等。

2.数据一致性

刚才讲了把支付成功的消息告诉别的系统，那么我怎么知道他有没有完成我交代的事呢？
所有服务（优惠券抵用，积分抵用，短信发送）全部完成我才能确认交易成功，这边就需要用到分布式事务了（暂时不动，下次了解）

3.稳定性

中间件万一突然挂了，那么我的系统不是直接崩盘了吗？

---

几款MQ

图片.png

这篇文章引用自b站up主三太子敖丙的文章，写下来用于自己记录一些java的知识点。如有侵权，我立刻删除！

这个是原文章地址：
https://www.bilibili.com/read/cv5086583