RabbitMQ：基础篇

1.RabbitMQ是高性能的异步通讯组件

何为异步通讯

        打电话就是同步通讯，微信聊天可以理解为异步通讯，不是实时的进行通讯：时效性差。

同步调用的缺点：

拓展性差（需求不尽提）

性能下降        

级联失败

优势：时效性强，等到结果再返回

异步调用

异步调用是基于消息通知形式实现，一般包含三个角色：消息发送者 消息代理 消息接收者

消息代理：负责管理转存转发消息

优势：解除耦合，拓展性强

无需等待，性能好

故障隔离

缓存消息、削峰填谷

缺点：不能立即得到结果

不确定下游服务是否成功

依赖某一个业务

技术选型

2.RabbitMQ基本介绍

MQ整体架构及核心概念

• publisher：消息发送者

• consumer：消息的消费者

• queue：队列，存储消息

• virtual-host：虚拟主机，起到数据隔离作用

• exchange：交换机，负责路由消息

3.数据隔离

在MQ中创建虚拟主机实现数据隔离

4.SpringAMQP

AMQP:消息通信协议与语言无关，更符合微服务中独立性的要求

Spring AMQP:基于AMQP协议定义的API规范，提供模板来发送和接受消息。->spring rabbit默认实现

AMQP依赖：父工程加入依赖

配置文件：每个微服务端引入MQ服务的信息

发送消息：RabbitTemplate.converAndSend(队列名，消息体内容)

消息接受：

4.1 WorkQueue

实现一个队列绑定多个消费者

默认情况下，RabbitMQ会将消息依次轮询投递给绑定在队列上的每一个消费者，但并不会考虑消费者是否处理完消息，可能会出现消息堆积

可以通过修改配置文件，设置preFetch为1，确保同一时刻最多传递给消费者1条消息

Work模型的使用：

1.多个消费者绑定到一个队列，可以加快消息的处理速度

2.同一条消息只会被一个消费者处理

3.通过设置prefetch来控制消费者预取的消息数量，处理完一条再处理下一条，实现能者多劳

4.2 Fanout交换机

fanout的交换机会将接收到的消息广播到每一个跟其绑定的queue，所以也叫广播模式

交换机的作用：

接收生产者发送的消息

将消息按照规则路由到与之绑定的队列

Fanout交换机会将消息路由到每个绑定的队列

4.3 Direct交换机

Direct交换机会将接受到的消息根据规则路由到指定的queue，因此称为定向路由

每一个queue都与exchange设置一个BindingKey

发布者发送消息时，指定消息的RoutingKey

Exchange将消息路由到 BKey和Rkey一致的队列

 生产者：

4.4 Topic交换机

与Direct交换机类似，区别在于routingKey可以是多个单词的列表，并且以.分割

queue与exchange指定bindingKey时，可以使用通配符：

*：代指一个单词；#：代指0个或多个单词

描述二者差异：

direct的routingKey必须是具体topic可以是多个单词，用.分割，并且队列与交换机绑定时的routingkey可以使用通配符

4.5 用java代码声明队列和交换机

SpringAMQP提供几个类，用来声明队列、交换机及其绑定关系

代码demo：

除了上述基于Bean形式声明队列和交换机还有一种方便的方式：

4.6 消息转换器

Spring的对消息对象的处理是由MessageConverter来处理的，而默认实现是simpleMessageConverter，基于JDK的ObjectOutputStream

有几个问题：

• JDK的序列化有安全性问题
• JDK序列化的消息太大
• JDK序列化的消息可读性差

推荐使用JSON序列化代替默认的JDK序列化：

publisher和consumer都要引入jackson依赖

publisher和consumer配置messageConverter

5.消息传输可靠性

5.1 生产者可靠性

5.1.1 生产者重连

利用重试机制可有效提高消息发送的成功率，不过SpringAMQP提供的重试机制是阻塞式的重试，线程是被阻塞的，会影响到业务性能

5.1.2 生产者确认

原理：

代码具体实现：

在生产者微服务中添加配置：

每个RabbitTemplate只能配置一个ReturnCallback，因此需要在项目启动过程中配置：

Confirmcallback 发消息

demo：

• 生产者确认需要额外的资源，尽量不使用
• 如果一定使用，无需开启Publisher-Return机制，因为一般路由失败是业务问题
• 对于nack消息可以有限次重试，依然失败则记录异常信息

5.2 MQ的可靠性

5.2.1 数据持久化

在默认情况下，RabbitMQ会将收到的信息保存到内存中以降低消息收发的延迟。这样会导致俩个问题：

• 一旦MQ宕机，内存的消息就会丢失
• 内存空间有限，消费者发生故障或处理过慢，会导致消息积压，引发MQ阻塞

实现数据持久化：

交换机持久化

 队列持久化

 消息持久化

5.2.2 Lazy Queue

从MQ3.6.0版本之后，引入懒惰队列的概念，懒惰队列的特征：

1、接收到消息不保存到内存中，而是存入磁盘(内存只保留最近的消息，默认是2048条)

2、消费者要消费信息时才会从磁盘读取消息

3、支持百万级别的消息存储

3.12版本之后队列只有懒惰队列，无法更改

配置方法：

 

5.3 消费者的可靠性

为了确认消费者是否成功处理消息，MQ提供了消费者确认机制，当消费者处理消息结束后，应该向MQ发送一个回执，告知自己的消息处理状态。回执有三种：

ack、nack、reject

5.3.1 消费者确认机制

SpringAMQP已经实现了消息确认功能，通过配置文件选择ACK处理方式：

 5.3.2 消费失败处理

失败重试机制：

当消费者出现异常后，消息会不断requeue到队列，再重新发送给消费者，无限循环，导致MQ的消息处理飙升，带来不必要的压力

失败消息处理策略：

在开启重试模式后，重试次数耗尽，需要MessageRecoverer接口来处理

消费者如何保证消息一定被消费

开启消费者确认机制为Auto，由Spring确认消息并返回ack或者其他；

开启失败重传机制后，并设置了MessageRecoverer，多次重传失败后将消息投递给指定的交换机

5.3.3 业务幂等性

同一个业务，执行一次或多次对业务状态的影响是一致的

天生幂等业务：查询业务、删除业务

唯一消息id

源码：

第二种方案就是根据业务实现：

比如说修改订单状态，想要从已支付变成未支付的情况下，可以不用设置uuid，而是在改状态前加一个判断状态的实现就可以了。

---

6. 延迟消息

生产者发送消息时指定一个时间，消费者不会立刻收到消息而是等待时间之后才收到消息

6.1 死信交换机

如果一个队列通过dead-letter-exchange属性指定了一个交换机，那么该队列中的死信就会指定给这个交换机，这个交换机就是死新交换机

使用场景：

控制台实现绑定死信交换机

发送消息：需要用到消息后置处理器要不然抛异常~

消费者

6.2 延迟消息插件

MQ官方推出一个插件，原生支持延迟消息功能。其原理是设计一种支持延迟消息功能的交换机，当消息投递给交换机后可以暂存一定时间，到期后再投递给交换机。

装好插件之后，交换机加参数：

发送消息实现：

6.3 取消超时订单

首先来说这个延迟消息的发送时间的确定是根据具体业务实现，就比如说针对取消超时订单的场景下，用户支付确认之后有30min的时间进行支付，那么我们可以设置一个数组，每个数组的元素就是延迟消息，第一个是10s、10s、10s、30s、30s、1min.....这样的形式来优化延迟消息的发送。