RabbitMQ特性原理与集群架构解析
RabbitMQ四种集群架构
- 主备模式 M-S
- 远程模式 异地多活[了解]
- 镜像模式
- 多活模式 异地多活
主备模式
warren(兔子窝)，一个主、备方案（主节点如果挂掉，从节点提供服务）
主备模式-HaProxy配置
listen rabbitmq_cluster
bind 0.0.0.0:5672 #配置TCP模式
mode tcp #简单的轮询
balance roundrobin #主节点
server bhz76 192.168.11.76:5672 check inter 5000 rise 2 fall 2
server bhz77 192.168.11.77:5672 backup check 5000 rise 2 fall 2 #备用节点远程模式
远程通信和复制，可以实现双活的一种模式，简称Shovel模式
所谓Shovel就是我们可以把消息进行不同数据中心的复制工作，可以跨地域的让两个mq集群互联。
这种架构的配置就不写了, 因为用的少, 如果有用的话, 百度一下, 或者找一下官方
镜像模式
- 集群模式非常经典的就是镜像模式, 保证100%数据不丢失
- 在实际的工作中用的最多, 并且实现集群非常的简单, 一般互联网大厂都会构建这种镜像集群模式
Mirror镜像队列
缺点: 不能支持横向扩展
多活模式
- 这种模式也是实现异地数据赋值的主流模式, 应为Shovel模式配置比较复杂, 所以一般来说实现异地集群都是使用这种双活或者多活模型来实现的
- 这种模型需要依赖
RabbitMQ的federation插件, 可以实现持续的可靠的AMQP数据通信, 多活模式实际配置与应用非常简单 - RabbitMQ部署架构采用双中心模式(多中心), 那么在两套(或多套)数据中心中各部署一套RabbitMQ集群, 各中心的RabbitMQ服务除了需要为业务提供正常的消息服务外, 中心之间还需要实现部分队列消息共享
多活集群架构图
Federation插件
- Federation 插件是一个不需要构建Cluster, 而在Brokers之间传输消息的高性能插件
- Federation插件可以在Brokers或Cluster之间传输消息, 连接的双方可以使用不同的users和virtual hosts, 双方也可以使用版本不同的RabbitMQ和Erlang
- Federation插件使用AMQP协议通讯, 可以接受不连续的传输
- Federation Exchanges, 可以看成Downstream从 Upstream主动拉取消息, 但并不是拉取所有消息, 必须是在Downstream上已经明确定义Bindings关系的Exchange, 也就是有实际的物理Queue来接收消息, 才会从Upstream拉取消息到Downstream, 使用AMQP协议实施代理间通信, Downstream会将绑定关系组合在一起, 绑定/ 接触绑定命令 将发送到Upstream交换机, 因此, Federation Exchange只接收具有订阅的消息
