联系我们联系我们
电子邮箱电子邮箱

MQ RabbitMQ 高可用集群(二):集群搭建

[复制链接]

该用户从未签到

小苏 发表于 2021-4-22 16:47:57
150 0
1 集群节点安装
单节点安装RabbitMQ,可参考博文:

MQ RocketMQ安装部署和配置: https://blog.csdn.net/qq_15769939/article/details/115800384

以上操作三个节点(71、72、73)同时进行操作

2 文件同步配置
选择71、72、73任意一个节点为Master(这里选择71为Master),也就是说我们需要把71的Cookie文件同步到72、73节点上去,进入/var/lib/rabbitmq目录下,把/var/lib/rabbitmq/.erlang.cookie文件的权限修改为777,原来是400;然后把.erlang.cookie文件copy到各个节点下;最后把所有cookie文件权限还原为400即可。

//进入目录修改权限;远程copy72、73节点
scp /var/lib/rabbitmq/.erlang.cookie 192.168.11.72:/var/lib/rabbitmq/
scp /var/lib/rabbitmq/.erlang.cookie 192.168.11.73:/var/lib/rabbitmq/

3 集群配置
3.1 停止服务
首先停止3个节点的服务:(这里不能使用原来的命令:/etc/init.d/rabbitmq-server stop)

rabbitmqctl stop
1
3.2 配置集群
3.2.1 组成集群
接下来我们就可以使用集群命令,配置71、72、73为集群模式,3个节点(71、72、73)执行启动命令,后续启动集群使用此命令即可。

rabbitmq-server -detached
1
3.2.2 slave加入集群
加入集群操作(重新加入集群也是如此,以最开始的主节点为加入节点)

//注意做这个步骤的时候:需要配置/etc/hosts 必须相互能够寻址到
bhz72:rabbitmqctl stop_app
bhz72:rabbitmqctl join_cluster --ram rabbit@bhz71
bhz72:rabbitmqctl start_app
bhz73:rabbitmqctl stop_app
bhz73:rabbitmqctl join_cluster rabbit@bhz71
bhz73:rabbitmqctl start_app
//在另外其他节点上操作要移除的集群节点
rabbitmqctl forget_cluster_node rabbit@bhz71

3.2.3 修改集群名称
修改集群名称(默认为第一个node名称)

rabbitmqctl set_cluster_name rabbitmq_cluster1
1
3.3 查看集群状态
3.3.1 命令查看
在集群的任意一个节点执行命令:查看集群状态

rabbitmqctl cluster_status
1


3.3.2 管理界面查看
访问任意一个管控台节点:http://192.168.11.71:15672 如图所示



4 配置镜像队列
设置镜像队列策略(在任意一个节点上执行)

rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}'
1
将所有队列设置为镜像队列,即队列会被复制到各个节点,各个节点状态一致,RabbitMQ高可用集群就已经搭建好了,我们可以重启服务,查看其队列是否在从节点同步。

5 消息一致性问题
5.1 介绍
在使用rabbitmq中,消息的一致性是非常重要的一个话题。下面我们来研究一下,在数据一致性方面,有哪些需要关注的。发送者发送消息出来,在数据一致性的要求下,我们通常认为必须达到以下条件:

broker持久化消息
publisher知道消息已经成功持久化
首先,我们可以采用事务来解决此问题。每个消息都必须经历以上两个步骤,就算一次事务成功。

事务是同步的。因此,如果采用事务,发送性能必然很差。官方给出来的性能是:

It takes a bit more than 4 minutes to publish 10000 messages.
1
异步的方法的效率是事务方法效率的100倍。

5.2 解决方案
我们可以采用异步的方式来解决此问题。publisher发送消息后,不进行等待,而是异步监听是否成功。这种方式又分为两种模式,一种是return,另一种是confirm. 前一种是publisher发送到exchange后,异步收到消息。第二种是publisher发送消息到exchange,queue,consumer收到消息后才会收到异步收到消息。可见,第二种方式更加安全可靠。如下所示:



但是,异步也存在些局限性。如果一旦出现broker挂机或者网络不稳定,broker已经成功接收消息,但是publisher并没有收到confirm或return.这时,对于publisher来说,只能重发消息解决问题。而在这里面,我们会发生重复消息的问题。当然,如果业务类型要求数据一致性非常高,可以采用低效率的事务型解决方案:引用:http://www.rabbitmq.com/blog/2011/02/10/introducing-publisher-confirms/
————————————————
版权声明:本文为CSDN博主「AusKa_T」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/qq_15769939/article/details/115890494
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

发表新帖