RabbitMQ 部署方式选择_rabbitmq的部署模式

部署模式

RabbitMQ支持多种部署模式，可以根据应用的需求和规模选择适合的模式。以下是一些常见的RabbitMQ部署模式：

• 单节点模式： 最简单的部署方式，所有的RabbitMQ组件（消息存储、交换机、队列等）都运行在单个节点上。适用于小型应用或者开发和测试环境，但不具备高可用性和容错能力。

• 集群模式： RabbitMQ集群由多个节点组成，分布在不同的物理服务器上。集群提供高可用性和容错性，其中一个节点出现故障时，其他节点可以继续提供服务。集群模式需要仔细的配置和管理，以确保数据同步和故障转移的正确性。

• 镜像队列模式： 镜像队列模式是集群模式的一种变体，用于提供队列级别的高可用性。队列的内容被复制到集群中的多个节点上，确保在节点故障时仍然可以访问数据。

• 仲裁队列模式：仲裁队列模式是镜像队列的替代方案，用于提供队列级别的高可用性。队列内容被复制集群中的多个节点上，通过raft算法保证数据的一致性。使用仲裁队列时，需要保证集群至少有一半以上节点可用。

• 双机房模式：用于保证在其中一个机房MQ服务不可用时，可以将服务切换到另一个机房，避免单机房故障。该方案对机房间、机房内部网络都有很高要求，否则会有很多可靠性问题。

单机部署模式

单机部署模式是最简单的部署模式，该模式下RabbitMQ不具备高可用性: MQ节点下线后，所有依赖RabbitMQ的服务将无法提供服务。

优点

• 简单易部署：单节点部署非常简单，不需要复杂的配置或管理。

• 适用于小型应用：对于小型应用或开发/测试环境，单节点部署足够满足需求。

• 成本低廉：由于只需部署单个节点，因此硬件和资源需求较低，成本相对较低。

缺点

• 容错性差：单节点部署的容错性较差，如果节点出现故障，整个系统可能会中断。没有故障转移或冗余机制来保证可用性。

• 扩展性有限：无法满足大规模应用的需求，无法水平扩展来提高性能和处理能力。

• 单点故障：由于只有一个节点，所以存在单点故障的风险，一旦节点出现问题，整个消息传递系统将不可用。

• 无法实现高可用性：缺乏故障转移和冗余机制，因此无法实现高可用性和持久性，消息可能会丢失或不可达。

使用场景

开发环境。

集群模式

普通集群模式下，队列数据节点分布在各节点中，具备较好的负载均衡能力，需要注意：该模式下如果有节点下线则该节点上的队列状态会变成down状态，正在消费队列消息的消费者也将会被下线。

优点

• 具备负载均衡能力：相比于单点部署模式，普通集群模式下，不同队列的消息生产者和消费者可以连接到不通过节点，节点之间通过内部代理的方式将消息发送请求和消费请求转发到内部数据节点。

• 可用性相比于单点模式有增强：单个节点进程不可用后，只要队列数据不可用的节点不是队列数据所在节点，则队列可用性不受影响。

缺点

队列数据缺少副本，队列数据所在节点不可用后， 和队列相关的消息将不会进入队列，队列中的消息将无法消费。

使用场景

对性能要求较高，但是对队列可用性较低的场景。

镜像队列模式

镜像集群模式下，非临时队列会有多个副本（分master副本和slave副本）分散在各节点下，单个节点下线不影响整体可用性。镜像队列内部采用可靠组播方式来保证集群内各副本数据的一致，对网络稳定性有很高要求。需要注意的是：启用了镜像模式后，消息需要在多个节点之间同步，性能相对单节点或者普通节点而言会有降低，且镜像队列副本数越多性能损失越大。

优点

• 相比于普通集群，镜像队列支持队列级别的高可用，部分节点出现不可用故障不会影响队列整体的可用性。

• 可通过任意一个节点将数据复制到镜像队列副本，客户端无序关心队列master节点位置。

缺点

• 数据通过可靠性组播方式来完成镜像队列副本数据同步，效率低下，对性能影响较大。

• 镜像队列副本不支持增量数据同步， 同步时会删除本地数据全量从master副本所在节点拉取数据，拉取数据过程中，集群不可用。

• 受网络稳定性影响较大，分区恢复过程中不稳定的网络环境容易导致队列crash并进一步引发消费者掉线、消息发送阻塞等现象。

• RabbitMQ官方已不在维护，计划在4.0版本中删除镜像队列。

使用场景

在MQ 版本低于3.8的版本中推荐使用， 镜像队列是3.8版本之前版本中唯一支持高可用的方案， 为了减少网络分区导致的各种问题，建议使用3节点 + pause_minority模式。

仲裁队列模式

仲裁队列是RabbitMQ官方支持的新一代高可用队列，内部采用Raft算法实现，队列副本也会分leader角色和follow角色，只要一半以上节点可用集群即可用，其在高可用和性能之间做了很好的平衡。

优点

• 相比于镜像队列，仲裁队列在一致性算法上做了升级，换成了raft算法，节点同步的容错能力明显增强：只需要一半以上的节点完成同步确认即可认为成功。

• 相比于镜像队列需要全量同步情况，仲裁也做了优化：支持增量同步，并且同步过程中并不会导致整个集群不可用。

• 相比于镜像队里，不存在队列副本之间的分区问题。

缺点

• 低于3.8的版本中不支持仲裁队列

• 要求集群节点为奇数，部分特性，如优先级不支持，部分特性如ttl，长度限制需要3.10版本支持。

使用场景

新环境对接使用3.10以上版本RabbitMQ 包含3个节点的仲裁队列集群。

双机房模式

多机房部署RabbitMq集群，防止因单机房出问题到时服务不可用。

优点

相比于普通的单机房镜像队列集群，双机房模式下， 可以避免集群出现单机房故障引发的整个集群不可用问题。

缺点

启用双机房模式后，客户端需要开启主机房定位策略来保证所有队列的主副本在主机房的节点上，无法做到队列master副本的负载均衡，且从理论上而言，并不能完全做到所有主副本都在主机房节点

使用场景

针对跨机房MQ的应用场景，官方的建议是不推荐同一个集群内的MQ节点之间跨机房，推荐的做法是各机房MQ集群独立部署，通过sholve或者federation插件来进行数据同步。