本文详细介绍了如何在CentOS上搭建RabbitMQ集群，包括节点配置、集群状态检查以及用户管理。接着，探讨了使用Docker构建RabbitMQ集群的方案。此外，通过HAProxy和Keepalived实现高可用负载均衡和故障切换。同时，讨论了镜像队列和联邦交换机在确保数据一致性和服务可用性方面的作用，并提供了具体的配置步骤。最后，提到了Shovel插件用于数据迁移和复制。
一、CentOS 集群
1. 修改三台服务器的主机名称
vim /etc/hostname
2. 配置各个节点的 hosts 文件，让各个节点都能互相识别对方
vim /etc/hosts
10.211.55.74 node1
10.211.55.75 node2
10.211.55.76 node3
3. 确保各个节点的 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
4. 启动 RabbitMQ 服务，顺带启动 Erlang 虚拟机
rabbitmq-server -detached
5. 节点二
# rabbitmqctl stop 会将 Erlang 虚拟机关闭
# rabbitmqctl stop_app 只关闭 RabbitMQ 服务
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@node1
# 只启动 RabbitMQ 服务
rabbitmqctl start_app
6. 节点三
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@node2
rabbitmqctl start_app
7. 集群状态
rabbitmqctl cluster_status
8. 需要重新设置用户
# 创建账号
rabbitmqctl add_user admin 123456
# 设置用户角色
rabbitmqctl set_user_tags admin administrator
# 设置用户权限
rabbitmqctl set_permissions -p "/" admin ".*" ".*" ".*"
9. 解除集群节点
- 在
node2和node3服务器上分别执行。
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl start_app
rabbitmqctl cluster_status
# node1 机器上执行
rabbitmqctl forget_cluster_node rabbit@node2
二、Docker 集群
三、HAProxy + Keepalived 实现高可用负载均衡
1. 整体架构图
2. HAProxy 实现负载均衡
- HAProxy 提供高可用性、负载均衡及基于 TCP/HTTP 应用的代理，支持虚拟主机。
- 它是免费、快速并且可靠的一种解决方案，包括 Twitter、Reddit、StackOverflow、GitHub 在内的多家知名互联网公司在使用。
HAProxy实现了一种事件驱动、单一进程模型，此模型支持非常大的井发连接数。- Nginx、LVS、HAProxy 三者区别
3. HAProxy 搭建步骤
3.1 在 node1 和 node2 下载 HAProxy
yum -y install haproxy
3.2 .修改 node1 和 node2 的 haproxy.cfg
vim /etc/haproxy/haproxy.cfg
- 需要修改 IP 为当前机器 IP：
3.3 在两台节点启动 HAProxy
haproxy -f /etc/haproxy/haproxy.cfg
ps -ef | grep haproxy
3.4 访问地址
4. Keepalived 实现双机（主备）热备
- 试想如果前面配置的 HAProxy 主机突然宕机或者网卡失效，那么虽然 RbbitMQ 集群没有任何故障，但是对于外界的客户端来说所有的连接都会被断开，结果将是灾难性的，为了确保负载均衡服务的可靠性，同样显得十分重要。
- 这里就要引入 KeepAlived 它能够通过自身健康检查、资源接管功能做高可用（双机热备），实现故障转移。
5. Keepalived 搭建步骤
5.1 下载 Keepalived
yum -y install keepalived
5.2 节点 node1 配置文件
vim /etc/keepalived/keepalived.conf
# keepalived.conf 修改之后替换
5.3 节点 node2 配置文件
# 需要修改 global_defs 的 router_id，如: nodeB
# 其次要修改 vrrp_instance_VI 中 state 为 "BACKUP"
# 最后要将 priority 设置为小于 100 的值
5.4 添加 haproxy_chk.sh
- 为了防止 HAProxy 服务挂掉之后，Keepalived 还在正常工作，而没有切换到 Backup 上。
- 所以这里需要编写一个脚本来检测 HAProxy 务的状态，当 HAProxy 服务挂掉之后该脚本会自动重启 HAProxy 的服务，如果不成功则关闭 Keepalived 服务，这样便可以切换到 Backup 继续工作。
# 可以直接上传文件
vim /etc/keepalived/haproxy_chk.sh
# 修改权限
chmod 777 /etc/keepalived/haproxy_chk.sh
5.5 在 node1 和 node2 启动 Keepalived 命令
systemctl start keepalived
5.6 观察 Keepalived 的日志
tail -f /var/log/messages -n 200
5.7 观察最新添加的 vip
ip add show
5.8 node1 模拟 Keepalived 关闭状态
systemctl stop keepalived
5.9 使用 vip 地址来访问 RabbitMQ 集群
四、镜像队列
1. 使用镜像的原因
- 如果 RabbitMQ 集群中只有一个 Broker 节点，那么该节点的失效将导致整体服务的临时性不可用，并且也可能会导致消息的丢失。
- 可以将所有消息都设置为持久化，并且对应队列的
durable属性也设置为 true，但是这样仍然无法避免由于缓存导致的问题。- 因为消息在发送之后 和 被写入磁盘井执行刷盘动作之间存在一个短暂却会产生问题的时间窗。
- 通过
Publisher Confirms机制能够确保客户端知道哪些消息己经存入磁盘，尽管如此，一般不希望遇到因单点故障导致的服务不可用。
- 引入镜像队列（Mirror Queue）的机制，可以将队列镜像到集群中的其他 Broker 节点之上。
- 如果集群中的一个节点失效了，队列能自动地切换到集群中的另一个节点上以保证服务的可用性。
2. 搭建步骤
2.1 启动三台集群节点
2.2 在其中一个节点添加Policy
添加备份指定规则的交换机 或 队列：
2.3 在 node1 上创建一个队列，node2 节点也存在镜像队列
2.4 .停掉 node1 之后，发现 node2 成为镜像队列
2.5 就算整个集群只剩下一台机器了，依然能消费队列里面的消息
说明队列里面的消息被镜像队列传递到相应机器里面了
五、联邦交换机（Federation Exchange）
1. 使用原因
- Broker（北京)，Broker（深圳) 彼此之间相距甚远，网络延迟是一个不得不面对的问题。
- 有一个在北京的业务 (Client 北京) 需要连接 Broker（北京)，向其中的交换机 ExchangeA 发送消息，此时的网络延迟很小，(Client 北京) 可以迅速将消息发送至 ExchangeA 中，就算在开启了 Publisher/Confirm 机制或者事务机制的情况下，也可以迅速收到确认信息。
- 此时又有个在深圳的业务 (Client 深圳) 需要向 ExchangeA 发送消息，那么 (Client 深圳) Broker（北京) 之间有很大的网络延迟，(Client 深圳) 将发送消息至 ExchangeA 会经历一定的延迟，尤其是在开启了 Publisher/Confirm 机制或者事务机制的情况下，(Client 深圳) 会等待很长的延迟时间来接收 Broker（北京) 的确认信息，进而必然造成这条发送线程的性能降低，甚至造成一定程度上的阻塞。
- 将业务 (Client 深圳) 部署到北京的机房可以解决这个问题，但是如果 (Client 深圳) 调用的另些服务都部署在深圳，那么又会引发新的时延问题，总不见得将所有业务全部部署在一个机房，那么容灾又何以实现？
- 这里使用 Federation 插件就可以很好地解决这个问题.。
2. 搭建步骤
2.1 需要保证每台节点单独运行
2.2 在每台机器上开启 federation 相关插件
rabbitmq-plugins enable rabbitmq_federation
rabbitmq-plugins enable rabbitmq_federation_management
2.3 原理图(先运行 consumer 在 node2 创建 fed_exchange)
2.4 在 downstream(node2) 配置 upstream(node1)
2.5 添加 policy
2.6 成功的提示
六、联邦队列（Federation Queue）
1. 使用原因
- 联邦队列可以在多个 Broker 节点（或者集群）之间为单个队列提供均衡负载的功能。
- 一个联邦队列可以连接一个或者多个上游队列（upstream queue），并从这些上游队列中获取消息以满足本地消费者消费消息的需求。
2. 搭建步骤
2.1 原理图
2.2 添加 upstream（同上）
2.3 添加 policy
七、Shovel
1. 使用原因
- Federation 具备的数据转发功能类似，Shovel 够可靠、持续地从一个 Broker 中的队列（作为源端，即Source）拉取数据并转发至另一个 Broker 中的交换器（作为目的端，即 Destination）。
- 作为源端的队列 和 作为目的端的交换器 可以同时位于同一个 Broker，也可以位于不同的 Broker 上。
- Shovel 可以翻译为 铲子，是一种比较形象的比喻，这个 铲子 可以将消息从一方 铲子 另一方。
- Shovel 行为就像优秀的客户端应用程序能够负责连接源和目的地、负责消息的读写及负责连接失败问题的处理。
2. 搭建步骤
2.1 开启插件（需要的机器都开启）
rabbitmq-plugins enable rabbitmq_shovel
rabbitmq-plugins enable rabbitmq_shovel_management
2.2 原理图（在源头发送的消息直接会进入到目的地队列）
2.3 添加 Shovel 源和目的地
扫一扫
806
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
