RabbitMQ 的4种集群架构

1. 主备模式

    也称为 Warren (兔子窝) 模式。实现 rabbitMQ 的高可用集群,一般在并发和数据量不高的情况下,这种模式非常的好用且简单。

    也就是一个主/备方案,主节点提供读写,备用节点不提供读写。如果主节点挂了,就切换到备用节点,原来的备用节点升级为主节点提供读写服务,当原来的主节点恢复运行后,原来的主节点就变成备用节点,和 activeMQ 利用 zookeeper 做主/备一样,也可以一主多备。


HaProxy 配置:

listen rabbitmq_cluster

bind 0.0.0.0:567  # 配置 tcp 模式

mode tcp  # 简单的轮询

balance roundrobin  # 主节点 roundrobin  随机

server 你的76机器 hostname  192.168.11.76:5672 check inter 5000 rise 2 fall 2

server 你的77机器 hostname  192.168.11.77:5672 backup check inter 5000 rise 2 fall 2  # 备用节点

    注意了,上面的 rabbitMQ 集群节点配置 # inter 每隔 5 秒对 mq 集群做健康检查, 2 次正确证明服务可用,2 次失败证明服务器不可用,并且配置主备机制

2. 远程模式

    远程模式可以实现双活的一种模式,简称 shovel 模式,所谓的 shovel 就是把消息进行不同数据中心的复制工作,可以跨地域的让两个 MQ 集群互联,远距离通信和复制。

    Shovel 就是我们可以把消息进行数据中心的复制工作,我们可以跨地域的让两个 MQ 集群互联。

远程模式

如图所示,有两个异地的 MQ 集群(可以是更多的集群),当用户在地区 1 这里下单了,系统发消息到 1 区的 MQ 服务器,发现 MQ 服务已超过设定的阈值,负载过高,这条消息就会被转到 地区 2 的 MQ 服务器上,由 2 区的去执行后面的业务逻辑,相当于分摊我们的服务压力。

    在使用了 shovel 插件后,模型变成了近端同步确认,远端异步确认的方式,大大提高了订单确认速度,并且还能保证可靠性。

shovel 模式拓扑图

    如上图所示,当我们的消息到达 exchange,它会判断当前的负载情况以及设定的阈值,如果负载不高就把消息放到我们正常的 warehouse_goleta 队列中,如果负载过高了,就会放到 backup_orders 队列中。backup_orders 队列通过 shovel 插件与另外的 MQ 集群进行同步数据,把消息发到第二个 MQ 集群上。

    这是 rabbitMQ 比较早期的架构模型了,现在很少使用了。

shovel 集群的配置,首先启动 rabbitmq 插件,命令如下:

    rabbitmq-plugins enable amqp_client

    rabbitmq-plugins enable  rabbitmq_shovel

    在 /etc/rabbitmq/ 目录下创建 rabbitmq.config 文件。注意,我们源服务器和目的地服务器都使用这个相同的配置文件。

    具体配置如下

3. 镜像模式

    非常经典的 mirror 镜像模式,保证 100% 数据不丢失。在实际工作中也是用得最多的,并且实现非常的简单,一般互联网大厂都会构建这种镜像集群模式。

    mirror 镜像队列,目的是为了保证 rabbitMQ 数据的高可靠性解决方案,主要就是实现数据的同步,一般来讲是 2 - 3 个节点实现数据同步。对于 100% 数据可靠性解决方案,一般是采用 3 个节点。

    集群架构如下

 mirror 镜像队列

    如上图所示,用 KeepAlived 做了 HA-Proxy 的高可用,然后有 3 个节点的 MQ 服务,消息发送到主节点上,主节点通过 mirror 队列把数据同步到其他的 MQ 节点,这样来实现其高可靠。

4. 多活模式

    也是实现异地数据复制的主流模式,因为 shovel 模式配置比较复杂,所以一般来说,实现异地集群的都是采用这种双活 或者 多活模型来实现的。这种模式需要依赖 rabbitMQ 的 federation 插件,可以实现持续的,可靠的 AMQP 数据通信,多活模式在实际配置与应用非常的简单。

    rabbitMQ 部署架构采用双中心模式(多中心),那么在两套(或多套)数据中心各部署一套 rabbitMQ 集群,各中心的rabbitMQ 服务除了需要为业务提供正常的消息服务外,中心之间还需要实现部分队列消息共享。

多活集群架构如下:


    federation 插件是一个不需要构建 cluster ,而在 brokers 之间传输消息的高性能插件,federation 插件可以在 brokers 或者 cluster 之间传输消息,连接的双方可以使用不同的 users 和 virtual hosts,双方也可以使用不同版本的 rabbitMQ 和 erlang。federation 插件使用 AMQP 协议通信,可以接受不连续的传输。federation 不是建立在集群上的,而是建立在单个节点上的,如图上黄色的 rabbit node 3 可以与绿色的 node1、node2、node3 中的任意一个利用 federation 插件进行数据同步。


    如上图所示,federation exchanges 可以看成 downstream 从 upstream 主动拉取消息,但是并不是拉取所有消息,必须是在 downstream 上已经明确定义 Bingdings 关系的 exchange,也就是有实际的物理 queue 来接收消息,才会从 upstream 拉取消息到 downstream 。

    它使用 AMQP 协议实现代理间通信,downstream 会将绑定关系组合在一起,绑定/解绑命令将发送到 upstream 交换机。因此,federation exchange 只接收具有订阅的消息。

推荐阅读更多精彩内容

  • 了解RabbitMQ集群架构 主备模式 实现RabbitMQ的高可用集群,一般在并发和数据量不高的情况下,这种模式...
    一行代码一首诗阅读 7,516评论 1 20
  • 利用RabbitMQ集群横向扩展能力,均衡流量压力,让消息集群的秒级服务能力达到百万,Google曾做过此类实验;...
    有货技术阅读 2,020评论 0 1
  • 关于消息队列,从前年开始断断续续看了些资料,想写很久了,但一直没腾出空,近来分别碰到几个朋友聊这块的技术选型,是时...
    预流阅读 269,156评论 46 608
  • 由于之前做的项目中需要在多个节点之间可靠地通信,所以废弃了之前使用的Redis pub/sub(因为集群有单点问题...
    商领云阅读 8,122评论 3 63
  • RabbitMQ 简介 MQ 消息队列,上承生产者,下接消费者。从生产者侧获取消息,然后将消息转发给消费者。由此可...
    2205阅读 1,788评论 1 9