消息队列（MQ）

今天我学习了以下有关MQ的一些知识，自己稍稍总结一下，也希望能给大家带来一点帮助

1.什么是MQ？

在一个业务流程中所有处理请求先作为一个消息发送到MQ，接着处理消息的系统从MQ里获取消息并进行处理。一般来说，我们把发送消息的系统叫做消息生产者，接收处理消息的系统称作消息消费者，而根据消息处理的特点，可以得出两种消息模式：

1）点对点模式：生产者产生的每个消息，只能由一个消费者能消费。

2）发布订阅模式：一个生产者发布的每一个消息，都会发送到订阅了此生产者队列的消费者，这样的话，该生产者的消息都能被对其感兴趣的消费者得到。

2.MQ的优点和缺点

优点：

1） 可以为系统增加通用性的异步业务处理能力

2） 降低了系统的耦合性，无论是在开发期间的引用关系依赖，还是在运行期间的调用关系依赖，都明显可以看出是简化了或者是降低了。通信的双方只要在一开始定义好了消息的数据格式，就可以各自开发测试，最后再集成在一起进行测试，大大降低了沟通的成本，提高了开发的效率。

3） 提高了系统通信的可靠性，无论是通信本身的可靠性（请求响应机制，重试），还是业务意义上的可靠性（处理顺序，事务，失败策略）。

4） 提高了系统的业务缓冲能力，MQ的作为中间的缓冲，业务激增的时候，可以把处理请求缓冲到队列中，再根据业务消费处理能力逐个消息处理，保障系统不会因为突然爆发的大量请求而过载瘫痪，提高系统的持续服务能力。

5） 增强了业务的可扩展性，当业务量激增时，可以扩大消息队列的长度，然后再多装载一些消费者来处理，从而可以直接扩展系统的业务处理能力，而不需要额外的代价。

缺点

1） 系统的复杂度变高了，要考虑的问题变多了。

2） MQ一旦出现故障或者瘫痪，整个系统便跟着瘫痪，根本无法运转。

3） 一致性问题，如果出现要需要多个消费者同时完成一个业务逻辑的情况，其他消费者都完成了，但是有一个消费者迟迟不能完成返回数据，将会导致所有消费者被迫等待，导致效率低下。

***要注意的的是：虽然MQ的应用优点是显然可见的，但是我们不能过分的依赖MQ来提高系统的业务处理能力，很多时候也可以通过提高系统本身的性能来提高整个系统的业务处理能力。

3.具体的应用场景

一句话总结就是：异步处理，应用解耦，削峰填谷，实现日志记录。

我看到一个知乎大佬—敖丙，总结的很好我就直接copy了一下，有兴趣的可以自己去出处膜拜

### 1.异步： 我们之前的场景里面有很多步骤都是在一个流程里面需要做完的，

就比如说我的下单系统吧，本来我们业务简单，下单了付了钱就好了，流程就走完了。

但是后面来了个产品经理，搞了个优惠券系统，OK问题不大，流程里面多100ms去扣减优惠券。

后来产品经理灵光一闪说我们可以搞个积分系统啊，也行吧，流程里面多了200ms去增减积分。

再后来后来隔壁的产品老王说：下单成功后我们要给用户发短信，也将就吧，100ms去发个短信。

再后来。。。（敖丙你有完没完！！！）

反正就流程有点像这样 ↓

你们可以看到这才加了三个，我可以斩钉截铁的告诉你真正的下单流程涉及的系统绝对在10个以上（主流电商），越大的越多。
这个链路这样下去，时间长得一批，用户发现我买个东西你特么要花几十秒，垃圾电商我不在你这里买了，不过要是都像并夕夕这么便宜，真香！

但是我们公司没有夕夕的那个经济实力啊，那只能优化系统了。

Tip：我之前在的电商老东家要求所有接口的Rt（ResponseTime响应时间）在200ms内，超出的全部优化，我现在所负责的系统QPS也是9W+就是抖动一下网络集群都可能炸锅那种，RT基本上都要求在50ms以内。

大家感受一下这个QPS。

嗯不错，链路长了就慢了，那你怎么解决的？

那链路长了就慢了，但是我们发现上面的流程其实可以同时做的呀，你支付成功后，我去校验优惠券的同时我可以去增减积分啊，还可以同时发个短信啊。

那正常的流程我们是没办法实现的呀，怎么办，异步。

你对比一下是不是发现，这样子最多只用100毫秒用户知道下单成功了，至于短信你迟几秒发给他他根本不在意是吧。

小伙子我打断你一下，你说了异步，那我用线程，线程池去做不是一样的么？
诶呀，面试官你不要急嘛，我后面还会说到的，骚等。(大家想看的话去出处那里找作者的下一期)

解耦：

既然面试官这么问了，我就说一下为啥我们不能用线程去做，因为用线程去做，你是不是要写代码？

你一个订单流程，你扣积分，扣优惠券，发短信，扣库存。。。等等这么多业务要调用这么多的接口，每次加一个你要调用一个接口然后还要重新发布系统，写一次两次还好，写多了你就说：老子不干了！

而且真的全部都写在一起的话，不单单是耦合这一个问题，你出问题排查也麻烦，流程里面随便一个地方出问题搞不好会影响到其他的点，小伙伴说我每个流程都try catch不就行了，相信我别这么做，这样的代码就像个定时炸弹 ，你不知道什么时候爆炸，平时不炸偏偏在你做活动的时候炸，你就领个P0故障收拾书包提前回家过年吧。
Tip：P0—PN 是互联网大厂经常用来判定事故等级的机制，P0是最高等级了。

但是你用了消息队列，耦合这个问题就迎刃而解了呀。

哦，帅丙怎么说？

且听我娓娓道来：

你下单了，你就把你支付成功的消息告诉别的系统，他们收到了去处理就好了，你只用走完自己的流程，把自己的消息发出去，那后面要接入什么系统简单，直接订阅你发送的支付成功消息，你支付成功了我监听就好了。

那你的流程走完了，你不用管别人是否成功么？比如你下单了积分没加，优惠券没扣怎么办？

问题是个好问题，但是没必要考虑，业务系统本身就是自己的开发人员维护的，你积分扣失败关我下单的什么事情？你管好自己下单系统的就好了。
Tip：话是这么说，但是这其实是用了消息队列的一个缺点，涉及到分布式事务的知识点，我下面会提到。

削峰：

就拿我上一期写的秒杀来说（暗示新同学看我上一期），你平时流量很低，但是你要做秒杀活动00 ：00的时候流量疯狂怼进来，你的服务器，Redis，MySQL各自的承受能力都不一样，你直接全部流量照单全收肯定有问题啊，直接就打挂了。

那怎么办？

简单，把请求放到队列里面，然后至于每秒消费多少请求，就看自己的服务器处理能力，你能处理5000QPS你就消费这么多，可能会比正常的慢一点，但是不至于打挂服务器，等流量高峰下去了，你的服务也就没压力了。

你看阿里双十一12：00的时候这么多流量瞬间涌进去，他有时候是不是会慢一点，但是人家没挂啊，或者降级给你个友好的提示页面，等高峰过去了又是一条好汉了。

4.不同MQ中间件的差别

贴上一位大佬的总结表格：https://www.cnblogs.com/laojiao/p/9573016.html







声明：本文仅用于学习和分享。如有表述或者技术上的错误，请各位大佬多多指点。