docker搭建rabbitmq镜像集群
目录
一、搭建RabbitMq的运行环境
1.通过search查询rabbitmq镜像
2.通过pull拉取rabbitmq的官方最新镜像
3.创建容器
4.启动管理页面
5.设置erlang cookie
二、普通模式
三、镜像模式
四、新增节点
普通集群：
此时我们创建的队列 Queue，它的元数据（主要就是 Queue 的一些配置信息）会在所有的 RabbitMQ 实例中进行同步，但是队列中的消息只会存在于一个 RabbitMQ 实例上，而不会同步到其他队列。
当我们消费消息的时候，如果连接到了另外一个实例，那么那个实例会通过元数据定位到 Queue 所在的位置，然后访问 Queue 所在的实例，拉取数据过来发送给消费者。
这种集群可以提高 RabbitMQ 的消息吞吐能力，但是无法保证高可用，因为一旦一个 RabbitMQ 实例挂了，消息就没法访问了，如果消息队列做了持久化，那么等 RabbitMQ 实例恢复后，就可以继续访问了；如果消息队列没做持久化，那么消息就丢了。
镜像集群：它是在普通模式的基础上，把需要的队列做成镜像队列，存在于多个节点来实现高可用(HA)。该模式解决了上述问题，Broker会主动地将消息实体在各镜像节点间同步，在consumer取数据时无需临时拉取。该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被大量消耗。通常地，对可靠性要求较高的场景建议采用镜像模式。
镜像集群有以下三种模式：
节点类型：
- RAM node：内存节点将所有的队列、交换机、绑定、用户、权限和 vhost 的元数据定义存储在内存中，好处是可以使得交换机和队列声明等操作速度更快。
- Disk node：将元数据存储在磁盘中，单节点系统只允许磁盘类型的节点，防止重启 RabbitMQ 的时候，丢失系统的配置信息
RabbitMQ 要求在集群中至少有一个磁盘节点，所有其他节点可以是内存节点，当节点加入或者离开集群时，必须要将该变更通知到至少一个磁盘节点。如果集群中唯一的一个磁盘节点崩溃的话，集群仍然可以保持运行，但是无法进行其他操作（增删改查），直到节点恢复。为了确保集群信息的可靠性，或者在不确定使用磁盘节点还是内存节点的时候，建议直接用磁盘节点。
一、搭建RabbitMq的运行环境
操作环境：centos7，通过docker搭建两个rabbitmq节点。
1.通过search查询rabbitmq镜像
docker search rabbitmq
2.通过pull拉取rabbitmq的官方最新镜像
这里最好带上tag为management的版本，否则拉最新的latest，web管理页无法显示全，会提示overview:management only mode
docker pull rabbitmq:3.8.25-management
3.创建容器
docker run -d --name rabbitmq1 -p 5672:5672 -p 15672:15672 --hostname myRabbit1
-e RABBITMQ_DEFAULT_VHOST=my_vhost1 -e RABBITMQ_DEFAULT_USER=admin
-e RABBITMQ_DEFAULT_PASS=admin a4eb038c2ecb
--name：容器名称
-p:端点映射
--hostname：rabbitmq的节点名称
-e RABBITMQ_DEFAULT_VHOST：虚拟主机名称
-e RABBITMQ_DEFAULT_USER：登录账号
-e RABBITMQ_DEFAULT_PASS：登录密码
a4eb038c2ecb是镜像id，根据自己情况替换。
4.启动管理页面
我们的镜像默认没有开启web管理页面，所以我们通过exec命令进入容器启动，这个镜像的环境是centos的
[root@moyu ~]# docker exec -it 639a151c5440 /bin/bash
root@myRabbit:/# rabbitmq-plugins enable rabbitmq_management
浏览器中访问http://localhost:15672/即可打开，另一个rabbitmq如法炮制，区别之处在于更换端口为5673和15673等，并且创建容器时使用--link连接第一个rabbitmq节点（也可创建桥接网络network连接），如下
docker run -d --name rabbitmq2 -p 5673:5672 -p 15673:15672 --hostname myRabbit2
-e RABBITMQ_DEFAULT_VHOST=my_vhost2 -e RABBITMQ_DEFAULT_USER=admin
-e RABBITMQ_DEFAULT_PASS=admin --link rabbitmq1:myRabbit1 a4eb038c2ecb
5.设置erlang cookie
erlang cookie原本可以通过run容器时设置参数-e RABBITMQ_ERLANG_COOKIE，但是现在过期弃用了。
我们先通过docker logs命令查看容器的运行日志，寻找home dir参数如下
[root@moyu ~]# docker logs rabbitmq1
//.....这里省略
Starting broker...2021-11-17 02:19:55.859245+00:00 [info] <0.222.0>
2021-11-17 02:19:55.859245+00:00 [info] <0.222.0> node : rabbit@myRabbit1
2021-11-17 02:19:55.859245+00:00 [info] <0.222.0> home dir : /var/lib/rabbitmq
2021-11-17 02:19:55.859245+00:00 [info] <0.222.0> config file(s) : /etc/rabbitmq/conf.d/10-default-guest-user.conf
2021-11-17 02:19:55.859245+00:00 [info] <0.222.0> : /etc/rabbitmq/conf.d/management_agent.disable_metrics_collector.conf
2021-11-17 02:19:55.859245+00:00 [info] <0.222.0> cookie hash : Aed9pjd9vYWw3hng7Gjmkg==
2021-11-17 02:19:55.859245+00:00 [info] <0.222.0> log(s) : /var/log/rabbitmq/rabbit@myRabbit1_upgrade.log
2021-11-17 02:19:55.859245+00:00 [info] <0.222.0> : <stdout>
2021-11-17 02:19:55.859245+00:00 [info] <0.222.0> database dir : /var/lib/rabbitmq/mnesia/rabbit@myRabbit1
所以.erlang.cookie文件在此路径下，我们进入容器可以看到此文件
root@myRabbit1:~# ls -a /var/lib/rabbitmq
. .. .bash_history .erlang.cookie mnesia
我们再设置erlang cookie的权限，在容器内运行如下代码，如果权限不够后续操作会报错
chmod 600 /var/lib/rabbitmq/.erlang.cookie
之后我们通过docker cp命令将rabbitmq1中的.erlang.cookie文件拷到物理机上再拷贝到rabbitmq2的容器中，物理机和容器之间复制命令如下：
容器复制文件到物理机：docker cp 容器名称:容器目录
物理机目录物理机复制文件到容器：docker cp 物理机目录 容器名称:容器目录
具体代码如下：
docker cp rabbitmq1:/var/lib/rabbitmq/ d:\workspace\
docker cp d:\workspace\rabbitmq\.erlang.cookie rabbitmq2:/var/lib/rabbitmq/
复制之后需要重启rabbitmq2容器，否则执行rabbitmqctl命令报如下错误：
[error] Cookie file /var/lib/rabbitmq/.erlang.cookie must be accessible by owner only
普通集群模式
重启后进入容器将rabbitmq2的节点加入rabbitmq1中创建普通集群，分别执行如下代码即可：
rabbitmqctl stop_app
rabbitmqctl reset // 重置集群
rabbitmqctl join_cluster --ram rabbit@myRabbit1 //myRabbit1为rabbitmq1容器中rabbitmq的hostname，并且把当前节点加入到myRabbit1这个节点中去
rabbitmqctl start_app
rabbitmqctl cluster_status // 查看集群状态
之后我们再web管理页可以看到两个节点了。
在任意一个节点创建一个队列，另一个节点也会生成相同的队列。而且可以发现rabbitmq2的vhost从my_vhost2变为了my_vhost1与rabbitmq相同了。
三、镜像模式
镜像模式就是在普通模式的基础上进入rabbitmq1容器输入如下命令即可：
rabbitmqctl set_policy -p my_vhost1 ha-all "^" '{"ha-mode":"all"}' --apply-to all
具体的格式为
rabbitmqctl set_policy [-p Vhost] Name Pattern Definition [Priority]
-p Vhost： 可选参数，针对指定vhost下的queue进行设置
Name: policy的名称
Pattern: queue的匹配模式(正则表达式)
Definition：镜像定义，包括三个部分ha-mode, ha-params, ha-sync-mode
ha-mode:指明镜像队列的模式，有效值为 all/exactly/nodes
all：表示在集群中所有的节点上进行镜像
exactly：表示在指定个数的节点上进行镜像，节点的个数由ha-params指定
nodes：表示在指定的节点上进行镜像，节点名称通过ha-params指定
ha-params：作为参数，为ha-mode的补充
ha-sync-mode：进行队列中消息的同步方式，有效值为automatic和manual
priority：可选参数，policy的优先级
rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}' --apply-to all
或者登录rabbitmq管理页面 ——> Admin ——> Policies ——> Add / update a policy
name：策略名称
Pattern：^ 匹配符，只有一个代表匹配所有。message指同步“message”开头的队列名称
Definition：ha-mode=all 为匹配类型，分为3种模式：all（表示所有的queue）
Priority:优先级，首先根据priority排序，值越大的优先级越高；相同priority则根据创建时间排序，越晚创建的优先级越高。
简单说明一下 Operator Policy 和 User Policy 的区别：
- Operator Policy 是给服务提供商或公司基础设施部门用来设置某些需要强制执行的通用规则
- User Policy 是给业务应用用来设置的规则
Operator Policy 和 User Policy 会合并后作用于队列，并且为防止 Operator Policy 对队列某些关键属性例如死信队列交换器Dead Letter Exchange的覆盖导致业务应用产生非预期的结果，Operator Policy 只支持expire、message-ttl、max-length、max-length-bytes4个参数。
四、新增节点
1.创建新的mq容器,需要分别link前面的容器。
docker run -d --name rabbitmq3 -p 5675:5672 -p 15675:15672 --hostname myRabbit3 -e RABBITMQ_DEFAULT_VHOST=my_vhost3
-e RABBITMQ_DEFAULT_USER=admin
-e RABBITMQ_DEFAULT_PASS=admin
--link rabbitmq1:myRabbit1 --link rabbitmq2:rabbitmq2 8d91aa7f6d1d
2.复制.erlang.cookie
将前面复制的.erlang.cookie文件同样复制给新增容器
3. 进入到新增容器节点内，将该节点加入集群
[root@moyu ~]# docker exec -it rabbitmq3 /bin/bash
rabbitmqctl stop_app
rabbitmqctl join_cluster --ram rabbit@myRabbit1 //把当前节点加入到myRabbit1这个节点中去
rabbitmqctl start_app
rabbitmqctl cluster_status // 查看集群状态
新增节点也会同步集群中的队列数据
