RabbitMQ cluster architecture

Reprint:

Author: one line of code a poem
link: https://www.jianshu.com/p/588e1c959f03
Source: Jane books

RabbitMQ cluster architecture

Standby mode

RabbitMQ achieve high availability clusters, usually in the amount of concurrency and data is not high, this model is very good and simple. Standby mode is also referred Warren mode

主备模式: Master node provides read and write, read and write from the node does not provide services, but is responsible for providing backup services, the main function of backup node is the primary node goes down, complete automatic switching from -> Main
主从模式: Provides read and write the master node, from Read-only node

  • Standby mode: Another model is called rabbitmq Warren (rabbit hole), it is a master / slave scheme (if linked to the master node, the node provides service only, and use activemq zookeeper shots / apparatus as)

  • HaProxy configuration:
  listen rabbitmq_cluster
  bind 0.0.0.0:5672 
  mode tcp  #配置TCP模式
  balance roundrobin #简单的轮询
  server bhz76 192.168.11.12:5672 check inter 5000 rise 2 fall 3 #主节点
  server bhz77 192.168.11.13:5672 backup check inter 5000 rise 2 fall 3 #备用节点

备注:rabbitmq #inter cluster nodes arranged every 5 seconds for a checkup mq cluster, secondary server is available to prove correct, it proved 3 failed server is unavailable, and the standby mechanism arranged

Remote mode 不常用( )

Remote mode: long-distance communication and replication, the so-called Shovel message is that we can replicate the work of different data center, we can make two cross-boundary mq cluster interconnect. Here we look at the Shovel architecture model:

 

After using a shovel plug into a model 近端同步确认, 远端异步确认fashion, greatly improving the speed of order confirmation, and also to ensure reliability.

  • Remote mode: Shovel cluster topology map:

     

  • Shovel cluster configuration, first start rabbitmq plug-in, the command is as follows:

rabbitmq-plugins enable amqp_client
rabbitmq-plugins enable rabbitmq_shovel
  • Creating rabbitmq.conf file: touch /etc/rabbitmq/rabbitmq.config

  • Add Configuration see rabbitmq.config

  • Finally, we need resources and destination servers use the same configuration file (rabbitmq.config)

    具体配置 自行百度

Mirror Mode ( 常用)

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

  • Mirror镜像队列,目的是为了保证rabbitmq数据的高可靠性解决方案,主要就是实现数据的同步,一般来讲是2-3个实现数据同步(对于100%数据可靠性解决方案一般是3个节点)集群架构如下:

多活模式

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

  • RabbitMQ部署架构采用双中心模式(多中心),那么在两套(或多套)数据中心中各部署一套RabbitMQ集群,各中心之间还需要实现部分队列消息共享。多活集群架构如下:

  • Federation插件是一个不需要构建Cluster,而在Brokers之间传输消息的高性能插件,Federation插件可以在Brokers或者Cluster之间传输消息,连接双方可以使用不同的users和vistual hosts,双方也可以使用版本不同的RabbitMQ和Erlang。Federation插件使用AMQP协议通信,可以接收不连续的传输。

  • Federation Exchanges,可以看成Downstream从Upstream主动拉取消息,但并不是拉取所有消息,必须是在Downstream上已经明确定义Bindings关系的Exchange,也就是有实际的物理Queue来接收消息,才会从Upstream拉取消息到Downstream。使用AMQP协议实施代理间通信,Downstream会将绑定关系组合在一起,绑定/解绑命令将会发送到Upstream交换机。因此,FederationExchange只接收具有订阅的消息。

RabbitMQ集群镜像模式从0到1

  • RabbitMQ集群环境节点说明(根据自己实际机器ip和histname进行修改)

     

建立集群之后管控台可见: 

详细步骤:
RabbitMQ镜像集群搭建步骤

  • HAProxy是一款提供高可用性、负载均衡以及基于TCP(第四层)和HTTP(第七层)应用的代理软件,支持虚拟主机,他是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点,这些站点通常又需要会话保持或七层处理。HAProxy运行在时下的硬件上,完全可以支撑数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中,同时可以保护你的web服务器不被暴露到网络上。
  • HAProxy借助于OS上几种常见的技术来实现性能的最大化:
  1. 单进程、时间驱动模型显著降低上下文切换的开销及内存占用
  2. 在任何可用的情况下,单缓冲(single buffering)机制能以不复制任何数据的方式完成读写操作,这会节约大量的CPU时钟周期及内存带宽
  3. 借助于Linux2.6上的splice()系统调用,HAProxy可以实现零复制转发(Zero-copy- forwarding),在linux3.5及以上的OS上还可以实现零复制启动(zero-starting)
  • KeepAlived软件主要是通过VRRP协议实现高可用功能的。VRRP是Virtual Router RedundancyProtocol(虚拟路由器冗余协议)的缩写,VRRP出现的目的就是为了解决静态路由单点故障问题的,它能保证党个别节点宕机时,整个网络可以不间断地运行,所以,KeepAlived一方面具有配置管理LVS的功能,同时还具备对LVS下面节点进行健康检查差的功能,另一方面可实现系统网络服务的高可用功能。

  • KeepAlived服务的三个重要功能:

    1. 管理LVS负载均衡软件
    2. 实现LVS集群节点的健康检查
    3. 作为系统网络服务的高可用性(failover)
  • KeepAlived高可用原理
    KeepAlived高可用服务对之间的故障转移,是通过VRRP(Virtual Router Redundancy Protocol,虚拟路由器冗余协议)来实现的。在KeepAlived服务正常工作是,主Master节点会不断地向备节点发送(多播的方式)心跳消息,用以告诉备Backup节点自己还活着,当主master节点发生故障时,就无法发送心跳消息,备节点也就因此无法继续监测到来自主Master节点的心跳了,于是调用自身的接管程序,接管主Master节点 的IP资源及服务。当主Master节点恢复时,备Backup节点又会释放主节点故障时自身接管的IP资源和服务,恢复到原来的备用角色。


 

 

 

Guess you like

Origin blog.csdn.net/LuuvyJune/article/details/93631533