RabbitMQ集群架构笔记

RabbitMQ集群架构笔记

RabbitMQ 四种集群架构

主备模式

  • warren(兔子窝),一个主/备方案(主节点如果挂了,从节点提供服务,和ActiveMQ利用Zookeeper做主/备一样)

    在这里插入图片描述

    图中的consumer不仅仅是消费者,可以理解为需求方,通过HaProxy默认路由到主节点,默认也是master提供服务,而当master出现故障之后,下一次路由在HaProxy里配置了一些规则后,它会帮我们路由到备份节点,备份节点就会升级为主节点,而当原主节点修复完成后便会加入该集群,成为新主节点的备份节点

  • HaProxy配置

    listen rabbitma_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 inter 5000 rise 2 fall 2    # 备用节点
    

远程模式

  • 远距离通信和复制,可以实现双活的一种模式,简称Shovel模式,并不常用,因为可靠性还有待提高,并且配置也比较麻烦

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

  • 架构模型

    在这里插入图片描述

  • Shovel集群的拓扑图

    在这里插入图片描述

    这种集群可以帮我们做路由转换,也就是说当第一个集群消费不过来的时候,可以转到第二个,当第一个出现问题的时候也可以转到第二个

  • 配置步骤:

    • 1、启动RabbitMQ插件:

      rabbitmq-plugins enable amqp_client
      rabbitmq-plugins enable rabbitmq_shovel
      
    • 2、创建rabbitmq.config文件

      touch /etc/rabbitmq/rabbitmq.config
      
    • 3、添加配置进rabbitmq.config

      在这里插入图片描述

    • 4、源与目的地服务器使用相同的配置文件(rabbitmq.config)

镜像模式(最主流)

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

    当数据发送过来时,会同步到队中的镜像集群中所有的节点,都会做一个数据备份存储

  • 数据同步

    由于底层是erlang写的,天然就用交换机的方式,与原生socket一样低的延迟,所以在同步的时候性能是非常好的

  • 奇数个节点

    如果发生脑裂,更快的能够在选举的时候将master选举出来

  • 架构图

    在这里插入图片描述

    这种架构的缺陷是不能支持横向的扩展,因为其数据存储是有限的,当在高峰期时,流量非常大,而消费者消费的速度并没有这么快时,消息就会堆积到镜像队列上,而此时横向扩容是无意义的,横向再扩展一份反倒增加了rabbitmq的负担

多活模式

  • 这种模式也是实现异地数据复制的主流模式,因为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只接收具有订阅的消息:

    在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值