原文：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这样的队列定位上有显著的区别。它自身应该是一个简略强壮的组件，但如果要利用在一个大规模的分布式系统中，理论还是须要做一些内部的再次开发，以解决咱们后面提到的队列存储单点，流控等问题。直观上看它的运维老本是会比拟高的，须要应用方有肯定的教训。