MQ 消息队列的解耦、接口异步处理、削峰

mq 的作用有哪些？缺点有什么？

我们大家都知道作用有解耦、接口异步处理、流量削峰，那么我这里来举例说明下这3个概念分别是什么。

解耦

首先我们看下耦合较高的情况，谁愿意负责A系统？难道被累死么？

负责A系统的大兄弟自作主张引入MQ消息队列后，我管你老王、老张还是老李要什么数据，我放在MQ中，你们要就从MQ中拿，别来烦我、

接口异步处理

首先来看下没有引入MQ时候，假设打开一个网页随意点一下都需要一秒才返回数据，才响应出来，会不会感觉活在70年代，首次感觉就是 what？我在哪？这什么、、、、

使用消息队列后，哎呀我去，难道使用了5G网么，响应真特么快啊、
因为，Ajax请求到系统服务，服务响应给用户的时间为：消息队列耗时+系统服务耗时；

流量削峰：

ok,没有采用MQ，用户并发访问直接爆了服务器，服务器强悍不爆，你硬件读写能跟得上？Mysql并发2000就要GG，直接罢工了；

引入MQ，你干不完是吧，先存起来，等你慢慢干；
通常用于 类似于双11 等并发访问较大时候；
秒杀活动，也要用到；

那这么好一个东西，那就用呗，拿来用，简单的使用没什么问题，但是，背后有好多问题被引申出来；
1、可用性降低，毕竟耗费了资源；
2、MQ宕机了怎么破？
》MQ一死，我整个系统全都完蛋；想过么？

3、若MQ发送消息过程中消息丢失？
》这不出事了么，老王转账10W，这下好了，没有存上钱没了；

1、采用持久化订阅的方式，防止消息丢失、
同时，MQ使用手动签到的方式、Client 真真的接收到消息了，就签到，否则就不签到，直到接收到再签到；
2、这里说的订阅，有人要说了pub/sub 你这只说了Topic发布订阅的模式啊，PTP模式呢？
PTP模式，持久化是不会丢失消息的；

》这里再引申一个问题，怎么保证MQ不会重复发送消息？老王从ATM取了10W，处理消息时候MQ来了个3连发，老王卡上一共30W，一毛不剩了、

这个时候，就要引入一张状态表记录消息处理的状态了，在处理MQ发送的消息时候，我先查下这张表，是不是处理过相同消息，老王已经在某一时间取了10W，UUID相同的消息又来了，我还能再扣老王的钱？
答案显然是不能的；

4、消息的顺序性MQ怎么保证？
》在MQ的模型中，顺序需要由3个阶段去保障：

消息被发送时保持顺序
消息被存储时保持和发送的顺序一致
消息被消费时保持和存储的顺序一致

发送时保持顺序意味着对于有顺序要求的消息，用户应该在同一个线程中采用同步的方式发送。存储保持和发送的顺序一致则要求在同一线程中被发送出来的消息A和B，存储时在空间上A一定在B之前。而消费保持和存储一致则要求消息A、B到达Consumer之后必须按照先A后B的顺序被处理。

5、系统操作原子性怎么保证？
A系统发送一个命令，同时要BCD都执行成功才算完成了一个具体的业务，但是现实情况是BC完成了命令，D执行失败了；

这样看来，MQ问题也不少、如何去解决这些问题呢？
————————————————
版权声明：本文为CSDN博主「打豆豆。」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_42323802/arti...

本作品采用《CC 协议》，转载必须注明作者和本文链接