0. 引言
MQ(Message Queue)：消息队列，如今在各类业务场景中已经被广泛使用，特别在并发量日益增涨的业务和微服务架构中，消息队列能够帮助我们解决很多传统方式所不能解决的问题。
所以今天，我们就开始学习消息队列啦
1. 什么是消息队列？
学习之前，我们要先了解什么是消息队列，学习过java的同学应该知道，有一种数据结构叫队列（Queue），队列保持着先进先出的原则。消息队列呢实际上就是一种队列结构，这个队列中盛装的就是我们的消息。
什么是消息呢？通俗一点就是我们要传递的数据，可以是一个字符串，也可以是一个自定义的对象。
当然既然消息队列是用来传递数据的，那么队列就会有两端：一端生产消息，我们称之为生产者，一端接收消息并且利用该消息进行后续的处理，我们称之为消费者。先放入到消息队列中的消息，就会先被消费掉。如下图所示
2. 为什么要使用消息队列？
在讲述这个问题之前，我们先引入几个场景：
1、异步调用
场景一：我们有一个服务A，服务A需要调用服务B,C，三个服务的执行时间分别是1s，2s，3s。那么用户调用服务A时，需要等待6s后才会得到执行完毕的反馈。想象一下你是这个用户，做一个操作让你等待6s，你会怎么想？如果你还挺有耐心的，6s能接受，那如果执行时间是1s,2min,3min，你需要等待5分1s才能得到这个回执，你还愿意等吗？5分钟，面都泡好了！
所以我们引入了一个服务异步调用的机制，什么是异步呢？就是服务A调用服务B,C时，不用再等待B,C执行完毕后才返回回执，服务A执行完，将服务B,C所需要的数据发送给他们，然后不等待完成，只要服务A自己的逻辑执行完成后就返回结果，这样的执行方式，我们称之为异步调用。
那么这个异步调用怎么实现呢？如何保证异步调用的数据一定能够被B,C接收到呢？要知道因为服务A不会监控B,C的执行结果，所以一旦数据丢失了，那么服务A并不知道B,C都没收到数据，也没执行，也不问题大了嘛。
解决办法就是MQ啦～
我们把服务B,C所需要的数据传送到对应的消息队列中，然后让服务B,C分别监控他们自己的队列，当有消息进来时，就会触发服务B,C的消息消费逻辑，而进行下一步的业务处理，那么MQ又是如何保证消息不丢失呢？这个我们就后续再来详解，今天我们先掌握MQ的基础概念。
2、流量削峰
场景2：另一个场景就是高并发的场景，想象下我们某一个时段有海量的请求发送过来，如果请求直接打到服务上，就会导致服务承受不住而宕机。
有同学会想啦，那我不能用分布式的概念，来扩展几个服务不就好了嘛。但是问题在于这样的海量请求只是短时间的，更多时间的平常运行中是不会有这么多请求的，那么如果我们为了满足这个短时间的需求，而增加服务器配置的话，是不是有点得不偿失呢？
于是乎，我们引入了MQ，将这些海量的请求数据先放到MQ中，然后服务一点一点的消费，每次消费服务能够承受的数量，这样就能将巨大的流量削减为一小部分。这样的操作我们也成为流量削峰。
3、服务解耦
场景3：与场景1类似，我们有服务A，会调用服务B,C。如果服务B,C出现报错，就会导致服务A也报错，而B,C的业务逻辑与服务A关系不大，比如下订单后，要增加用户的积分，这个增加用户积分的操作并没有那么重要，甚至可以晚一点执行都可以，如果因为积分服务而导致订单服务报错，有点不划算
于是我们想象，如果能够把对服务B,C的调用剥离出去，其调用不影响服务A的执行，也样的操作称为服务解耦，那我们的问题就解决啦。于是又是MQ来帮忙
道理类似，我们把服务B,C需要的数据，传递到消息队列中，服务A执行完就直接反馈，而B,C的调用通过监控消息队列的数据来实现。
3. 初学者优先学习哪种MQ?
当前市面上常用的MQ有：ActiveMQ,RabbitMQ,RocketMQ,Kafka这四种
mq的概念和原理是相差不大的，只是不同的mq在不同的业务场景中有不同的表现，比如RabbitMQ适用于低延迟的场景，RocketMQ适用于高并发场景，并且是唯一支持分布式事务的消息队列，Kafka更是为了大数据而生的消息队列，是吞吐量最大的消息队列。
所以针对mq的学习，更多的是看大家公司的业务场景，以及自己未来可能接触的更多的业务场景。如果对于高并发没有那么大的要求，个人建议大家可以从RabbitMQ入手，也就是我们后续要带大家快速上手的MQ.
而ActiveMQ的话，是Apache公司早些时候的产品，在其又推出ActiveMQ之后，社区的维护就更少了，RabbitMQ有着轻量，入门快的特点，如果MQ不是公司的重点业务支撑中间的话，那么RabbitMQ毫无疑问，是我们入门的最佳选择。
但如果大家公司对于并发场景有要求，且对MQ的使用较频繁，那么由alibaba开源的RocketMQ，是不错的选择，其支撑住了中国的双11挑战，足以证明它的实力，现在RocketMQ已经贡献给Apache开源基金会了，由Apache来维护，但近期其开源社区并不活跃，所以如果选用RocketMQ还需要考虑公司是否有足够的技术实力来支持RocketMQ
如果你学习的方向是大数据方向，那么不用怀疑，Kafka就是你的命中注定！Kafka也常用于实时的数据收集和日志采集的场景，比如ELK+Kafka的应用。
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机并发量 | 万级 | 万级 | 10万级 | 10万级 |
| 延迟 | 毫秒级 | 微秒级 | 毫秒级 | 毫秒级 |
| 可用性 | 高，主从架构 | 高，主从架构 | 非常高，分布式架构 | 非常高，分布式架构 |
| 消息可靠性 | 低概率丢失消息 | 基本不丢失 | 优化后可做到0丢失 | 优化后可做到0丢失 |
| 应用场景 | MQ基础应用场景 | 低延迟业务场景 | 高吞吐业务场景 | 高吞吐，大数据领域，数据、日志采集 |
好了，本期的分享也就到此结束了，后续我们以更常用的RabbitMQ来入门，带大家学习MQ！
关注专栏，了解更多动态
参考文章
https://github.com/doocs/advanced-java/blob/main/docs/high-concurrency/why-mq.md
