📝个人主页：五敷有你      

 🔥系列专栏：MQ

⛺️稳中求进，晒太阳

定义

消息队列：一般我们简称为MQ(Message Queue)

Message Queue :消息队列中间件，很多初学者认为，MQ通过消息的发送和接受来实现程序的异步和解耦。mq主要用于异步操作，这个并不是mq的真正目的，这只是mq的应用，mq的真正目的是为了通讯。

使用场景

消息队列的三个最主要的作用：异步、消峰、解耦。

传统设计

这种设计模式有一个很大的优势：代码简单，出现问题容易定位。但是也有劣势。

从三高(高并发，高性能，高可用)三个方面去评审这个设计

• 高可用：这些服务假如挂掉（宕机或网络波动），就意味着请求失败，用户体验感极差。
• 高并发：因为这些操作都是由一个线程（主线程）去执行这些操作，所以当我们的QPS如果很高的话，很容易造成超时。
• QPS：系统每秒钟收到的请求。
• 高性能：因为上面这种设计模式是串行的，假设我的每次网络传输耗时200ms，业务处理需要20ms，完成上面那些操作需要耗时2s，这样用户体验也会很差（想象一下每次下单都需要等2s）,如果用户下单后的操作越来越多，耗时只会越来越高

所以在一个大型的互联网项目中，以上设计是完全不可取的（非核心模块除外）。

并行处理调优

既然上面说的是串行模块，那么我们用自己的线程池把他改为并行的设计，再看评审一下。

所谓的并行设计就是原来由一个线程去串行做的逻辑，改为多个线程并行去做。

高可用：这些服务假如有一个服务挂掉（宕机或者网络波动），理论上讲，如果补偿服务做的出色的话，还是满足高可用的。（可以用try,catch）

高并发：相比上面的设计，系统的吞吐量可以达到了很大程度上的提升。

高性能：相比上面的设计，因为很多业务是并行执行的，所以相当于只有200*2+20，就可以返回。

上面这个设计看起来还是不错的设计，所以在很多这种串行调用，多次io的时候，我们就可以采用这种方案，上面这种设计也是多线程的一种实战应用。

下面来分析一下弊端：

1.系统的可扩展性太差了。上面只是列举了4步，但是实际上会有几十步，这几十步放到代码里就会像屎堆一样，可维护性极差。每次加一个步骤，都要多调一个接口，然后重新发布一下服务。

2，系统的耦合性太高了。想象一下，几十个http调用放到一起并发执行，很有可能会影响其他的点，尤其是淘宝京东这种秒杀敏感的业务，和钱挂钩的业务，很容易出现p0级别的bug。

3，使用的业务本身的线程池，在并发很多的情况下，容易造成cpu的竞争。

于是就有了进一步演化。

多线程处理三种方案：

1，主线程交给线程池里的线程去执行时，主线程等待，等我所有任务，执行完之后，主线程再去接着执行（查询做聚合的时候）

2，主线程交给线程池去处理，就不管了（我要删除或修改一个东西，需要耗时2s）

3，主线程交给线程池去处理，主线程继续去执行其他的任务，等线程池里的任务执行完之后，去通知主线程，主线程在接着去执行后续的逻辑。

消息队列

咱们从继续从三高的层面去审视一下这个设计：

高可用：当我系统里的一个模块宕机了，不会影响到我其他服务。（可以通过数据补偿或者分布式事务来保证数据最终一致性）

高性能：用户下单，将下单所需要的数据都放到消息队列里，就直接返回了，所有耗时相当于就是网络传输所耗时。

高并发：由于消息队列不处理任何业务上的逻辑，所有他支持的并发是百万级别的。假如有100万个用户下单，100万的数据放到消息队列里，连接消息队列的服务慢慢消费即可，也不至于造成瞬间有百万请求进来，将我的服务压垮。

消息队列的一些术语：

producer	消息生产（发布）者
consumer	消息消费（订阅）者

三大优点：

解耦：就像高可用里面说的一样，发淘金币服务挂了，关下单什么关系，发淘金币服务挂了，我还是可以正常下单，只不过后期可以数据补偿或者分布式事务去解决这个问题。

削峰：比如说我平时服务就只能支撑几万的qps，像淘宝京东那种秒杀，那时候服务突然打进来（如果采用第二种方案）那服务就会直接被压死了。但是如果采用消息队列，这秒杀进来的所有的请求都不会直接打到具体服务上，都会先打到消息队列里，然后我后面的服务再慢慢消费。

可以看看淘宝京东双11秒杀的时候，是不是有的时候慢是慢了点，但是服务起码没挂。等我秒杀结束之后，服务还能正常运转。

消息队列就像是一个三峡大坝，用来拦截上游给的压力。

异步：连接消息队列的服务可以异步去执行。而且每次多增加一个步骤，我下单的代码是不需要动的，只需要再增加一个消费者即可。

消息队列也并不是全是优点，也有一些缺点。

缺点

1，增加了系统复杂性。

所以说如果说你的业务量不大，并发也不高，就没必要使用消息队列。

2，事务问题。

事务问题其实是分布式系统肯定会存在的一个问题，只不过消息队列更严重一些。一般解决方案有两种，第一种就是采用分布式事务，这个下单的里涉及的所有服务放到一个事务里面，要么都成功，要么都失败。第二种就是，消费者做好合理的数据补偿措施，比如说，消息重试，人工刷数据等等。

3，可用性

刚才讲了解耦，其实是系统的各个模块之间的解耦，但是这些模块都和消息队列关联，万一消息队列挂了，就真的下不了单了。为了保证可用性，我们可以采用消息队列集群，前端流量限流等，后面会介绍。

几种常见的消息队列

其中kafka和rocketmq现在在互联网大厂使用最广泛，因为吞吐量大。

MQ的两种流派

1、有broker的

broker是什么，可以理解为是一个中转站。生产者将消息发送给他就结束自己的任务了，broker将消息主动推送给消费者（具体的将消息推送到哪个队列，或者说消费者主动请求）

重topic

必须要有topic

kafka：全球消息处理性能最快的一款mq

rocketmq：阿里内部的一个大神根据kafka的执行原理手写的，性能与kafka差不多，但是功能上比kafka要多，比如说顺序消费。

轻topic

可以没有topic，topic只是一种中转模式

rabbitmq

2、无broker的

zeromq：没有使用broker，是直接使用socket进行通信。