RabbitMQ

AMQP全称高级消息队列协议（Advanced Message Queuing Protocol），是一种标准，类似于 JMS，兼容JMS协议。目前RabbitMQ主流支持AMQP 0-9-1，3.8.4版本支持AMQP 1.0。

Publisher：消息发送者，将消息发送到Exchange并指定RoutingKey，以便queue可以接收到指定的消息。

Consumer：消息消费者，从queue获取消息，一个Consumer可以订阅多个queue以从多个 queue中接收消息。

Server：一个具体的MQ服务实例，也称为Broker。

Virtual host：虚拟主机，一个Server下可以有多个虚拟主机，用于隔离不同项目，一个Virtual host通常包含多个Exchange、Message Queue。

Exchange：交换器，接收Producer发送来的消息，把消息转发到对应的Message Queue中。 （Exchange只是做转发，Exchange 也可以将消息转发到另外一个Excchange ）

Routing key：路由键，用于指定消息路由规则（Exchange将消息路由到具体的queue中），通常需要和具体的Exchange类型、Binding的Routing key结合起来使用。

Bindings：指定了Exchange和Queue之间的绑定关系。Exchange根据消息的Routing key和 Binding配置（绑定关系、Binding、Routing key等）来决定把消息分派到哪些具体的queue中。这依赖于Exchange类型。

Message Queue：实际存储消息的容器，并把消息传递给最终的Consumer。

AMQP是一个二进制的协议，信息被组织成数据帧，有很多类型。数据帧携带协议方法和其他信息。所有数据帧都拥有基本相同的格式：帧头，负载，帧尾。数据帧负载的格式依赖于数据帧的类型。

数据帧界定

会把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中。

direct类型的交换器路由规则很简单，它会把消息路由到那些BindingKey和RoutingKey完全匹配的队列中，

topic类型的交换器在direct匹配规则上进行了扩展，也是将消息路由到BindingKey和RoutingKey 相匹配的队列中，这里的匹配规则稍微不同，它约定：BindingKey和RoutingKey一样都是由"."分隔的字符串；BindingKey中可以存在两种特殊字符“* ”和 “#”，用于模糊匹配，其中"* "用于匹配一个单词，"#"用于匹配多个单词（可以是0个）

headers类型的交换器不依赖于路由键的匹配规则来路由信息，而是根据发送的消息内容中的 headers属性进行匹配。在绑定队列和交换器时指定一组键值对，当发送的消息到交换器时， RabbitMQ会获取到该消息的headers，对比其中的键值对是否完全匹配队列和交换器绑定时指定的键 值对，如果匹配，消息就会路由到该队列。headers类型的交换器性能很差，不实用。

持久化消息

非持久化消息

队列索引存储

消息存储

队列结构

经典队列可以选择是否持久化(Durability)以及是否自动删除(Auto delete)两个属性

仲裁队列，是RabbitMQ从3.8.0版本，引入的一个新的队列类型，整个3.8.X版本，也都是在围绕仲裁队列进行完善和优化。仲裁队列相比Classic经典队列，在分布式环境下对消息的可靠性保障更高。官方文档中表示，未来会使用Quorum仲裁队列代替传统Classic队列

Quorum是基于Raft一致性协议实现的一种新型的分布式消息队列，他实现了持久化，多备份的FIFO队列，主要就是针对RabbitMQ的镜像模式设计的。简单理解就是quorum队列中的消息需要有集群中多半节点同意确认后，才会写入到队列中。这种队列类似于RocketMQ当中的DLedger集群。这种方式可以保证消息在集群内部不会丢失。同时，Quorum是以牺牲很多高级队列特性为代价，来进一步保证消息在分布式环境下的高可靠。

从整体功能上来说，Quorum队列是在Classic经典队列的基础上做减法，因此对于RabbitMQ的长期使用者而言，其实是会影响使用体验的。他与普通队列的区别：

Quorum队列更适合于队列长期存在，并且对容错、数据安全方面的要求比低延迟、不持久等高级队列更能要求更严格的场景。例如电商系统的订单，引入MQ后，处理速度可以慢一点，但是订单不能丢失

不适合使用的场景

Stream队列是RabbitMQ自3.9.0版本开始引入的一种新的数据队列类型，也是目前官方最为推荐的队列类型。这种队列类型的消息是持久化到磁盘并且具备分布式备份的，更适合于消费者多，读消息非常频繁的场景

Stream队列的核心是以append-only只添加的日志来记录消息，整体来说，就是消息将以append-only的方式持久化到日志文件中，然后通过调整每个消费者的消费进度offset，来实现消息的多次分发。下方有几个属性也都是来定义日志文件的大小以及保存时间。如果你熟悉Kafka或者RocketMQ，会对这种日志记录消息的方式非常熟悉

这种队列提供了RabbitMQ已有的其他队列类型不太好实现的四个特点

整体上来说，RabbitMQ的Stream队列，其实有很多地方借鉴了其他MQ产品的优点，在保证消息可靠性的基础上，着力提高队列的消息吞吐量以及消息转发性能。因此，Stream也是在视图解决一个RabbitMQ一直以来，让人诟病的缺点，就是当队列中积累的消息过多时，性能下降会非常明显的问题。RabbitMQ以往更专注于企业级的内部使用，但是从这些队列功能可以看到，Rabbitmq也在向更复杂的互联网环境靠拢，未来对于RabbitMQ的了解，也需要随着版本推进，不断更新。

RabbitMQ从3.6.0版本开始，就引入了懒队列的概念。懒队列会尽可能早的将消息内容保存到硬盘当中，并且只有在用户请求到时，才临时从硬盘加载到RAM内存当中

懒队列的设计目标是为了支持非常长的队列(数百万级别)。队列可能会因为一些原因变得非常长-也就是数据堆积

• 消费者服务宕机了
• 有一个突然的消息高峰，生产者生产消息超过消费者
• 消费者消费太慢了

默认情况下，RabbitMQ接收到消息时，会保存到内存以便使用，同时把消息写到硬盘。但是，消息写入硬盘的过程中，是会阻塞队列的。RabbitMQ虽然针对写入硬盘速度做了很多算法优化，但是在长队列中，依然表现不是很理想，所以就有了懒队列的出现。
懒队列会尝试尽可能早的把消息写到硬盘中。这意味着在正常操作的大多数情况下，RAM中要保存的消息要少得多。当然，这是以增加磁盘IO为代价的。

声明懒队列有两种方式

懒队列适合消息量大且长期有堆积的队列，可以减少内存使用，加快消费速度。但是这是以大量消耗集群的网络及磁盘IO为代价的

• RabbitMQ 采用类似NIO的做法，复用TCP连接，减少性能开销，便于管理。 当每个信道的流量不是很大时，复用单一的Connection 可以在产生性能瓶颈的情况下有效地节省 TCP 连接资源。
• 当信道本身的流量很大时，一个Connection 就会产生性能瓶颈，流量被限制。需要建立多个 Connection ，分摊信道。具体的调优看业务需要。 信道在AMQP 中是一个很重要的概念，大多数操作都是在信道这个层面进行的。

systemctl start|restart|stop|status rabbitmq-server

rabbitmqctl  help  可以查看更多命令

rabbitmq-plugins enable|list|disable

添加用户

创建虚拟主机

绑定虚拟主机和用户

在这种情况下，我们需要考虑消息丢失的问题

不需要指定Route key

每个队列都能拿到消息

普通Confirm

批量Confirm

异步Confirm

配置Yaml

创建confirm和 return 监听

 工作原理

Maven项目

SpringBott 项目

通过定义时设置durable = ture

通过定义时设置durable = ture

将消息的投递模式 (BasicProperties 中的 deliveryMode 属性)设置为 2

NONE模式

AUTO（自动ACK）模式

MANUAL（手动Ack）模式

RabbitMQ 还默认提供了一种基于credit flow的流控机制，面向每一个连接进行流控。当单个队列达到最大流速 时，或者多个队列达到总流速时，都会触发流控。触发单个链接的流控可 能是因为connection、channel、queue的某一个过程处于flow状态，这些状态都可以从监控平台看到

connection

channel

queue

生产者：生产者往往是希望自己产生的消息能快速投递出去，而当消息投递太快且超过了下游的消费速度时 就容易出现消息积压/堆积，所以，从上游来讲我们应该在生产端应用程序中也可以加入限流、应急开关等控制手段，避免超过Broker端的极限承载能力或者压垮下游消费者。
消费者：再看看下游，我们期望下游消费端能尽快消费完消息，而且还要防止瞬时大量消息压垮消费端（推模式），我们期望消费端处理速度是最快、最稳定而且还相对均匀（比较理想化）。

提升下游应用的吞吐量和缩短消费过程的耗时

消息传输保障三个层级

RabbitMQ 支持其中的“最多一次”和“最少一次”

Maven Java 使用

SpringBoot 使用

通过命令行方式设置全局TTL

消息被拒绝（Basic.Reject/Basic.Nack），并且设置requeue参数为false

消息过期

队列达到最大长度

TTL消息过期是基于FIFO特性的

TTL存放消息在死信队列(delayqueue)里，而基于插件存放消息 在延时交换机里(x-delayed-message exchange)。

插件下载/安装

Spring Boot代码

单活，容量对等，可以实现故障转移。使用独立存储时需要借助复制、镜像同步等技术，数据会有延迟、不一致等问题（CAP定律），使用共享存储时就不会有状态同步这个问题。

一定程度的双活，容量对等，最常见的是`读写分离`。通常也需要借助复制技术，或者要求上游实现双写来保证节点数据一致。

两边都可以读写，互为主备。如果两边同时写入很容易冲突，所以通常实现的都是“伪主主模式”，或者说就是主从模式的升级版，只是`新增了主从节点的选举和切换。`

不同节点保存不同的数据，上游应用或者代理节点做路由，`突破存储容量限制，分摊读写负载`；典型的如MongoDB的分片、MySQL的分库分表、Redis集群。

“两地三中心”是金融行业经典的容灾模式（`有资源闲置的问题`），“异地多活”才是王道。

也叫Warren（兔子窝）模式，同一时刻只有一个节点在工作（备份节点不能读写），当主节点发 生故障后会将请求切换到备份节点上（主恢复后成为备份节点）。需要借助HAProxy之类的（VIP模式）负载均衡器来做健康检查和主备切换，底层需要借助共享存储（如SAN设备）。

Shovel是一个插件，用于实现跨机房数据复制，或者数据迁移，故障转移与恢复等。

总的来说，该集群模式只能保证集群中的某个Node挂掉后应用程序还可以切换到其他Node上继续地发送和消费消息，但并无法保证原有的消息不丢失，所以并不是一个真正意义的高可用集群。

Master 选取策略

队列添加镜像

HAProxy是一款开源免费，并提供高可用性、负载均衡以及基于TCP和HTTP协议的代理软件，可以支持四层、七层负载均衡，经过测试单节点可以支持10W左右并发连接。

使用HAProxy来做RabbitMQ的负载均衡，通过暴露VIP给上游的应用程序直接连接，
上游应用程序不感知底层的RabbitMQ的实例节点信息。

HA Proxy 也是一个单体，如何避免Ha Proxy的单点故障问题？

Spring Boot 有可以配置多个RabbitMQ的节点，这和 HAProxy 有什么区别？