RabbitMQ：什么是消息队列MQ？为什么使用消息队列MQ？入门MQ先学哪种？（一）

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