RabbitMQ整理汇总

1 消息队列

1.1 消息队列模式

消息队列目前主要 2 种模式，分别为”点对点模式”和”发布/订阅模式”。

1.1.1 点对点模式

一个具体的消息只能由一个消费者消费，多个生产者可以向同一个消息队列发送消息，但是一个消息在被一个消息者处理的时候，这个消息在队列上会被锁住或者被移除并且其他消费者无法处理该消息。

需要额外注意的是，如果消费者处理一个消息失败了，消息系统一般会把这个消息放回队列，这样其他消费者可以继续处理。

1.1.2 发布/订阅模式

单个消息可以被多个订阅者并发的获取和处理。一般来说，订阅有两种类型：

临时（ephemeral）订阅：这种订阅只有在消费者启动并且运行的时候才存在。一旦消费者退出，相应的订阅以及尚未处理的消息就会丢失。

持久（durable）订阅：这种订阅会一直存在，除非主动去删除。消费者退出后，消息系统会继续维护该订阅，并且后续消息可以被继续处理。

2 RabbitMQ 原理初探

提到RabbitMQ，就不得不提AMQP协议。AMQP协议是具有现代特征的二进制协议。

2.1 基本概念

AMQP协议中间的几个重要概念：

Server：接收客户端的连接，实现AMQP实体服务。
Connection：连接，应用程序与Server的网络连接，TCP连接。
Channel：信道，消息读写等操作在信道中进行。客户端可以建立多个信道，每个信道代表一个会话任务。
Message：消息，应用程序和服务器之间传送的数据，消息可以非常简单，也可以很复杂。由Properties和Body组成。Properties为外包装，可以对消息进行修饰，比如消息的优先级、延迟等高级特性；Body就是消息体内容。
Virtual Host：虚拟主机，用于逻辑隔离。一个虚拟主机里面可以有若干个Exchange和Queue，同一个虚拟主机里面不能有相同名称的Exchange或Queue。
Exchange：交换器，接收消息，按照路由规则将消息路由到一个或者多个队列。如果路由不到，或者返回给生产者，或者直接丢弃。RabbitMQ常用的交换器常用类型有direct、topic、fanout、headers四种，后面详细介绍。
Binding：绑定，交换器和消息队列之间的虚拟连接，绑定中可以包含一个或者多个RoutingKey。
RoutingKey：路由键，生产者将消息发送给交换器的时候，会发送一个RoutingKey，用来指定路由规则，这样交换器就知道把消息发送到哪个队列。路由键通常为一个“.”分割的字符串，例如“com.rabbitmq”。
Queue：消息队列，用来保存消息，供消费者消费。

2.2 工作原理

AMQP 协议模型由三部分组成：生产者、消费者和服务端，执行流程如下：

生产者是连接到 Server，建立一个连接，开启一个信道。
生产者声明交换器和队列，设置相关属性，并通过路由键将交换器和队列进行绑定。
消费者也需要进行建立连接，开启信道等操作，便于接收消息。
生产者发送消息，发送到服务端中的虚拟主机。
虚拟主机中的交换器根据路由键选择路由规则，发送到不同的消息队列中。
订阅了消息队列的消费者就可以获取到消息，进行消费。

2.3 常用交换器

RabbitMQ常用的交换器类型有direct、topic、fanout、headers四种：

Direct Exchange：直连交换机意思是此交换机需要绑定一个队列，要求该消息与一个特定的路由键完全匹配。简单点说就是一对一的，点对点的发送。
Fanout Exchange：这种类型的交换机需要将队列绑定到交换机上。一个发送到交换机的消息都会被转发到与该交换机绑定的所有队列上。每台子网内的主机都获得了一份复制的消息。
Topic Exchange：直接翻译的话叫做主题交换机，如果从用法上面翻译可能叫通配符交换机会更加贴切。这种交换机是使用通配符去匹配，路由到对应的队列。通配符有两种：”” 、 “#”。需要注意的是通配符前面必须要加上”.”符号。 ```text *符号：有且只匹配一个词。比如 a.可以匹配到”a.b”、”a.c”，但是匹配不了”a.b.c”。

#符号：匹配一个或多个词。比如”rabbit.#”既可以匹配到”rabbit.a.b”、”rabbit.a”，也可以匹配到”rabbit.a.b.c”。 ```

Headers Exchange：这种交换机不是用routingKey进行路由匹配，而是在匹配请求头中所带的键值进行路由。创建队列需要设置绑定的头部信息，有两种模式：全部匹配和部分匹配。

2.4 集群镜像模式

我们先看几个基本概念：

broker：每个节点运行的服务程序，功能为维护该节点的队列的增删以及转发队列操作请求。
master queue：每个队列都分为一个主队列和若干个镜像队列。
mirror queue：镜像队列，作为master queue的备份。在master queue所在节点挂掉之后，系统把mirror queue提升为master queue，负责处理客户端队列操作请求。注意，mirror queue只做镜像，设计目的不是为了承担客户端读写压力。

集群中有两个节点，每个节点上有一个broker，每个broker负责本机上队列的维护，并且borker之间可以互相通信

mirror queue要和master queue保持一致，故需要同步机制，正因为一致性的限制，导致所有的读写操作都必须都操作在master queue上，然后由master节点同步操作到mirror queue所在的节点。即使consumer连接到了非master queue节点，也会被路由到master queue所在的节点上，这样才能进行消费。

对于生成队列，原理和消费一样，如果连接到非 master queue 节点，则路由过去。 r10

2.5 高级特性

2.5.1 过期时间

Time To Live，也就是生存时间，是一条消息在队列中的最大存活时间，单位是毫秒。
当然也可以不设置TTL，不设置表示消息不会过期，超过了队列的超时时间配置，那么消息会变成死信，自动清除。
RabbitMQ可以对消息和队列设置TTL

2.5.2 消息确认

为了保证消息从队列可靠地到达消费者，RabbitMQ提供了消息确认机制。autoAck参数控制是否自动确认

2.5.3 持久化

RabbitMQ的持久化分为三个部分：交换器持久化、队列持久化和消息持久化。

交换器持久化：可以通过在声明队列时将durable参数设置为true。如果交换器不设置持久化，那么在RabbitMQ服务重启之后，相关的交换器元数据会丢失，不过消息不会丢失，只是不能将消息发送到这个交换器了。
队列的持久化能保证其本身的元数据不会因异常情况而丢失，但是不能保证内部所存储的消息不会丢失。要确保消息不会丢失，需要将其设置为持久化。队列的持久化可以通过在声明队列时将durable参数设置为true。
设置了队列和消息的持久化，当RabbitMQ服务重启之后，消息依然存在。如果只设置队列持久化或者消息持久化，重启之后消息都会消失。

ps:当然，也可以将所有的消息都设置为持久化，但是这样做会影响RabbitMQ的性能，因为磁盘的写入速度比内存的写入要慢得多。

2.5.4 死信队列

当消息在一个队列中变成死信之后，他能被重新发送到另一个交换器中，这个交换器成为死信交换器，与该交换器绑定的队列称为死信队列。

消息变成死信有下面几种情况：

消息被拒绝。
消息过期
队列达到最大长度

2.5.5 延迟队列

TTL+死性队列完成

3 特性分析

消息路由（支持）：RabbitMQ可以通过不同的交换器支持不同种类的消息路由；
消息有序（不支持）：当消费消息时，如果消费失败，消息会被放回队列，然后重新消费，这样会导致消息无序；
消息时序（非常好）：通过延时队列，可以指定消息的延时时间，过期时间TTL等；
容错处理（非常好）：通过交付重试和死信交换器（DLX）来处理消息处理故障；
伸缩（一般）：伸缩其实没有非常智能，因为即使伸缩了，master queue还是只有一个，负载还是只有这一个master queue去抗，所以我理解RabbitMQ的伸缩很弱（个人理解）。
持久化（不太好）：没有消费的消息，可以支持持久化，这个是为了保证机器宕机时消息可以恢复，但是消费过的消息，就会被马上删除，因为RabbitMQ设计时，就不是为了去存储历史数据的。
消息回溯（不支持）：因为消息不支持永久保存，所以自然就不支持回溯。
高吞吐（中等）：因为所有的请求的执行，最后都是在master queue，它的这个设计，导致单机性能达不到十万级的标准。