RabbitMQ之集群搭建

举报
别团等shy哥发育 发表于 2023/01/10 21:53:37 2023/01/10
【摘要】 @toc RabbitMQ集群 1、Clustering 1.1 使用集群的原因  最开始我们介绍了如何安装及运行 RabbitMQ 服务,不过这些是单机版的,无法满足目前真实应用的 要求。如果 RabbitMQ 服务器遇到内存崩溃、机器掉电或者主板故障等情况,该怎么办?单台 RabbitMQ 服务器可以满足每秒 1000 条消息的吞吐量,那么如果应用需要 RabbitMQ 服务满足每秒 ...

@toc

RabbitMQ集群

1、Clustering

1.1 使用集群的原因

  最开始我们介绍了如何安装及运行 RabbitMQ 服务,不过这些是单机版的,无法满足目前真实应用的 要求。如果 RabbitMQ 服务器遇到内存崩溃、机器掉电或者主板故障等情况,该怎么办?单台 RabbitMQ 服务器可以满足每秒 1000 条消息的吞吐量,那么如果应用需要 RabbitMQ 服务满足每秒 10 万条消息的吞 吐量呢?购买昂贵的服务器来增强单机 RabbitMQ 务的性能显得捉襟见肘,搭建一个 RabbitMQ 集群才是 解决实际问题的关键.

1.2 集群搭建步骤

架构图如下:

1.2.1 准备三台虚拟机

image-20211227152551161

可以给其中一台机器配置好环境,然后直接克隆两台就行。

1.2.2 修改三台机器的主机名称

vim /etc/hostname

image-20211227152528250

node1     192.168.159.33 
node2     192.168.159.34 
node3     192.168.159.35 

1.2.3 配置各个节点的hosts文件,让各个节点都能户向识别对方

image-20211227152737554

1.2.4 确保各个节点的cookie文件使用的是同一个值

在node1节点的机器上执行远程操作命令

scp /var/lib/rabbitmq/.erlang.cookie root@node2:/var/lib/rabbitmq/.erlang.cookie
scp /var/lib/rabbitmq/.erlang.cookie root@node3:/var/lib/rabbitmq/.erlang.cookie

1.2.5 启动RabbitMQ服务

顺带启动Erlang虚拟机和RabbitMQ应用服务(在三台节点上分别执行以下命令)

rabbitmq-server -detached

1.2.6 在节点2执行如下命令

(rabbitmqctl stop 会将 Erlang 虚拟机关闭,rabbitmqctl stop_app 只关闭 RabbitMQ 服务)

abbitmqctl stop_app
rabbitmqctl reset

将节点2加入到节点1所在的集群中

rabbitmqctl join_cluster rabbit@node1

只启动应用服务

rabbitmqctl start_app

1.2.7 在节点3执行如下命令

rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@node2
rabbitmqctl start_app

1.2.8 查看集群状态

随便在一台机器上面执行如下命令:

rabbitmqctl cluster_status

image-20211227172136495

1.2.9 需要重新设置设置用户

下面这些命令在三台节点都要执行

创建账号:

rabbitmqctl add_user admin 123

设置用户角色

rabbitmqctl set_user_tags admin administrator

设置用户权限

rabbitmqctl set_permissions -p "/" admin ".*" ".*" ".*"

1.2.10 查看管理界面

随便进入某一台节点的管理界面

image-20211227172351119

没有任何问题,集群搭建成功

2、镜像队列

2.1 使用镜像队列的原因

  如果 RabbitMQ 集群中只有一个 Broker 节点,那么该节点的失效将导致整体服务的临时性不可用,并 且也可能会导致消息的丢失。可以将所有消息都设置为持久化,并且对应队列的durable属性也设置为true, 但是这样仍然无法避免由于缓存导致的问题:因为消息在发送之后和被写入磁盘井执行刷盘动作之间存在 一个短暂却会产生问题的时间窗。通过 publisherconfirm 机制能够确保客户端知道哪些消息己经存入磁盘, 尽管如此,一般不希望遇到因单点故障导致的服务不可用。

  引入镜像队列(Mirror Queue)的机制,可以将队列镜像到集群中的其他 Broker 节点之上,如果集群中 的一个节点失效了,队列能自动地切换到镜像中的另一个节点上以保证服务的可用性。

2.2 镜像队列搭建步骤

2.2.1 随便找一个节点添加policy

这里我在节点2(192.168.159.34)这台机器上添加

image-20211227172934368

这里pattern那一栏其实就相当于是一个正则表达式,

image-20211227172949231

2.2.2 在node1上创建一个队列发送消息,队列存在镜像队列

image-20211227173822710

2.2.2 停掉node1节点的机器,node2成为镜像队列

停掉node1

rabbitmqctl stop_app

image-20211227174045768

image-20211227173952594

可以看到,node1节点宕机之后,node2成为镜像队列

2.2.3 测试一台机器宕机之后,消息是否还能被消费。

开始消费node2节点中队列的消息,发现依然可以被消费。

image-20211227174216010

  就算整个集群只剩下一台机器了,依然能够消费队列里面的消息,说明队列里面的消息被镜像队列传递到响应的机器里面了。

3、解除集群节点的命令

根据上面搭建的集群,在node2和node3节点上执行如下命令

rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl start_app
rabbitmqctl cluster_status

(node1 机器上执行下列命令)

rabbitmqctl forget_cluster_node rabbit@node2
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。