RabbitMQ是一个开源的消息队列系统，它实现了高级消息队列协议（AMQP）。RabbitMQ能够帮助应用程序通过异步消息传递来进行有效的通信，从而提高系统的可扩展性和可靠性。它广泛应用于各种场景，如日志收集、支付状态同步、电商库存管理等。

安装与配置

RabbitMQ的安装相对简单。它基于Erlang OTP平台，因此首先需要安装Erlang。之后，可以通过包管理器或直接下载RabbitMQ服务器进行安装。安装完成后，RabbitMQ服务会自动启动，并且可以通过默认的端口15672访问管理控制台。

RabbitMQ的管理控制台是一个基于Web的用户界面，允许用户轻松管理和监控RabbitMQ服务器。

通过管理控制台，我们可以：

创建、删除和管理队列、交换机和绑定。
监控队列长度、消息速率和服务器状态。
查看和管理连接和通道。
设置用户权限和访问控制。
导入/导出队列和交换机配置。

核心组件

Broker服务器

在RabbitMQ中，Broker服务器就是RabbitMQ服务器本身，负责消息的中转、存储和管理，以及维护客户端连接和系统资源的有效利用。

Broker可以配置为集群模式，以提供高可用性和负载均衡。

在集群中，多个Broker服务器协同工作，共享队列和交换机的状态，但每个消息只存储在单个节点上。

Exchange交换机

RabbitMQ使用交换机来决定消息应该被路由到哪些队列。有几种不同类型的交换机，每种都有其特定的用途和路由算法。

Fanout交换机

工作原理：

Fanout交换机将消息发送到所有与其绑定的队列。

它不关心消息的RoutingKey，因此每个绑定的队列都会收到每条消息。

使用场景：

广播消息：当你需要将消息发送给多个消费者时，例如，在一个实时通知系统中，你可能希望将新通知发送给所有用户。
日志收集：在分布式系统中，可以将所有日志消息发送到一个Fanout交换机，然后由多个队列接收，用于不同的处理或存储。

Direct交换机

工作原理：

Direct交换机根据消息的RoutingKey将消息路由到特定的队列。

消息只会被发送到RoutingKey与队列的BindingKey完全匹配的队列。

使用场景：

基于属性的路由：例如，根据消息的类型或来源进行路由。在订单处理系统中，可以根据订单类型将消息路由到不同的队列。

Topic交换机

工作原理：

Topic交换机允许更复杂的匹配规则，使用*（星号）作为单个单词的通配符，使用#（井号）作为零个或多个单词的通配符。

消息的RoutingKey可以包含多个单词，以点号（.）分隔。

使用场景：

基于多个属性的复杂路由：例如，在股票市场数据系统中，可以根据股票的交易所和股票代码进行路由，如stock.nyse.microsoft。

Headers交换机

工作原理：

Headers交换机不依赖于RoutingKey，而是根据消息的headers属性进行匹配。

可以设置多个headers属性作为匹配条件。

使用场景：

当消息的路由不仅仅依赖于路由键，还依赖于消息的其他属性时。
由于其复杂性和性能问题，Headers交换机通常不是首选，但在特定情况下可能非常有用。

Queue队列

RabbitMQ中的Queue队列是用于存储和传递消息的缓冲区，它确保消息按照接收顺序被消费。

队列是消息的容器，用于存储由生产者发送但尚未被消费者处理的消息。队列遵循先进先出（FIFO）原则，即最早进入队列的消息最先被消费。

队列可以是持久化的（durable），这意味着即使 RabbitMQ 重启后队列仍然存在。非持久化队列（non-durable）则在 RabbitMQ 重启后消失。

队列需要与交换机（Exchange）绑定，才能接收从交换机路由过来的消息。

一个队列可以绑定到多个交换机，并且可以有不同的绑定键（Binding Key）。

Binding绑定关系

生产者发送的消息并不是直接到达队列，而是通过交换机进行分发。交换机根据预设的绑定规则将消息路由到一个或多个队列中，这些规则就是通过Binding来定义的。

组成元素

Binding由三部分组成，包括Routing Key、Exchange Type和Queue Name。Routing Key是一个字符串，用于指定消息的路由规则。Exchange Type决定了交换机处理消息的方式，而Queue Name则是指定队列的名称。

绑定类型

直连绑定：

对于直连交换器，只有当消息的路由键与绑定键完全匹配时，消息才会被路由到队列。

主题绑定：

对于主题交换器，绑定键可以包含通配符，如*（匹配一个单词）和#（匹配零个或多个单词）。
消息的路由键必须与绑定键的模式相匹配，才能被路由到队列。

扇形绑定：

对于扇形交换器，绑定键被忽略，因为所有发布到扇形交换器的消息都会被广播到所有绑定的队列。

头绑定：

对于头交换器，绑定基于消息的头部属性，而不是路由键。
绑定时可以指定一组头部属性和值，只有当消息的头部属性匹配这些值时，消息才会被路由到队列。

Connection连接

客户端通过TCP协议与RabbitMQ服务器建立连接。

一旦TCP连接建立，客户端会使用AMQP（高级消息队列协议）协议与RabbitMQ进行通信。

AMQP协议定义了客户端和服务器之间交换信息的格式和规则。

连接在特定的虚拟主机内进行，每个连接都必须指定一个虚拟主机。

虚拟主机是服务器中的一个逻辑分区，用于隔离不同的用户和应用。

连接建立时，客户端需要提供用户名和密码进行认证。

只有认证成功的客户端才能与RabbitMQ服务器进行交互。

连接本身不是持久的，一旦客户端断开连接，连接就会关闭。

一个连接可以创建多个通道（Channel），每个通道可以独立地发送和接收消息。

通道是轻量级的，相对于创建多个TCP连接，使用通道可以更高效地管理资源。

Message消息

消息（Message）是由生产者发送并由消费者接收的数据单元，是系统中传递信息的基本载体。

消息包含了实际的数据载荷（Payload）以及一些元数据（Metadata），这些元数据可以帮助消息在系统中正确地路由和处理。

消息的基本结构

一个典型的消息由以下几个部分组成：

消息体（Payload）：
- 消息体是消息的主要内容，包含了生产者想要发送的实际数据。消息体可以是任何形式的数据，如文本、二进制数据等。
消息属性（Properties）：
- 消息属性是一组元数据，提供了有关消息的附加信息。这些属性可以包括但不限于：
  - 消息标识符（Message ID）：用于唯一标识消息的 ID。
  - 消息类型（Message Type）：消息的类型信息。
  - 内容类型（Content-Type）：消息体的内容类型，如 text/plain、application/json 等。
  - 内容编码（Content-Encoding）：消息体的编码方式，如 UTF-8。
  - 优先级（Priority）：消息的优先级，用于优先级队列。
  - 持久性（Delivery Mode）：指示消息是否应该持久化。持久化消息会在磁盘上备份，以防止 RabbitMQ 重启时消息丢失。
  - TTL（Time to Live）：消息的生存时间，超过这个时间未被消费的消息将被丢弃或发送到死信队列。
  - 回复到（Reply-To）：用于请求/响应模式的消息，指定响应应该发送到哪个队列。
消息头（Header）：
- 消息头包含了一组键值对形式的信息，主要用于 Headers Exchange 的消息匹配。
路由键（Routing Key）：
- 路由键是在发布消息时提供的，用于确定消息应该发送到哪个交换器（Exchange），并进一步根据绑定规则路由到相应的队列。

消息的生命周期

生产者发布消息：
- 生产者创建消息，并通过一个特定的交换器和路由键将消息发送到 RabbitMQ。消息在这个阶段被序列化并准备好传输。
消息存储在队列中：
- 根据绑定关系，消息被路由到一个或多个队列中。消息在这个阶段存储在队列中，等待被消费者消费。
消费者消费消息：
- 消费者从队列中拉取消息或订阅队列来接收消息。消费者处理消息后可以选择确认消息已被处理，或者拒绝消息（可选重新排队）。
消息确认或拒绝：
- 消费者可以发送确认（Acknowledge）给 RabbitMQ，表明消息已被成功处理。如果没有确认，RabbitMQ 会将消息重新排队，以便其他消费者可以处理它。
消息删除：
- 当消息被确认处理后，它将从队列中删除。如果消息被拒绝并且设置了重新排队，则消息会返回到队列中。

Producer生产者

生产者是发送消息的应用程序。它通常通过发布消息到一个交换机来发送消息。

Consumer消费者

消费者是接收消息的应用程序。消费者通过订阅一个队列来接收消息。当消息到达队列时，RabbitMQ 将尝试将其交付给消费者。

Channel信道

RabbitMQ 使用信道来传输数据是一种优化TCP连接使用的方式。

在RabbitMQ中，信道是客户端与RabbitMQ服务器之间进行通信的虚拟连接。每个信道都复用了同一个TCP连接，但它们在逻辑上是隔离的。这意味着，即使在同一个TCP连接上，不同的信道也可以独立地发送和接收消息，而不会相互干扰。

为什么使用信道

减少TCP连接开销：
- TCP连接的创建和销毁需要时间，并且涉及网络和操作系统的开销。如果每个消息传输都建立一个新的TCP连接，将会导致性能问题。
- 通过使用信道，可以在一个稳定的TCP连接上创建多个逻辑连接，避免了频繁建立和关闭TCP连接的开销。
提高并发性能：
- 由于TCP连接数量有限，直接使用TCP连接进行消息传输会限制并发处理的数量。
- 信道允许在一个TCP连接上实现多个并发的消息流，从而提高了系统的并发处理能力。
逻辑隔离：
- 不同的信道可以设置不同的属性，如队列声明、交换机声明、消息确认等，实现了逻辑上的隔离。
- 即使一个信道发生错误，也不会影响到其他信道的正常工作。

信道的工作原理

创建信道：
- 客户端在建立TCP连接后，可以在这个连接上创建多个信道。每个信道都有一个唯一的ID。
使用信道：
- 客户端通过信道发送AMQP命令来执行各种操作，如声明队列、发送消息、接收消息、设置交换机等。
消息传输：
- 当客户端发送消息时，消息会通过指定的信道发送到RabbitMQ服务器。
- 服务器接收到消息后，根据消息的属性和路由规则，将其路由到相应的队列。
关闭信道：
- 当客户端不再需要某个信道时，可以关闭该信道。关闭信道并不会关闭底层的TCP连接。

性能优势

资源共享：多个信道共享同一个TCP连接的带宽和资源，减少了资源消耗。
流量控制：每个信道可以独立地进行流量控制，不会因为单个信道的繁忙而影响到其他信道的性能。
错误隔离：一个信道的错误不会影响到其他信道的操作，提高了系统的稳定性。

Virtual Host虚拟主机

Virtual Host是RabbitMQ中的逻辑隔离单元，类似于物理服务器中的虚拟机。每个Virtual Host都拥有自己的资源和配置，包括交换机（Exchange）、队列（Queue）和绑定（Binding），并且具备独立的权限系统。

每个Virtual Host都有自己的命名空间，都是相互隔离的，类似于沙盒的概念，不同Virtual Host中的交换器、队列和绑定互不干扰，这意味着在不同的虚拟主机中可以存在同名的队列和交换器。

这种隔离机制确保了不同应用或团队在使用同一个RabbitMQ实例时，能够安全、独立地运行，避免了命名冲突和数据泄露的风险。

RabbitMQ设计为多租户系统，在同一个RabbitMQ服务器上可以创建多个Virtual Host，每个Virtual Host代表一个独立的小型RabbitMQ服务器。这种设计允许不同的开发者、团队甚至客户在同一套硬件设施上有各自独立的消息传递环境，而不会互相影响。

默认虚拟主机 / 是所有用户都可以访问的，因此在配置用户权限时需要注意，默认情况下用户可以访问这个虚拟主机中的资源。

假设有两个不同的应用程序：一个是订单处理系统，另一个是库存管理系统。这两个系统都需要使用 RabbitMQ 来处理消息。

创建虚拟主机：
- 可以为订单处理系统创建一个名为 orders_vhost 的虚拟主机。
- 可以为库存管理系统创建一个名为 inventory_vhost 的虚拟主机。
配置队列和交换器：
- 在 orders_vhost 中创建队列和交换器，用于处理订单相关的消息。
- 在 inventory_vhost 中创建队列和交换器，用于处理库存相关的消息。
分配用户权限：
- 创建用户账户，并分别为这些用户分配对 orders_vhost 和 inventory_vhost 的访问权限。

高级特性

消息可靠性

消息可靠性是确保消息在生产、传输和消费过程中的不丢失。

生产者可靠性

重试机制：当生产者发送消息失败时，可以设置重试机制，自动重新发送消息。这可以通过配置application.yaml文件中的spring.rabbitmq.template.retry.enabled、initial-interval、multiplier和max-attempts属性来实现。

yaml

spring:
  rabbitmq:
    connection-timeout: 1s # 设置MQ的连接超时时间
    template:
      retry:
        enabled: true # 开启超时重试机制
        initial-interval: 1000ms # 失败后的初始等待时间
        multiplier: 1 # 失败后下次的等待时长倍数，下次等待时长 = initial-interval * multiplier
        max-attempts: 3 # 最大重试次数

确认机制：生产者可以设置消息确认机制，当RabbitMQ收到消息后，会发送一个确认回执给生产者。这可以通过配置application.yaml文件中的spring.rabbitmq.publisher-confirm-type属性来实现，并可以在代码中定义ConfirmCallback和ReturnCallback来处理确认和返回的消息。

yaml

spring:
  rabbitmq:
    publisher-confirm-type: correlated # 开启publisher confirm机制，并设置confirm类型
    publisher-returns: true # 开启publisher return机制

在生产者代码中定义ConfirmCallback和ReturnCallback：

查看代码

java

@Autowired
private RabbitTemplate rabbitTemplate;

public void sendMessageWithConfirm(String message) {
    CorrelationData correlationData = new CorrelationData(UUID.randomUUID().toString());
    rabbitTemplate.convertAndSend("exchange", "routingKey", message, correlationData, new ConfirmCallback() {
        @Override
        public void confirm(CorrelationData correlationData, boolean ack, String cause) {
            if (ack) {
                System.out.println("消息发送成功: " + correlationData);
            } else {
                System.out.println("消息发送失败: " + cause);
            }
        }
    }, new ReturnCallback() {
        @Override
        public void returnedMessage(ReturnedMessage returnedMessage) {
            System.out.println("消息被退回: " + returnedMessage);
        }
    });
}

MQ可靠性

数据持久化：通过配置队列、交换机和消息的持久化，确保消息在MQ重启后不会丢失。这可以通过在创建交换机和队列时将持久化的参数设置为true来实现。

java

@Bean
public Queue myQueue() {
    return new Queue("myQueue", true, true, true); // 持久化
}

@Bean
public DirectExchange myExchange() {
    return new DirectExchange("myExchange", true, true); // 持久化
}

LazyQueue：RabbitMQ的3.6.0版本后引入的惰性队列，将消息直接存储在磁盘上，降低内存占用。这可以通过在代码中配置QueueBuilder.durable("lazy.queue").lazy().build()来实现。

java

@Bean
public Queue lazyQueue() {
    return QueueBuilder.durable("lazy.queue").lazy().build();
}

消费者可靠性

确认机制

消费者处理完消息后，向RabbitMQ发送确认回执。这可以通过配置application.yaml文件中的spring.rabbitmq.listener.simple.acknowledge-mode属性来实现，并在代码中根据业务处理结果调用channel.basicAck()或channel.basicNack()方法。

yaml

spring:
  rabbitmq:
    listener:
      simple:
        acknowledge-mode: manual # 开启手动确认消费机制

在消费者代码中处理确认：

查看代码

java

@RabbitListener(queues = "myQueue")
public void receiveMessage(String message) {
    try {
        // 处理消息
        System.out.println("Received message: " + message);
        // 手动确认消费
        channel.basicAck(deliveryTag, false);
    } catch (Exception e) {
        // 处理消息处理失败的情况
        channel.basicNack(deliveryTag, false, true);
    }
}

失败重试

消费者在处理消息失败时，可以设置本地重试机制，而不是立即重新入队。这可以通过配置application.yaml文件中的spring.rabbitmq.listener.simple.retry.enabled、initial-interval、multiplier和max-attempts属性来实现。

yaml

spring:
  rabbitmq:
    listener:
      simple:
        retry:
          enabled: true
          initial-interval: 1000ms
          multiplier: 1
          max-attempts: 3

业务幂等性

幂等性是指一个操作可以被重复多次而不会改变结果的操作特性。对于消息队列中的消息消费而言，这意味着即使同样的消息被消费多次，也应该只产生一次业务效果。

这可以通过在业务代码中实现幂等性检查，例如使用唯一消息ID或业务状态判断来实现。

使用 Redis 实现幂等性

生成消息 ID:
- 每条消息都有一个全局唯一的 ID (messageId)，这个 ID 可以由生产者在发送消息时生成并附加在消息中。
消费者接收到消息:
- 当消费者从 RabbitMQ 接收到消息时，首先检查消息中包含的 messageId。
Redis 中记录消息状态:
- 在 Redis 中使用 SETNX 命令（Set if Not eXists）尝试为该 messageId 设置一个值。
  - 如果 SETNX 成功，则表示这是第一次处理这条消息。
  - 如果 SETNX 失败，则表示这条消息已经被处理过了。
检查消息状态:
- 如果 SETNX 成功，继续执行业务逻辑，并将 Redis 中对应的消息状态设置为已完成（例如设置为 "1"），并设置一个过期时间以防止死锁情况发生。
- 如果 SETNX 失败，根据 Redis 中的状态值决定是否继续处理：
  - 如果状态值为 "0"，表示消息正在被另一个消费者处理，当前消费者不做任何操作。
  - 如果状态值为 "1"，表示消息已经被成功处理，当前消费者可以安全地确认消息 (ack) 而无需重复执行业务逻辑。
设置过期时间:
- 为了避免因为异常情况导致的消息状态一直停留在 "0" 或 "1"，可以在设置状态的同时设置一个合理的过期时间。一旦过期，其他消费者仍然可以尝试处理该消息。
处理异常情况:
- 如果消费者在处理消息过程中遇到错误，应确保消息状态不被修改或回滚到初始状态（如 "0"），以便后续重试。

Redis 操作示例

初次处理消息:

查看代码

java

// 尝试使用 SETNX 设置状态
if (redis.setnx("messageId", "0")) {
    // 执行业务逻辑
    try {
        // 业务处理...
        redis.setex("messageId", 60, "1");  // 设置状态为完成，并设置过期时间为 60 秒
        rabbitMQ.acknowledge();            // 确认消息已处理
    } catch (Exception e) {
        // 处理异常情况
        redis.del("messageId");            // 清除状态
        throw e;
    }
} else {
    String status = redis.get("messageId");
    if ("0".equals(status)) {
        // 不做任何处理
    } else if ("1".equals(status)) {
        rabbitMQ.acknowledge();            // 直接确认消息
    }
}

延迟消息

在某些业务场景中，我们可能需要实现延迟消息功能，即消息在发送后不会立即被消费，而是等待特定时间后才被处理。RabbitMQ提供了两种实现延迟消息的方案：使用死信交换机（Dead Letter Exchange，DLX）和利用DelayExchange插件。

死信交换机

死信交换机是一种特殊的交换机，用于接收和处理无法被正常消费的消息，也称为死信。这些消息可能因为以下原因成为死信：

消费者使用basic.reject或basic.nack声明消费失败，并且消息的requeue参数设置为false。
消息是一个过期消息，超时无人消费。
要投递的队列消息满了，无法投递。

当一个队列中的消息成为死信后，如果这个队列通过dead-letter-exchange属性指定了一个交换机，那么这些死信就会投递到这个交换机中。然后，如果有队列与死信交换机绑定，死信最终会被投递到这个队列中。

实现延迟消息

设置TTL：首先，生产者在发送消息时为其设置一个TTL（Time To Live）。TTL是消息在队列中保持的最大时间，一旦TTL到期，消息将被视为过期。
发送消息：接着，生产者将设置了TTL的消息发送到一个正常的队列中。这个队列虽然暂时没有消费者，但却已经绑定了一个死信交换机。
消息的等待与过期：由于消息在队列中没有消费者消费，它们会等待TTL的到期。一旦TTL到期，这些消息就会被路由到死信交换机。
死信交换机的作用：死信交换机接收到过期消息后，可以将这些消息路由到其他的队列中。这些队列可以由其他消费者进行消费，从而实现延迟消息的处理。
消息过期后的处理：需要注意的是，RabbitMQ的消息过期是基于消息处于队首时才会被检查的方式来实现。这意味着，如果队列中消息堆积很多，过期消息可能不会被及时处理，导致实际延迟时间与预期设置的时间不一致。

DelayExchange插件

DelayExchange插件是RabbitMQ社区提供的一个插件，它提供了更简单的方式来实现延迟消息功能。使用DelayExchange插件，生产者可以直接发送消息到DelayExchange，并设置延迟时间，消息将在指定时间后路由到目标队列。

实现延迟消息

使用DelayExchange插件实现延迟消息的步骤如下：

安装并启用DelayExchange插件。
创建一个延迟交换机，并设置其延迟时间。
创建一个队列，并将其绑定到延迟交换机。
生产者发送消息到延迟交换机，并设置延迟时间。
消息在延迟时间过后被路由到绑定的队列中。

应用场景

延迟消息功能在许多业务场景中非常有用，例如：

订单超时处理：如果用户在一定时间内未支付，自动取消订单。
定时任务调度：例如，每天定时发送报告或提醒。
缓解系统压力：在高峰期，可以将一些非紧急任务延迟处理，以减轻系统负担。

Spring AMQP集成

Spring AMQP简介

Spring AMQP是Spring提供的一套用于简化RabbitMQ操作的框架。它包括了对RabbitMQ的封装，提供了一套更为简洁、直观的API，以及与Spring框架的无缝集成。通过Spring AMQP，开发者可以更加方便地管理RabbitMQ的连接、交换机、队列、绑定和消息等。

配置与管理

Spring AMQP的配置主要涉及以下几个方面：

连接工厂（ConnectionFactory）：用于创建与RabbitMQ服务器的连接。
RabbitTemplate：用于发送和接收消息的高级抽象。
消息转换器（MessageConverter）：用于消息的序列化和反序列化。
队列、交换机和绑定：用于声明RabbitMQ中的队列、交换机和它们之间的绑定关系。
监听器容器（ListenerContainer）：用于异步接收消息。

下面是一个使用Spring AMQP的简单示例，展示如何发送和接收消息。

添加依赖

在pom.xml中添加Spring Boot的RabbitMQ依赖：

xml

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-amqp</artifactId>
</dependency>

配置连接参数

在application.properties中配置RabbitMQ连接参数：

properties

spring.rabbitmq.host=localhost
spring.rabbitmq.port=5672
spring.rabbitmq.username=guest
spring.rabbitmq.password=guest

声明队列、交换机和绑定

使用@Bean注解在配置类中声明队列、交换机和绑定关系：

查看代码

java

@Configuration
public class RabbitConfig {
    @Bean
    public Queue myQueue() {
        return new Queue("myQueue");
    }
    @Bean
    public DirectExchange myExchange() {
        return new DirectExchange("myExchange");
    }
    @Bean
    public Binding binding(Queue myQueue, DirectExchange myExchange) {
        return BindingBuilder.bind(myQueue).to(myExchange).with("myRoutingKey");
    }
}

发送消息

使用RabbitTemplate发送消息：

java

@Autowired
private RabbitTemplate rabbitTemplate;
public void sendMsg(String msg) {
    rabbitTemplate.convertAndSend("myExchange", "myRoutingKey", msg);
}

接收消息

使用@RabbitListener注解在方法上监听队列：

java

@RabbitListener(queues = "myQueue")
public void receiveMsg(String msg) {
    System.out.println("Received message: " + msg);
}

集群架构模式

RabbitMQ 的几种集群架构模式，包括主备模式、镜像模式和多活模式。

主备模式（Warren模式）

特点：

简单性：主备模式是最简单的集群模式，实现和维护相对容易。
资源利用：备节点通常不参与消息的投递和消费，资源利用率较低。
自动故障转移：当主节点故障时，备节点可以自动接管服务。

实现方式：

配置主备节点：首先配置一个主节点，然后添加一个或多个备节点。
同步元数据：主备节点之间同步元数据，如队列定义、交换机、绑定等。
数据存储：所有消息都存储在主节点上，备节点不存储消息数据。
故障转移：当主节点故障时，备节点通过预设的机制（如使用 HAProxy 或 Keepalived）来接管主节点的角色。

应用场景：

低并发场景：适用于并发量不高，数据量较小的系统。
对数据一致性要求不高：由于备节点不存储消息，因此在故障转移时可能会有数据丢失。

镜像模式（Mirror模式）

特点：

数据高可用：消息数据在多个节点间复制，确保了数据的高可靠性。
负载均衡：消费者可以从任意一个镜像节点消费消息。
自动同步：消息的写入会自动同步到所有镜像节点。

实现方式：

配置镜像队列策略：通过 rabbitmqctl 命令或管理界面设置镜像队列策略，指定队列应该有多少个镜像。
数据同步：队列中的消息和状态会同步到所有镜像节点。
故障恢复：如果一个镜像节点故障，其他节点将继续提供服务。

应用场景：

高可用性需求：适用于对数据可靠性要求极高的系统。
读写分离：虽然镜像队列可以处理读写操作，但通常建议只在一个节点上进行写操作，以减少网络延迟。

多活模式（Federation模式）

特点：

地理分布：允许在不同的地理位置部署 RabbitMQ 集群。
数据复制：可以根据需要复制部分或全部消息数据到其他集群。
去中心化：各个集群独立运行，不需要中心控制节点。

实现方式：

配置Federation插件：在需要复制的集群上启用 Federation 插件。
定义上游和下游：配置哪些集群作为数据源（上游），哪些集群作为数据目的地（下游）。
数据传输：使用 AMQP 协议在集群之间传输数据。

应用场景：

异地容灾：适用于需要在多个数据中心之间进行数据复制的场景。
数据分发：可以在不同地理位置之间分发消息，以减少延迟。

Shovel集群模式

特点：

灵活的数据复制：可以指定源队列和目标队列，实现精细的数据复制。
复杂的配置：配置较为复杂，需要明确指定数据复制的规则。

实现方式：

配置Shovel插件：在需要复制的节点上启用 Shovel 插件。
定义Shovel：配置 Shovel 规则，指定源和目标队列，以及数据复制的条件。

应用场景：

特定数据复制需求：适用于需要将特定队列的数据复制到另一个集群或另一个队列的场景。

安装与配置 ​

核心组件 ​

Broker服务器 ​

Exchange交换机 ​

Fanout交换机 ​

Direct交换机 ​

Topic交换机 ​

Headers交换机 ​

Queue队列 ​

Binding绑定关系 ​

组成元素 ​

绑定类型 ​

Connection连接 ​

Message消息 ​

消息的基本结构 ​

消息的生命周期 ​

Producer生产者 ​

Consumer消费者 ​

Channel信道 ​

为什么使用信道 ​

信道的工作原理 ​

性能优势 ​

Virtual Host虚拟主机 ​

高级特性 ​

消息可靠性 ​

生产者可靠性 ​

MQ可靠性 ​

消费者可靠性 ​

确认机制 ​

失败重试 ​

业务幂等性 ​

使用 Redis 实现幂等性 ​

Redis 操作示例 ​

延迟消息 ​

死信交换机 ​

实现延迟消息 ​

DelayExchange插件 ​

实现延迟消息 ​

应用场景 ​

Spring AMQP集成 ​

Spring AMQP简介 ​

配置与管理 ​

集群架构模式 ​

主备模式（Warren模式） ​

特点： ​

实现方式： ​

应用场景： ​

镜像模式（Mirror模式） ​

特点： ​

实现方式： ​

应用场景： ​

多活模式（Federation模式） ​

特点： ​

实现方式： ​

应用场景： ​

Shovel集群模式 ​

特点： ​

实现方式： ​

应用场景： ​

安装与配置

核心组件

Broker服务器

Exchange交换机

Fanout交换机

Direct交换机

Topic交换机

Headers交换机

Queue队列

Binding绑定关系

组成元素

绑定类型

Connection连接

Message消息

消息的基本结构

消息的生命周期

Producer生产者

Consumer消费者

Channel信道

为什么使用信道

信道的工作原理

性能优势

Virtual Host虚拟主机

高级特性

消息可靠性

生产者可靠性

MQ可靠性

消费者可靠性

确认机制

失败重试

业务幂等性

使用 Redis 实现幂等性

Redis 操作示例

延迟消息

死信交换机

实现延迟消息

DelayExchange插件

实现延迟消息

应用场景

Spring AMQP集成

Spring AMQP简介

配置与管理

集群架构模式

主备模式（Warren模式）

特点：

实现方式：

应用场景：

镜像模式（Mirror模式）

特点：

实现方式：

应用场景：

多活模式（Federation模式）

特点：

实现方式：

应用场景：

Shovel集群模式

特点：

实现方式：

应用场景：