RabbitMQ集群架构和原理解析

RabbitMQ 四种集群架构

• 主备模式：warren（兔子窝），一个主/备方案（主节点如果挂了，从节点），与提供服务，和ActiveMQ 利用Zookeeper做主/备一样）ActiveMQ不同的是，RabbitMQ主使用HaProxy路由。当主节点恢复后，会成为备份节点的备份节点，会进行漂移
  
  可以理解为是热备份，有一个Master和一个Slave, 正常情况下，Master是对外提供读写的，而Slave仅仅作为一个备份，当系统出现异常的时候，比如说Master遇到宕机时，会做一个切换，Slave节点会升级成Master节点，继续对外提供服务（主从切换）

主备模式-HaProxy 配置

• 远程模式：远距离通信和复制，可以实现双活的一种模式，简称Shovel模式。
  所谓的Shovel就是我们可以把消息进行不同数据中心的复制工作，可以跨地域的让两个mq集群互联。
  
  RabbitMQ早期提供的一种多活的存储，主要是做数据的异地容灾，异地转移，也可以提升性能，比如说当我们单节点（单个集群）处理不过来的时候，可以把消息转发到某个下游的集群模式中，这种方式的架构非常简单，但是配置很复杂。

Shovel集群的配置步骤

• 镜像模式：非常经典的集群模式，保证100%数据不丢失。镜像模式类似于MongoDB的复制集概念。

工作中用的最多，实现非常简单，互联网大厂也会用。
Mirror镜像队列：高可靠、数据同步、3节点（推荐奇数个节点）
缺点：无法横向扩容。

• 多活模式：实现异地数据复制的主流方式。
  需要依赖federation插件，可实现持续的可靠的AMQP数据通信，配置与应用非常简单。
  

与远程模式差不多，就是做一个异地的容灾，或者数据的转储功能，路由转发的而功能

Federation插件：可以在broker或cluster之间传输，可以看成exchanges：下游从上游拉去消息，可视化添加路由。

RocketMQ¹

---

1. 下期分享RocketMQ消息中间件集群架构与原理解析 ↩︎