RabbitMQ集群搭建

前言:

首先准备好集群环境:
RabbitMQ集群搭建_第1张图片
下面要演示的是将node02和node03加入node01的rabbitmq集群中

说明一下三台机器分别部署了rabbitmq版本是:
在这里插入图片描述
单机部署就不演示了,想研究的小伙伴可以移步到这里说明的很详细
https://blog.csdn.net/Code__rookie/article/details/122829673?spm=1001.2014.3001.5506

在RabbitMQ中,一个节点的服务其实也是作为一个集群来处理的,在web控制台的admin-> cluster 中可以看到集群的名字,并且可以在页面上修改。而多节点的集群有两种方式

RabbitMQ集群搭建_第2张图片

默认的普通集群模式:

这种模式使用Erlang语言天生具备的集群方式搭建。这种集群模式下,集群的各个节点之间只会有相同的元数据,即队列结构,而消息不会进行冗余,只存在一个节点中。消费时,如果消费的不是存有数据的节点, RabbitMQ会临时在节点之间进行数据传输,将消息从存有数据的节点传输到消费的节点。很显然,这种集群模式的消息可靠性不是很高。因为如果其中有个节点服务宕机了,那这个节点上的数据就无法消费了,需要等到这个节点服务恢复后才能消费,而这时,消费者端已经消费过的消息就有可能给不了服务端正确应答,服务起来后,就会再次消费这些消息,造成这部分消息重复消费。 另外,如果消息没有做持久化,重启就消息就会丢失。并且,这种集群模式也不支持高可用,即当某一个节点服务挂了后,需要手动重启服务,才能保证这一部分消息能正常消费。所以这种集群模式只适合一些对消息安全性不是很高的场景。而在使用这种模式时,消费者应该尽量的连接上每一个节点,减少消息在集群中的传输。

镜像模式:

这种模式是在普通集群模式基础上的一种增强方案,这也就是RabbitMQ的官方HA高可用方案。需要在搭建了普通集群之后再补充搭建。其本质区别在于,这种模式会在镜像节点中间主动进行消息同步,而不是在客户端拉取消息时临时同步。并且在集群内部有一个算法会选举产生master和slave,当一个master挂了后,也会自动选出一个来。从而给整个集群提供高可用能力。
这种模式的消息可靠性更高,因为每个节点上都存着全量的消息。而他的弊端也是明显的,集群内部的网络带宽会被这种同步通讯大量的消耗,进而降低整个集群的性能。这种模式下,队列数量最好不要过多。

搭建普通集群

1.需要同步集群节点中的cookie。

默认会在 /var/lib/rabbitmq/目录下生成一个.erlang.cookie。 里面有一个字符串。我们要做的就是保证集群中三个节点的这个cookie字符串一致。
所以要将node01的.erlang.cookie文件分发到node02和node03。(注意这是个隐藏文件,修改完node02和node03的cookie配置记得使用 命令: systemctl restart rabbitmq-server 重启一下mq服务
在这里插入图片描述
2.将node02的服务加入到node01的集群中。

首先需要保证node02上的rabbitmq服务是正常启动的。 然后在node02执行以下指令:

rabbitmqctl stop_app
rabbitmqctl join_cluster --ram rabbit@node01
rabbitmqctl start_app

RabbitMQ集群搭建_第3张图片

说明:
–ram 表示以Ram节点加入集群。RabbitMQ的集群节点分为disk和ram。disk节点会将元数据保存到硬盘当中,而ram节点只是在内存中保存元数据。

1、由于ram节点减少了很多与硬盘的交互,所以,ram节点的元数据使用性能会比较高。但是,同时,这也意味着元数据的安全性是不如disk节点的。在我们这个集群中,worker1和worker3都以ram节点的身份加入到worker2集群里,因此,是存在单点故障的。如果worker2节点服务崩溃,那么元数据就有可能丢失。在企业进行部署时,性能与安全性需要自己进行平衡。

2、这里说的元数据仅仅只包含交换机、队列等的定义,而不包含具体的消息。因此,ram节点的性能提升,仅仅体现在对元数据进行管理时,比如修改队列queue,交换机exchange,虚拟机vhosts等时,与消息的生产和消费速度无关。

3、如果一个集群中,全部都是ram节点,那么元数据就有可能丢失。这会造成集群停止之后就启动不起来了。RabbitMQ会尽量阻止创建一个全是ram节点的集群,但是并不能彻底阻止。所以,综合考虑,官方其实并不建议使用ram节点,更推荐保证集群中节点的资源投入,使用disk节点。

最后同样的方式把node03上的rabbitmq加入到node01的集群中。

加入完成后,可以在node01的Web管理界面上看到集群的节点情况:

RabbitMQ集群搭建_第4张图片

搭建镜像集群

在普通集群的基础上继续搭建镜像集群
通常在生产环境中,为了减少RabbitMQ集群之间的数据传输,在配置镜像策略时,会针对固定的虚拟主机virtual host来配置。

RabbitMQ中的vritual host可以类比为MySQL中的库,针对每个虚拟主机,可以配置不同的权限、策略等。并且不同虚拟主机之间的数据是相互隔离的。

首先创建一个/mirror的虚拟主机,然后再添加给对应的镜像策略:

rabbitmqctl add_vhost /mirror
 rabbitmqctl set_policy ha-all --vhost "/mirror" "^" '{"ha-mode":"all"}'

在这里插入图片描述

同样,这些配置的策略也可以在Web控制台操作。另外也提供了HTTP API来进行这些操作。
RabbitMQ集群搭建_第5张图片
这些参数需要大致了解下。其中,pattern是队列的匹配规则, ^表示全部匹配。 ^ ha \ 这样的配置表示以ha开头。通常就用虚拟主机来区分就够了,这个队列匹配规则就配置成全匹配。

然后几个关键的参数:

  • HA mode: 可选值 all , exactly, nodes。生产上通常为了保证高可用,就配all

  • all : 队列镜像到集群中的所有节点。当新节点加入集群时,队列也会被镜像到这个节点。

  • exactly : 需要搭配一个数字类型的参数(ha-params)。队列镜像到集群中指定数量的节点。如果集群内节点数少于这个数字,则队列镜像到集群内的所有节点。如果集群内节点少于这个数,当一个包含镜像的节点停止服务后,新的镜像就不会去另外找节点进行镜像备份了。

  • nodes: 需要搭配一个字符串类型的参数。将队列镜像到指定的节点上。如果指定的队列不在集群中,不会报错。当声明队列时,如果指定的所有镜像节点都不在线,那队列会被创建在发起声明的客户端节点上。
    还有其他很多参数,可以后面慢慢再了解。

通常镜像模式的集群已经足够满足大部分的生产场景了。虽然他对系统资源消耗比较高,但是在生产环境中,系统的资源都是会做预留的,所以正常的使用是没有问题的。但是在做业务集成时,还是需要注意队列数量不宜过多,并且尽量不要让RabbitMQ产生大量的消息堆积。

  • 这样搭建起来的RabbitMQ已经具备了集群特性,往任何一个节点上发送消息,消息都会及时同步到各个节点中。而在实际企业部署时,往往会以RabbitMQ的镜像队列作为基础,再增加一些运维手段,进一步提高集群的安全性和实用性。
  • 例如,增加keepalived保证每个RabbitMQ的稳定性,当某一个节点上的RabbitMQ服务崩溃时,可以及时重新启动起来。另外,也可以增加HA-proxy来做前端的负载均衡,通过HA-proxy增加一个前端转发的虚拟节点,应用可以像使用一个单点服务一样使用一个RabbitMQ集群。这些运维方案我们就不做过多介绍了,有兴趣可以自己了解下。

你可能感兴趣的:(rabbitmq,java-rabbitmq,rabbitmq,java,分布式)