RabbitMQ支持多种集群模式，主要包括以下几种：普通集群模式、镜像队列模式、主备模式、远程模式、多活模式
普通集群模式
主要通过在多个节点之间共享配置和状态信息来工作，多个RabbitMQ服务器实例（节点）通过配置彼此的网络地址和端口号形成一个集群。节点间通过Erlang分布式系统进行通信，共享元数据，如交换器（Exchanges）、队列（Queues）和绑定（Bindings）。
集群对外表现为一个单一的RabbitMQ实例，集群可以在多个节点之间分发客户端的连接和消息流量，通过分散负载，可以提高整体的处理能力和可用性。
优点：
- 扩展性：普通集群模式允许水平扩展，可以通过增加节点来提高系统的吞吐量和负载能力。
- 负载均衡：在集群中，客户端连接和消息路由可以在多个节点之间分发，从而实现负载均衡。
- 高并发：普通集群模式支持高并发的连接和消息处理，适合于需要处理大量消息的系统。
- 元数据共享：集群中的节点可以共享交换器、队列和绑定等元数据，这使得管理和维护变得更加方便。
- 灵活性：普通集群模式提供了灵活的配置选项，可以根据业务需求对集群进行调整和优化。
缺点：
- 单点故障：队列数据仅存储在一个节点上。如果该节点发生故障，存储在该节点上的消息可能会丢失（除非消息被设置为持久化）。
- 消息丢失风险：如果队列所在的节点宕机，并且消息没有被持久化，那么未被消费的消息将会丢失。
- 复杂性：集群的搭建和管理相对于单机部署来说更为复杂，需要更多的配置和维护工作。
- 性能开销：集群内部的消息路由和节点间通信可能会引入额外的性能开销。
- 不适合数据高可用性要求：对于对数据丢失零容忍的业务场景，普通集群模式可能不是最佳选择，因为它不提供消息的跨节点复制。
镜像模式（高可用模式）
队列中的消息会在多个节点间进行同步复制，确保即使某个节点发生故障，队列中的消息也不会丢失。集群中的队列有一个主节点（Master）和多个镜像节点（Mirrors），主节点负责处理生产者发送的消息，将它们存储在本地队列中，并负责将这些消息复制到镜像节点。镜像节点接收来自主节点的复制消息，并在自己的本地队列中存储这些消息的副本。消费者可以从任何节点消费消息，镜像节点会丢弃已在主节点上确认的消息，以避免重复消费。
RabbitMQ 3.8 版本以后引入了仲裁队列，用来替代镜像队列，它同样是主从模式的，并且使用非常简单，底层的主从同步是基于 Raft 协议，具有强一致的特点。
优点：
- 数据冗余：镜像队列模式通过在多个节点间复制队列数据，提供了数据冗余，从而减少了单点故障导致的数据丢失风险。
- 高可用性：如果主节点发生故障，最老的镜像节点可以自动提升为新的主节点，确保了服务的连续性和可用性。
- 容错能力：即使在部分节点宕机的情况下，镜像队列模式仍然能够保证消息的传递和服务的运行。
- 消息不丢失：所有发送到镜像队列的消息都会被复制到所有镜像节点，即使主节点宕机，消息也不会丢失。
- 支持事务和确认：镜像队列支持事务和publisher confirm机制，进一步确保了消息的可靠性。
缺点：
- 性能开销：镜像队列模式需要在节点间同步消息，这会增加网络和磁盘I/O的负载，可能导致性能下降。
- 存储压力：由于每个节点都需要存储完整的队列数据副本，这会增加存储资源的需求。
- 复杂性增加：配置和管理镜像队列比普通队列更为复杂，需要更多的维护工作。
- 消息处理延迟：在主节点宕机并进行故障转移时，可能会有短暂的服务中断和消息处理延迟。
- 不适用于所有场景：对于消息量极大或者对延迟敏感的应用，镜像队列可能不是最佳选择，因为它可能会增加消息传输的延迟。
- 启动顺序和故障恢复：在节点启动和故障恢复时，需要特别注意启动顺序和故障恢复策略，以避免数据不一致或服务中断。
主备模式（Warren模式）
集群中的一个节点作为主节点（Master），负责处理所有的读写操作，而其他节点作为备份节点（Slaves），仅在主节点宕机时提供服务。当主节点发生故障时，备份节点中的一个会被自动选举为新的主节点。主备模式的优点在于其简单性和易于实现，但它也有一些局限性，例如备份节点在正常情况下不参与消息处理，可能导致资源的浪费。此外，故障转移过程中可能会有短暂的服务中断，对于对延迟敏感的应用来说，这可能是一个问题。
优点：
- 简单性：主备模式相对简单，易于理解和部署。它只需要一个主节点来处理所有的读写操作，而备份节点仅在主节点宕机时提供服务。
- 高可用性：在主节点发生故障时，备份节点可以自动切换成为新的主节点，从而保证了服务的连续性和可用性。
- 资源利用：在正常情况下，备份节点不需要参与消息处理，可以将资源集中在主节点上，提高了资源的利用效率。
- 故障转移：主备模式支持自动故障转移，当主节点宕机时，备份节点可以迅速接管服务，减少了人为干预的需求。
缺点：
- 单点故障风险：尽管主备模式提供了一定程度的高可用性，但如果主节点宕机，仍然需要进行故障转移操作，这可能会导致短暂的服务中断。
- 备份节点的闲置：在主节点正常运行时，备份节点通常不参与消息处理，这可能导致资源的浪费。
- 性能限制：由于所有的读写操作都集中在主节点上，如果主节点的性能不足，可能会成为系统瓶颈。
- 数据同步问题：在主备模式中，备份节点需要与主节点保持数据同步，这可能会引入额外的网络和存储开销。
- 复杂的故障恢复：虽然主备模式支持自动故障转移，但在实际操作中，故障恢复过程可能会涉及到复杂的配置和数据同步问题。
- 扩展性限制：主备模式在扩展性方面有一定的限制，因为它依赖于单个主节点来处理所有的消息，这可能不适合高并发和大数据量的场景。
远程模式（Shovel模式）
实现不同数据中心或地理位置之间的消息复制和同步的集群架构，在两个或多个RabbitMQ集群之间进行消息的远距离传输和复制，从而实现双活或多活集群。远程模式依赖于RabbitMQ的Shovel插件，源集群是消息的生产者，它负责产生和发送消息。目标集群是消息的消费者，它接收来自源集群的消息。Shovel插件可以配置为同步或异步复制消息。 在同步复制模式下，消息在源集群中被发送并在目标集群中被确认之前，不会被视为已处理。在异步复制模式下，消息在源集群中被发送后，不会等待目标集群的确认，这可以提高吞吐量但可能会牺牲一定的可靠性。
优点：
- 跨地域复制：Shovel模式允许在不同地理位置的RabbitMQ集群之间复制消息，这对于跨数据中心的消息同步非常有用。
- 灵活的配置：Shovel插件提供了灵活的配置选项，可以根据需要设置消息的复制规则和目标集群。
- 负载均衡：通过Shovel模式，可以将消息负载分发到不同的集群，从而实现负载均衡和优化资源使用。
- 灾难恢复：远程模式可以用于灾难恢复策略，确保在主集群出现故障时，消息可以在备用集群中继续处理。
- 异步复制：Shovel模式支持异步复制，可以提高消息传输的效率，尤其是在网络延迟较高的情况下。
缺点： -- 复杂性：Shovel模式的配置和管理相对复杂，需要对RabbitMQ和网络通信有深入的了解。
- 性能开销：消息复制会消耗额外的网络和处理资源，可能会影响集群的性能。
- 消息延迟：由于消息需要在网络中传输，可能会增加消息的延迟，特别是在跨地域部署时。
- 版本兼容性：Shovel模式可能需要集群中的RabbitMQ版本保持一致或兼容，否则可能会导致配置问题或消息复制失败。
多活模式（Federation模式）
异地数据复制和消息共享的集群架构。这种模式允许在不同的数据中心或地理位置部署的RabbitMQ集群之间进行消息的双向复制和通信。多活模式依赖于RabbitMQ的Federation插件，该插件允许在不同的RabbitMQ服务器（或集群）之间建立消息路由。 消息可以从一个集群（Upstream）主动拉取到另一个集群（Downstream），或者反过来。同时支持持续的消息同步，确保在一个集群中发布的消息能够及时地复制到其他集群。
优点：
- 异地数据复制：多活模式通过Federation插件实现了不同数据中心之间的消息复制，这对于实现地理分布式部署和灾难恢复非常有用。
- 高可用性：多活模式通过在多个数据中心部署RabbitMQ集群，提高了整体的可用性和容错能力。如果一个数据中心发生故障，其他数据中心仍然可以继续处理消息。
- 配置简单：相比于Shovel模式，多活模式的配置更加简单，因此在实际应用中更为主流。
- 灵活的消息路由：Federation插件允许定义复杂的路由规则和过滤条件，可以实现高度定制化的消息路由。
- 跨版本和跨集群通信：Federation插件支持不同版本的RabbitMQ和Erlang之间的通信，以及使用不同用户和虚拟主机的集群之间的消息传输。
缺点：
- 网络带宽压力：由于需要在不同数据中心之间复制消息，这可能会导致网络带宽的大量消耗，特别是在消息量大的情况下。
- 消息延迟：跨数据中心的消息传输可能会受到网络延迟的影响，从而增加消息的传输延迟。
- 复杂性管理：虽然配置相对简单，但在多活模式下管理多个数据中心的集群仍然需要一定的专业知识和经验。
- 故障转移和数据一致性：在多活模式中，确保跨数据中心的数据一致性和故障转移的正确性可能会比较复杂。
- 性能开销：持续的消息同步和消息路由可能会导致额外的性能开销，尤其是在跨地域部署时。
