rabbitmq服务器搭建-集群

---

前言

目标：搭建一个三节点的rabbitmq集群
准备工作：
1：准备3个单机版的rabbitmq服务器，并修改各个服务器的hostname为：node1、node2、node3（服务器名称的定义最好不要有“-”或者“.”等特殊符号，否则在加入集群时会报错！）。
2：修改3个服务器的ip地址为：192.168.45.201、192.168.45.202、192.168.45.203。

1、修改主机名

# 临时修改主机名
[root@node1 ~]# hostname node1
# 永久修改主机名
[root@node1 ~]# hostnamectl set-hostname node1

2、开启端口25672和4369

不开启这两个端口将会在节点的加入时报错！

firewall-cmd --list-ports
firewall-cmd --zone=public --add-port=25672/tcp --permanent
firewall-cmd --zone=public --add-port=4369/tcp --permanent
systemctl restart firewalld.service
firewall-cmd --reload

3、配置hosts 文件

让各个节点都能互相识别对方，分别在node1、node2、node3中执行下列命令：

vi /etc/hosts
192.168.45.201 node1
192.168.45.202 node2
192.168.45.203 node3

4、 cookie值同步

将某一个节点的 cookie值同步至其他节点，这里将node1的 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

然后再重启node2、node3服务器（reboot），切记！
否则会造成 rabbitmqctl 相关命令全部执行报错的问题(本质原因是用户当前的cookie和rabbitmq的cookie不一致了)！

5、重启服务

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

rabbitmq-server -detached

6、将node2加入至node1

node2中执行

# rabbitmqctl stop 会将Erlang虚拟机关闭，rabbitmqctl stop_app 只关闭RabbitMQ服务
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@node1
# 只启动RabbitMQ服务
rabbitmqctl start_app

然后使用node1节点的地址：登录rabbitmq管理后台，可以看到如下图所示，说明node2节点添加成功！
也可以在node1或node2中使用如下命令查看集群的状态，来确认节点是否添加成功：

rabbitmqctl cluster_status

7、将node3加入至node2

将node3加入至node2之前，需要将node2的服务开启，否则node3加入时会失败，报错！

node3中执行以下命令：

rabbitmqctl stop_app
rabbitmqctl reset
# 这里是将node3加入至node2,当前也可以加入到node1
rabbitmqctl join_cluster rabbit@node2
rabbitmqctl start_app

8、查看集群状态

rabbitmqctl cluster_status

9、登录测试

使用node1中之前添加的用户：admin/123 均可以在以下rabbitmq管理后台地址中进行登录。

http://192.168.45.201:15672/
http://192.168.45.202:15672/
http://192.168.45.203:15672/

10、镜像队列

10.1 使用镜像的原因

	如果 RabbitMQ 集群中只有一个 Broker 节点，那么该节点的失效将导致整体服务的临时性不可用，并

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

10.2 命令配置(选其一)

# 在任意一个rabbitmq服务器节点执行以下命令
rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}'

ha-all：为策略名称。
^ ：为匹配符，只有一个代表匹配所有，^abc为匹配以abc名称开头的exchanges或者queue。
ha-mode：为匹配类型，他分为3种模式：
all：所有（所有的 queue），
exctly：部分（需配置ha-params参数，此参数为int类型, 比如3，众多集群中的随机3台机器），
nodes：指定（需配置ha-params参数，此参数为数组类型比如[“rabbit@F”,“rabbit@G”]这样指定为F与G这2台机器。
ha-params：指定镜像队列总数量；
ha-sync-mode：可以指定：automatic（自动）、manual(手动)

10.3 手动配置(选其一)

（1）保证3节点的rabbitmq服务器均已启动

（2）在任意一个节点中添加 policy

（3）测试验证

在node1中创建一个队列"mirrior.test.queue",并发送一条消息，然后查看控制台，发现该队列在node3上有备份：

此时，我们关闭node1节点服务器，然后登录node3的服务器管理后台，可以看到当前的集群状态如下图所示：

在node3上再次查看该队列的信息，需要刷新了查看，会发现队列在node2上存在一个备份。