关于rabbitmq:深入理解RabbitMQ的前世今生

原文：https://sq.163yun.com/blog/ar…
作者：Java 大蜗牛

对于 RabbitMQ

• 出身：诞生于金融行业的音讯队列
• 语言：Erlang
• 协定：AMQP（Advanced Message Queuing Protocol 高级音讯队列协定）
• 关键词：内存队列，高可用，一条音讯

队列构造

• Producer/Consumer：生产者消费者
• Exchange：交换器，能够了解为队列的路由逻辑，交换器次要有三种，图中是 Direct 交换器
• Queue：队列
• Binding：绑定关系，理论是交换器上映射队列的规定

发送和生产一条音讯

在上图的模式下，交换器的类型为 Direct，伪代码示意音讯的生产和生产

音讯生产

# 音讯发送办法
#messageBody 音讯体
#exchangeName 交换器名称
#routingKey 路由键
publishMsg(messageBody,exchangeName,routingKey){......}
#音讯发送
publishMsg("This is a warning log","exchange","log.warning");

RoutingKey=log.warning，和队列 A 与交换器的绑定统一，所以音讯被路由到了队列 A 上。

音讯生产

对于音讯生产而言，消费者间接指定要生产的队列即可，比方指定生产队列 A 的数据。

须要留神的是，在消费者生产实现数据后，返回给 RabbitMq ACK 音讯，RabbitMq 会删掉队列中的该条信息。

多种音讯路由模式

在 Exchange 这个模块上，RabbitMq 次要反对了 Direct，Fanout，Topic 三种路由模式，RabbitMq 在路由模式上下功夫，也阐明了他在设计上想要满足多样化的需要。

Direct 和 Fanout 模式比拟好了解，相似于单播和播送模式，Topic 模式比拟有意思，它反对自定义匹配规定，依照规定把所有满足条件的音讯路由到指定队列，可能帮忙开发者灵便应答各类需要。

音讯的存储

RabbitMQ 的音讯默认是在内存里的，实际上不光是音讯，Exchange 路由等信息理论都在内存中。内存的长处是高性能，问题在于故障后无奈复原。所以 RabbitMQ 也反对长久化的存储，也就是写磁盘。

要在 RabbitMQ 中长久化音讯，要同时满足三个条件：

1. 音讯投体时应用长久化投递模式
2. 指标交换器是配置为长久化的
3. 指标队列是配置为长久化的

RabbitMQ 长久化音讯的形式是常见的写日志形式：

1. 当一条长久化音讯发送到长久化的 Exchange 上时，RabbitMQ 会在音讯提交到日志文件后，才发送响应。
2. 一旦这条音讯被生产后，RabbitMQ 会将会把日志中该条音讯标记为期待垃圾收集，之后会从日志中革除。
3. 如果呈现故障，主动重建 Exchange,Bindings 和 Queue，同时通过重播长久化日志来复原音讯。

音讯长久化的优缺点很显著，领有故障恢复能力的同时，也带来了性能的急剧下降。同时，因为 RabbitMQ 默认状况下是没有冗余的，假如一个长久化节点解体，统一到该节点复原前，音讯和队列都无奈复原。

音讯投递模式

1. 发后即忘

RabbitMQ 默认公布音讯是不会返回任何后果给生产者的，所以存在发送过程中失落数据的危险。

2.AMQP 事务

AMQP 事务保障 RabbitMQ 不仅收到了音讯，并胜利将音讯路由到了所有匹配的订阅队列，AMQP 事务将使得生产者和 RabbitMQ 产生同步。

尽管事务使得生产者能够确定音讯曾经达到 RabbitMQ 中的对应队列，然而却会升高 2～10 倍的音讯吞吐量。

3. 发送方确认

开启发送方确认模式后，音讯会有一个惟一的 ID，一旦音讯被投递给所有匹配的队列后，会回调给发送方应用程序（蕴含音讯的惟一 ID），使得生产者晓得音讯曾经平安达到队列了。

如果音讯和队列是配置成了长久化，这个确认音讯只会在队列将音讯写入磁盘后才会返回。如果 RabbitMQ 外部产生了谬误导致这条音讯失落，那么 RabbitMQ 会发送一条 nack 音讯，当然我了解这个是不能保障的。

这种模式因为不存在事务回滚，同时整体依然是一个异步过程，所以更加轻量级，对服务器性能的影响很小。

RabbitMQ RPC

个别的异步服务间，可能会用两组队列实现两个服务模块之前的异步通信，乏味的是 RabbitMQ 就内建了这个性能。

RabbitMQ 反对音讯应答性能，每个 AMQP 音讯头中有一个 Reply_to 字段，通过该字段指定音讯返回到的队列名称（这是一个公有队列）音讯的生产者能够监听该字段对应的队列。

RabbitMQ 集群

RabbitMQ 集群的设计指标：

1. 容许消费者和生产者在 RabbitMQ 节点解体的状况下持续运行
2. 能过通过增加节点来线性扩大音讯通信吞吐量

从理论后果看，RabbitMQ 实现设计指标上并不非常杰出，次要起因在于默认的模式下，RabbitMQ 的队列实例子只存在在一个节点上（尽管后续也反对了镜像队列），既不能保障该节点解体的状况下队列还能够持续运行，也不能线性扩大该队列的吞吐量。

集群构造

RabbitMQ 外部的元数据次要有：

1. 队列元数据 - 队列名称和属性
2. 交换器元数据 - 交换器名称，类型和属性
3. 绑定元数据 - 路由信息

尽管 RabbitMQ 的队列理论只会在一个节点上，但元数据能够存在各个节点上。举个例子来说，当创立一个新的交换器时，RabbitMQ 会把该信息同步到所有节点上，这个时候客户端不论连贯的那个 RabbitMQ 节点，都能够拜访到这个新的交换器，也就能找到交换器下的队列。

如上图所示，队列 A 的实例理论只在一个 RabbitMQ 节点上，其它节点理论存储的是只想该队列的指针。

为什么 RabbitMQ 不在各个节点间做复制了，《RabbitMQ 实战》给出了两个起因：

1. 存储老本 -RabbitMQ 作为内存队列，复制对存储空间的影响，毕竟内存是低廉而无限的
2. 性能损耗 - 公布音讯须要将音讯复制到所有节点，特地是对于长久化队列而言，性能的影响会很大

我了解老本这个起因并不齐全成立，复制并不一定要复制到所有节点，比方一个队列能够只做两个正本，复制带来的内存老本能够交给应用方来评估，毕竟在内存中没有沉积的状况下，实际上队列是不会占用多大内存的。

还有一点是 RabbitMQ 自身并没有保障音讯生产的有序性，所以实际上队列被 Partition 到各个节点上，这样能力真正达到线性扩容的目标（以 RabbitMQ 的现状来说，单队列理论是无奈扩容的，只有在业务层做切分）。

注：RabbitMQ 集群中的节点能够是内存节点也能够是磁盘节点，但要求至多有一个磁盘节点，这样呈现故障时能力复原数据。

镜像队列

镜像队列架构

RabbitMQ 本人也思考到了咱们之前剖析的单节点长时间故障无奈复原的问题，所以 RabbitMQ 2.6.0 之后它也反对了镜像队列，换个说法也就是正本。

除了发送音讯，所有的操作理论都在主拷贝上，从拷贝理论只是个冷备（默认的状况下所有 RabbitMQ 节点上都会有镜像队列的拷贝），如果应用音讯确认模式，RabbitMQ 会在主拷贝和从拷贝都平安的承受到音讯时才告诉生产者。

从这个构造上来看，如果从拷贝的节点挂了，理论没有任何影响，如果主拷贝挂了，那么会有一个从新选主的过程，这也是镜像队列的长处，除非所有节点都挂了，才会导致音讯失落。从新选主后，RabbitMQ 会给消费者一个消费者勾销告诉（Consumer Cancellation），让消费者重连新的主拷贝。

镜像队列原理

1.RabbitMQ 构造

• AMQPQueue：负责 AMQP 协定相干的音讯解决，包含接管音讯，投递音讯，Confirm 音讯等
• BackingQueue：提供 AMQQueue 调用的接口，实现音讯的存储和长久化工作

BackingQueue 由 Q1,Q2,Delta,Q3,Q4 五个子队列形成，在 Backing 中，音讯的生命周期有四个状态：

1. Alpha：音讯的内容和音讯索引都在 RAM 中。（Q1，Q4）
2. Beta：音讯的内容保留在 Disk 上，音讯索引保留在 RAM 中。（Q2，Q3）
3. Gamma：音讯的内容保留在 Disk 上，音讯索引在 DISK 和 RAM 上都有。（Q2，Q3）
4. Delta：音讯内容和索引都在 Disk 上。(Delta）

这里以长久化音讯为例（能够看到非长久化音讯的生命周期会简略很多），从 Q1 到 Q4，音讯理论经验了一个 RAM->DISK->RAM 这样的过程，BackingQueue 这么设计的目标有点相似于 Linux 的 Swap，当队列负载很高时，通过将局部音讯放到磁盘上来节俭内存空间，当负载升高时，音讯又从磁盘回到内存中，让整个队列有很好的弹性。因而触发音讯流动的次要因素是：1. 音讯被生产；2. 内存不足。

RabbitMQ 会更具音讯的传输速度来计算以后内存中容许保留的最大音讯数量（Traget_RAM_Count），当：内存中保留的音讯数量 + 期待 ACK 的音讯数量 >Target_RAM_Count 时，RabbitMQ 才会把音讯写到磁盘上，所以说尽管实践上音讯会依照 Q1->Q2->Delta->Q3->Q4 的程序流动，然而并不是每条音讯都会经验所有的子队列以及对应的生命周期。

从 RabbitMQ 的 Backing Queue 构造来看，当外部有余时，音讯要经验多个生命周期，在 Disk 和 RAM 之间置换，者理论会升高 RabbitMQ 的解决性能（后续的流控就是关联的解决办法）。

2. 镜像队列构造

所有对镜像队列主拷贝的操作，都会通过 Guarented Multicasting(GM)同步到各个 Salve 节点，Coodinator 负责组播后果的确认。

GM 是一种牢靠的组播通信协议，保障组组内的存活节点都收到音讯。

GM 的主播并不是由 Master 节点来负责告诉所有 Slave 的（目标是为了防止 Master 压力过大，同时防止 Master 生效导致音讯无奈最终 Ack)，RabbitMQ 把一个镜像队列的所有节点组成一个链表，由主拷贝发动，由主拷贝最终确认告诉到了所有的 Slave，而两头由 Slave 接力的形式进行音讯流传。

从这个构造来看，音讯实现整个镜像队列的同步耗时实践上是不低的，然而因为 RabbitMQ 音讯的音讯确认自身是异步的模式，所以整体的吞吐量并不会受到太大影响。

流控

当 RabbitMQ 呈现内存 (默认是 0.4) 或者磁盘资源达到阈值时，会触发流控机制，阻塞 Producer 的 Connection，让生产者不能持续发送音讯，直到内存或者磁盘资源失去开释。

RabbitMQ 基于 Erlang/OTP 开发，一个音讯的生命周期中，会波及多个过程间的转发，这些 Erlang 过程之间不共享内存，每个过程都有本人独立的内存空间，如果没有适合的流控机制，可能会导致某个过程占用内存过大，导致 OOM。因而，要保障各个过程占用的内容在一个正当的范畴，RabbitMQ 的流控采纳了一种信用证机制(Credit)，为每个过程保护了四类键值对：

1. {credit_from,From}- 该值示意还能向音讯接管过程 From 发送多少条音讯
2. {credit_to,To}- 示意以后过程再接管多少条音讯，就要向音讯发送过程减少 Credit 数量
3. credit_blocked- 示意以后过程被哪些过程 block 了，比方过程 A 向 B 发送音讯，那么当 A 的过程字典中 {credit_from,B} 的值为 0 是，那么 A 的 credit_blocked 值为[B]
4. credit_deferred- 音讯接管过程向音讯发送过程减少 Credit 的音讯列表，当过程被 Block 时会记录音讯信息，Unblock 后顺次发送这些音讯

如图所示，A 过程以后能够发送给 B 的音讯有 100 条，每发一次，值减 1，直到为 0，A 才会被 Block 住。B 生产音讯后，会给 A 减少新的 Credit，这样 A 才能够继续的发送音讯。这里只画了两个过程，多过程串联的状况下，这中影响也就是从底向上传递的。

想学习 Java 工程化、分布式架构、高并发、高性能、深入浅出、微服务架构、Spring，MyBatis，Netty 源码剖析等技术能够加群：479499375，群里有阿里大牛直播解说技术，以及 Java 大型互联网技术的视频收费分享给大家，欢送进群一起深刻交流学习。

总结

注：本文基于的 RabbitMQ 资料可能较为古老，新的 RabbitMQ 可能会有不同的性能个性

整体来看，RabbitMQ 的性能比拟丰盛（惋惜没有看到提早，优先级等性能），更实用于偏实时的业务场景，与 Kafka 这样的队列定位上有显著的区别。它自身应该是一个简略强壮的组件，但如果要利用在一个大规模的分布式系统中，理论还是须要做一些内部的再次开发，以解决咱们后面提到的队列存储单点，流控等问题。直观上看它的运维老本是会比拟高的，须要应用方有肯定的教训。