之前在网上找rabbitmq集群方案有哪几种时，基本上看到的答案都不太一样，所以此文的主要目的是梳理一下rabbitmq集群方案，对rabbitmq集群方案的笔记并不是搭建的笔记。
总结了一些文章，rabbitmq集群大概有五种方案：普通集群、镜像集群(高可用)、Quorum(仲裁)队列、Streams集群模式(高可用+负载均衡)、插件方式。
添加图片注释，不超过 140 字（可选）
我们来看看rabbitmq集群搭建的步骤，主要包括以下几步：
- 准备工作：安装 Erlang和RabbitMQ 。
- 集群配置：
- 修改/etc/hosts文件以确保节点间可以互相解析。
- 配置Erlang Cookie以确保节点间可以通信。
- 启动独立节点并创建集群。
- 配置同步(原本叫配置镜像队列)：为了提高集群的可用性和容错性，可以配置镜像队列来在集群中的多个节点上复制存储消息。
以上就是rabbitmq集群搭建的大致步骤，可以看到比较关键的地方就是搭建集群(官方叫集群形成Cluster Formation)与配置镜像队列。也就是官方文档中的
- How clusters are formed（集群形成）
- Queue and stream leader replica placement strategies（集群节点同步）
下面就来具体分析一下：
添加图片注释，不超过 140 字（可选）
一、集群形成
添加图片注释，不超过 140 字（可选）
- 通过在配置文件中列出集群节点以声明方式
- 以声明方式使用基于 DNS 的发现
- 以 AWS （EC2） 实例发现（通过插件）的声明方式
- 以声明方式使用 Kubernetes 发现（通过插件）
- 声明性地使用基于 Consul 的发现（通过插件）
- 以声明方式使用基于 etcd 的发现（通过插件）
- 使用 rabbitmqctl 手动操作
最常用的应该还是使用 rabbitmqctl 手动操作的方式
二、集群方案
RabbitMQ提供了几种不同的节点同步模型，每种模型都有其特定的用途和权衡。让我们来详细探讨一下RabbitMQ中的主要节点同步模型：
2.1、普通模式
在普通集群中，队列的内容只存在于其声明的节点上。其他节点只存储元数据（如队列名称、绑定关系等）。当客户端连接到非队列所在节点并执行诸如消费消息的操作时，该节点会作为代理，将请求转发给实际持有队列的节点。
添加图片注释，不超过 140 字（可选）
如果生产者向集群中的Node3节点发送一条消息，此时集群中的其它节点是没有这条消息的，只有Node3才这条消息。
- 优点：资源利用效率高，因为消息不会被复制到所有节点。
- 缺点：如果持有队列的节点宕机，该队列将不可用，直到节点恢复。
2.2、镜像队列模式（Classic Queue Mirroring）
镜像队列是RabbitMQ实现高可用性的传统方式。队列可以在集群中的多个节点上拥有镜像（副本）。有一个主副本（master）和多个从副本（slave）。所有对队列的操作都首先在主副本上执行，然后异步复制到从副本。
添加图片注释，不超过 140 字（可选）
如果生产者向集群发送一条消息，此时集群中的其它节点都会有这条消息。
- 优点：提高了可用性，因为如果主副本所在的节点失效，最老的从副本会被提升为新的主副本。
- 缺点：
- 增加了网络带宽和磁盘空间的使用，因为每个消息都被复制到所有镜像。
- 写入吞吐量可能下降，因为每个操作都需要被复制。
- 在网络分区的情况下可能导致脑裂或数据丢失。
Classic Queue Mirroring已被弃用
在RabbitMQ的早期版本中，经典队列镜像允许队列内容在集群中的多个节点上进行复制，以实现高可用性。然而，由于其性能和可扩展性的限制，它将在RabbitMQ 4.0版本中被弃用，并建议使用Quorum队列和Streams作为替代。
添加图片注释，不超过 140 字（可选）
翻译： 本指南介绍了已弃用且计划删除的功能：经典队列的镜像（队列内容复制）。应使用 Quorum queues and/or streams，而不是镜像经典队列。
Classic Queue Mirroring（经典队列镜像）是RabbitMQ中的一种机制，用于实现高可用性。它的工作原理可以通过以下几点来解释：
2.3、Quorum队列模式（仲裁队列）
Quorum队列是在RabbitMQ 3.8中引入的，旨在克服镜像队列的一些限制。基于Raft共识算法，提供更强的一致性保证。队列数据在奇数个节点（通常是3或5）之间复制。只要大多数节点（即quorum）可用，队列就能继续工作。
添加图片注释，不超过 140 字（可选）
Quorum队列与镜像队列类似，不过在性能与完整性做了权衡，只要集群中的大多数节点（即quorum）可用。另外集群的节点使用的是Leader和follower。
- 优点：
- 更好的故障处理：能更优雅地处理网络分区，减少数据丢失的风险。
- 显式的故障转移：不像镜像队列中的隐式故障转移，Quorum队列中的leader选举是明确的。
- 没有脑裂问题：由于使用了共识算法，即使在网络分区的情况下也能保证数据一致性。
- 缺点：
- 由于需要在多数节点上达成一致，可能比镜像队列稍慢一些。
- 不支持一些高级特性，如优先级队列、消息TTL等。
2.4、流模式（Streams）
Streams是RabbitMQ 3.9+ 最新引入的一种新型数据结构，借鉴了Apache Kafka的一些理念。消息以追加日志的形式存储，支持多消费者订阅，每个消费者维护自己的消费位置。
添加图片注释，不超过 140 字（可选）
RabbitMQ 3.9引入了流特性，它是为高吞吐量场景优化的。流由领导者和副本Erlang进程组成，分布在RabbitMQ集群的节点上。发布应用程序可以连接到任何节点，消息会自动转发到领导者进程所在的节点。而消费应用程序必须连接到包含流成员的节点，以利用sendfile优化。
- 优点：
- 持久化开销小，非常适合需要长期存储大量消息的场景。
- 支持消息重放，消费者可以从任意位置开始消费。
- 集群复制基于Raft算法，提供了类似Quorum队列的一致性保证。
- 缺点：
- 作为新特性，可能还不够成熟，某些客户端库的支持可能有限。
2.5、插件
Shovel Plugin
Shovel Plugin 的主要目标是实现消息从一个 RabbitMQ 集群（或单个节点）到另一个 RabbitMQ 集群（或单个节点）的可靠传输。它通常用于在地理上分散的集群之间传递消息，或者在需要跨数据中心传递消息时使用。也有人把它叫成远程模式。
Federation Plugin
Federation Plugin 旨在允许 RabbitMQ 集群之间的动态消息共享。这意味着在不进行消息的物理传输的情况下，可以在多个 RabbitMQ 集群之间共享消息流，通常用于构建更松散耦合的集群架构。也有人把它叫成多活模式。
总结
- 目前推荐使用的集群模式就是Quorum队列与Streams，大多数应该还是Quorum队列模式。
- Quorum队列支持的是高可用集群，而Streams模式即支持高可用集群与支持负载均衡集群。当然Quorum队列模式也可以借助如HAproxy来支持负载均衡。
- 另外除了以上说的方式外还有一些插件可以搭建集群如federation搭建多活集群。
