消息队列MQ快速入门

Myth丶恋晨 2023-10-06 13:47 38阅读 0赞

#### 文章目录 ####

*   *   *   *   *  1. 消息队列是什么
                 *  2. 消息队列作用
                 *  3. 消息队列优点以及缺点
                 *   *  3.1 优点
                     *  3.2 缺点
                 *  4. 消息队列应用场景
                 *   *  4.1 异步处理
                     *  4.2 应用解耦
                     *  4.3 流量削锋
                     *  4.4 消息通讯
                 *  5. 消息队列的两种模式
                 *   *  5.1 点对点模式
                     *  5.2 发布/订阅模式
                 *  6.消息队列中间件有哪些，有什么区别？

###### 1. 消息队列是什么 ######

1.  消息队列是一个存放消息的容器，当我们需要时可以取出使用。
2.  消息队列可以完成异步处理，提高系统性能。
3.  消息队列可以削峰平谷，消息队列可以缓解短时间内高流量压垮应用

###### 2. 消息队列作用 ######

1.  通过异步处理提高系统性能（削峰、减少响应所需时间），即通过异步处理，将短时间高并发产生的事务消息存储在消息队列中，从而削平高峰期的并发事务。例如：电子商务中的秒杀，促销活动
2.  降低系统耦合性
3.  消息队列使利用发布-订阅模式工作，消息发送者（生产者）发布消息，一个或多个消息接受者（消费者）订阅消息. 消息发送者（生产者）和消息接受者（消费者）之间没有直接耦合，消息发送者将消息发送至分布式消息队列即结束对消息的处理，消息接受者从分布式消息队列获取该消息后进行后续处理，并不需要知道该消息从何而来。对新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响，从而实现网站业务的可扩展性设计。

###### 3. 消息队列优点以及缺点 ######

###### 3.1 优点 ######

1.  应用耦合：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；
2.  异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；
3.  限流削峰：广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况；那个
4.  消息驱动的系统：系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理；

###### 3.2 缺点 ######

1.  系统可用性降低： 系统可用性在某种程度上降低，在加入MQ之前，你不用考虑消息丢失或者说MQ挂掉等等的情况，但是，引入MQ之后你就需要去考虑了！
2.  系统复杂性提高： 加入MQ之后，你需要保证消息没有被重复消费、处理消息丢失的情况、保证消息传递的顺序性等等问题！
3.  一致性问题：消息队列可以实现异步，消息队列带来的异步确实可以提高系统响应速度。但是，万一消息的真正消费者并没有正确消费消息，这样就会导致数据不一致的情况了!

###### 4. 消息队列应用场景 ######

###### 4.1 异步处理 ######

例如：用户注册  
场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种 1.串行的方式；2.并行方式  
**4.1.1 传统方式**

1.  串行的方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端  
    ![在这里插入图片描述][20200728211514519.png]
2.  并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTM4MDk3_size_16_color_FFFFFF_t_70]

**4.1.2 引入消息队列**:将不是必须的业务逻辑，异步处理。  
![在这里插入图片描述][20200728211606760.png]

###### 4.2 应用解耦 ######

例如：用户下单  
场景说明：用户下单后，订单系统需要通知库存系统。传统的做法是，订单系统调用库存系统的接口，如下图  
![在这里插入图片描述][20200728211616603.png]

**4.2.1 传统模式缺点**

*  假如库存系统无法访问，则订单减库存将失败，从而导致订单失败
 *  订单系统与库存系统耦合  
    **4.2.2 引入队列**  
    ![在这里插入图片描述][20200728211628482.png]
 *  订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户下单成功
 *  库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作
 *  假如：在下单时库存系统不能正常使用。也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦

###### 4.3 流量削锋 ######

例如：秒杀活动  
应用场景：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在应用前端加入消息队列。

*  可以控制活动的人数
 *  可以缓解短时间内高流量压垮应用  
    ![在这里插入图片描述][20200728211638513.png]
 *  用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面
 *  秒杀业务根据消息队列中的请求信息，再做后续处理

###### 4.4 消息通讯 ######

消息通讯是指，消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。比如实现点对点消息队列，或者聊天室等

*  点对点通讯  
    ![在这里插入图片描述][20200728211644973.png]
 *  聊天室通讯  
    ![在这里插入图片描述][20200728211650766.png]

###### 5. 消息队列的两种模式 ######

消息队列包括两种模式，点对点模式（point to point， queue）和发布/订阅模式（publish/subscribe，topic）

###### 5.1 点对点模式 ######

*  点对点模式三个角色
 *  消息队列
 *  发送者 (生产者)
 *  接收者（消费者）  
    ![在这里插入图片描述][20200728211706740.png]

5.1.1 点对点模式特点：

*  每个消息只有一个接收者（Consumer）(即一旦被消费，消息就不再在消息队列中)；
 *  发送者和接收者间没有依赖性，发送者发送消息之后，不管有没有接收者在运行，都不会影响到发送者下次发送消息；
 *  接收者在成功接收消息之后需向队列应答成功，以便消息队列删除当前接收的消息；

###### 5.2 发布/订阅模式 ######

*  发布/订阅模式下包括三个角色
 *  角色主题（Topic）
 *  发布者(Publisher)
 *  订阅者(Subscriber)  
    ![在这里插入图片描述][2020072821171416.png]

5.2.1发布/订阅模式特点：

*  每个消息可以有多个订阅者；
 *  发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。
 *  为了消费消息，订阅者需要提前订阅该角色主题，并保持在线运行；

###### 6.消息队列中间件有哪些，有什么区别？ ######

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTM4MDk3_size_16_color_FFFFFF_t_70 1]  
综上，各种对比之后，有如下建议：

一般的业务系统要引入 MQ，最早大家都用 ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了；

后来大家开始用 RabbitMQ，但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高；

不过现在确实越来越多的公司会去用 RocketMQ，确实很不错，毕竟是阿里出品，但社区可能有突然黄掉的风险（目前 RocketMQ 已捐给 Apache，但 GitHub 上的活跃度其实不算高）对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则回去老老实实用 RabbitMQ 吧，人家有活跃的开源社区，绝对不会黄。

所以中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。

如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。

参考博客  
[https://www.cnblogs.com/midoujava/p/11488925.html][https_www.cnblogs.com_midoujava_p_11488925.html].  
[https://www.zhihu.com/people/yi-ke-bai-cai-cai-87/posts][https_www.zhihu.com_people_yi-ke-bai-cai-cai-87_posts].

[20200728211514519.png]: https://img-blog.csdnimg.cn/20200728211514519.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTM4MDk3_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/2020072821155497.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTM4MDk3,size_16,color_FFFFFF,t_70
[20200728211606760.png]: https://img-blog.csdnimg.cn/20200728211606760.png
[20200728211616603.png]: https://img-blog.csdnimg.cn/20200728211616603.png
[20200728211628482.png]: https://img-blog.csdnimg.cn/20200728211628482.png
[20200728211638513.png]: https://img-blog.csdnimg.cn/20200728211638513.png
[20200728211644973.png]: https://img-blog.csdnimg.cn/20200728211644973.png
[20200728211650766.png]: https://img-blog.csdnimg.cn/20200728211650766.png
[20200728211706740.png]: https://img-blog.csdnimg.cn/20200728211706740.png
[2020072821171416.png]: https://img-blog.csdnimg.cn/2020072821171416.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTM4MDk3_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200728211421901.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTM4MDk3,size_16,color_FFFFFF,t_70
[https_www.cnblogs.com_midoujava_p_11488925.html]: https://www.cnblogs.com/midoujava/p/11488925.html
[https_www.zhihu.com_people_yi-ke-bai-cai-cai-87_posts]: https://www.zhihu.com/people/yi-ke-bai-cai-cai-87/posts