Distributed RabbitMQ

RabbitMQ 官方给出了 3 种方式

Clustering(原生集群)

客户端可连接任意节点，节点间通过 Erlang Cookie 通信

所有节点共享元数据(交换机/队列定义)，但队列(Classic Queues)内容默认仅存在于创建节点，其它节点只有该队列内容的引用(队列定义)，因此访问到引用时需要转到有具体数据的节点上

Mirror(镜像队列)

本质是 Clustering 的增强策略，类似主从模式

镜像队列(Mirrored Classic Queues)可通过配置 x-ha-policy 参数让队列数据同步到其它节点上

镜像队列可能会出现主从数据不一致(主节点收到数据后宕机了，还没向从节点发送)，3.9 标记 deprecated，4.0 已经移除

Quorum(仲裁队列)

仲裁队列(Quorum Queues)用于替代镜像队列，基于 Raft 算法达到一致性

Warren(主备模式)

非官方推荐方案：传统 VIP 方案(如 Keepalived + HAProxy)，已被 Clustering + Quorum 方案取代，官方文档不推荐，因其存在脑裂风险

Federation(联邦插件/多活模式)

无需建立集群就可进行节点间数据同步

官方推荐的跨数据中心方案是使用 Federation 或 Shovel，而不是传统的集群模式，因为集群设计用于低延迟、高带宽的局域网环境。跨广域网的集群会遇到脑裂、网络分区等问题，导致性能下降和稳定性问题

单向消息转发(Upstream→Downstream)，使用 AMQP 协议跨不同 RabbitMQ 实例 / Vhost 传输，自动重连机制适合不稳定的广域网

Shovels(消息铲插件/远程模式)

与 Federation 的关键差异：更轻量的静态单向转发，支持多种协议(AMQP, AMQP 1.0, MQTT)，需显式配置源/目标地址

 

---

https://www.rabbitmq.com/docs/distributed

https://www.bilibili.com/video/BV1sw4m1U7Qe?p=56