一、简介

什么是 MQ

MQ = Message Queue = 消息队列

消息队列：存放内容是消息的 FIFO（先入先出） 队列。是一种跨进程的通信机制，用于上下游传递消息。

为什么要用 MQ ？作用

1、应用解耦

以电商系统为例，应用中有订单系统、库存系统、物流系统、支付系统。当用户创建一个订单时，如果耦合地调用库存、物流、支付系统，当某个系统出现故障，都会导致下单操作异常。但如果转变为基于消息队列方式后，问题就会减少很多，比如如果物流系统发送故障，需要几分钟来修复。在这段时间内，物流系统要处理地内存会被缓存在消息队列中，用户地下单操作可以正常完成。等物流系统恢复后，会继续处理订单信息，而这个过程用户感受不到物流系统出现了异常。

2、异步处理

举个例子，有两个系统 A 和 B。假如 A 调用 B，B 需要花费很长时间执行，但是 A 需要知道 B 什么时候可以执行完毕，以前一般有两种方式处理：一是 A 过一段时间去调用 B 的查询 api 。二是 A 提供一个 callback 接口，当 B 处理完时调用该接口通知 A 服务。但这两种方式都不是很优雅。使用消息队列后，可以这样做，A 调用 B 的服务后，只需要监听 B 处理完的消息，当 B 处理完后，会发送一条消息给 MQ，MQ 会将该消息发送给 A 服务。

3、流量消峰

举个例子，假如一个系统一秒最多可以处理一千次订单，这个处理能力在正常时段是绰绰有余的。但是在高峰的时候（例如双十一），一秒钟能达到五千次请求，这时候系统是处理不了这么多的，传统的方法是限制当请求超过一千之后不允许用户下单。而使用消息队列的话可以做为缓冲，把一秒内处理的订单分成一段时间来处理，当然这会影响到用户响应时间，但是比起不能下单的体验要好很多。

 削峰填谷

 MQ分类？

ActiveMQ
优点：单机吞吐量万级，时效性 ms 级，可用性高，基于主从架构实现高可用性，不容易丢失数据。
缺点：官方社区维护越来越少，高吞吐量场景较少使用。

Kafka：
优点：为大数据而生，吞吐量高，多运用于大数据领域的实时计算和日志采集场景。
缺点：社区更新较慢。

RokectMQ：
优点：Java 语言实现，单机吞吐量十万级，支持 10 亿级别的消息堆积。
缺点：支持的客户端语言不多。

RabbitMQ：
优点：一个在 AMQP （高级消息队列协议）基础上完成的，主流的消息中间件之一，erlang 语言实现的高并发特性，吞吐量到万级，支持多种语言，社区活跃度高。
缺点：商业版收费。
 

二、RabbitMQ

2.1 简介

概念：RabbitMQ 是一个消息中间件，负责接收、存储、转发消息。类似生活中的快递站，负责接受快递，存储快递，转发快递。

组成：
生产者：负责产生数据
交换机：接收来自生产者的消息，并将消息推送到队列中。决定消息是要推送给特定队列，还是推送给多个队列，还是丢弃。
队列：存储消息。
消费者：接收消息。

 2.2 六大模式

1、简单模式
2、工作模式
3、发布/订阅模式
4、路由模式
5、主题模式
6、发布确认模式

 简单模式

1. 消息产生着§将消息放入队列
2. 消息的消费者(consumer) 监听(while) 消息队列,如果队列中有消息,就消费掉,消息被拿走后,自动从队列中删除(隐患 消息可能没有被消费者正确处理,已经从队列中消失了,造成消息的丢失)应用场景:聊天(中间有一个过度的服务器;p端,c端)

 work工作模式（资源的竞争)

 

1. 消息产生者将消息放入队列消费者可以有多个,消费者1,消费者2,同时监听同一个队列,消息被消费?C1 C2共同争抢当前的消息队列内容,谁先拿到谁负责消费消息(隐患,高并发情况下,默认会产生某一个消息被多个消费者共同使用,可以设置一个开关(syncronize,与同步锁的性能不一样) 保证一条消息只能被一个消费者使用)
2. 应用场景:红包;大项目中的资源调度(任务分配系统不需知道哪一个任务执行系统在空闲,直接将任务扔到消息队列中,空闲的系统自动争抢)

publish/subscribe发布订阅(共享资源)

 

1. X代表交换机rabbitMQ内部组件,erlang 消息产生者是代码完成,代码的执行效率不高,消息产生者将消息放入交换机,交换机发布订阅把消息发送到所有消息队列中,对应消息队列的消费者拿到消息进行消费
2. 相关场景:邮件群发,群聊天,广播(广告)

routing路由模式

1. 消息生产者将消息发送给交换机按照路由判断,路由是字符串(info) 当前产生的消息携带路由字符(对象的方法),交换机根据路由的key,只能匹配上路由key对应的消息队列,对应的消费者才能消费消息;
2. 根据业务功能定义路由字符串
3. 从系统的代码逻辑中获取对应的功能字符串,将消息任务扔到对应的队列中业务场景:error 通知;EXCEPTION;错误通知的功能;传统意义的错误通知;客户通知;利用key路由,可以将程序中的错误封装成消息传入到消息队列中,开发者可以自定义消费者,实时接收错误;

topic 主题模式(路由模式的一种)

1. 星号井号代表通配符
2. 星号1个字符井号代表0个或多个字符
3. 路由功能添加模糊匹配
4. 消息产生者产生消息,把消息交给交换机
5. 交换机根据key的规则模糊匹配到对应的队列,由队列的监听消费者接收消息消费

2.3 死信队列

什么是死信

死信：无法被消费的消息。
死信队列：无法被消费的消息将被流转到该队列。

producer 将消息投递到 broker 或者直接到queue 里了，consumer 从 queue 取出消息进行消费，但某些时候由于特定的原因导致 queue 中的某些消息无法被消费，这样的消息如果没有后续的处理，就变成了死信，有死信自然就有了死信队列。

应用场景:

为了保证订单业务的消息数据不丢失，需要使用到 RabbitMQ 的死信队列机制，当消息
消费发生异常时，将消息投入死信队列中.还有比如说: 用户在商城下单成功并点击去支付后在指定时间未支付时自动失效。

产生死信的原因

1、消息 TTL 过期
2、队列达到最大长度(队列满了，无法再添加数据到 mq 中)
3、消息被拒绝(basic.reject 或 basic.nack)并且 requeue=false

死信架构图

2.4 延迟队列

什么是延迟

在上节的死信队列案例中有一种情况是消息 TTL 过期，从而消息进入死信队列的过程。这种过程单独列出来就叫做延迟队列。

延迟队列：延时队列就是用来存放需要在指定时间被处理的元素的队列。即生产者正常发消息到队列，在队列中经过一定的延迟时间后进入死信队列，从而再被消费者消费。

延迟队列使用的场景有很多：
1、订单在十分钟之内未支付则自动取消
2、新创建的店铺，如果在十天内都没有上传过商品，则自动发送消息提醒。
3、用户注册成功后，如果三天内没有登陆则进行短信提醒。
4、用户发起退款，如果三天内没有得到处理则通知相关运营人员。
5、预定会议后，需要在预定的时间点前十分钟通知各个与会人员参加会议。
————————————————
版权声明：本文为CSDN博主「执章学长」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/PaperJack/article/details/124734987