phprabbitmq集群技巧_详解RabbitMQ的4种集群架构主备远程镜像模式多活模式

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

HaProxy 配置:

listen rabbitmq_clusterbind 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 2server 你的77机器 hostname 192.168.11.77:5672 backup check inter 5000 rise 2 fall 2 # 备用节点

把稳了，上面的 rabbitMQ 集群节点配置 # inter 每隔 5 秒对 mq 集群做康健检讨， 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 比较早期的架构模型了，现在很少利用了。

非常经典的 mirror 镜像模式，担保 100% 数据不丢失。
在实际事情中也是用得最多的，并且实现非常的大略，一样平常互联网大厂都会构建这种镜像集群模式。

mirror 镜像行列步队，目的是为了担保 rabbitMQ 数据的高可靠性办理方案，紧张便是实现数据的同步，一样平常来讲是 2 - 3 个节点实现数据同步。
对付 100% 数据可靠性办理方案，一样平常是采取 3 个节点。

集群架构如下

mirror 镜像行列步队

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

这个也是实现异地数据复制的主流模式，由于 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 只吸收具有订阅的。

实在四种模式建议大家重点节制第三种，镜像模式属于标准的集群镜像模式。
其他几种模式都存在涌现脏数据问题的可能，后面会分享更多devops和DBA方面内容，感兴趣的朋友可以关注下！