四、RabbitMQ 集群

一、RabbitMQ 介绍
二、RabbitMQ 核心
三、RabbitMQ 扩展
四、RabbitMQ 集群

一、`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 访问地址

http://192.168.137.2:8888/stats

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 源和目的地

四、RabbitMQ 集群相关推荐

RabbitMq（十七）rabbitmq的四种集群监控
rabbitmq的四种集群监控方式: rabbitmq控制台页面监控 tracing日志监控使用api接口自定义实现监控使用Zabbix监控rabbitmq 第一种.使用控制台页面监控rabbit ...
Docker：搭建RabbitMQ集群
RabbitMQ原理介绍(一) RabbitMQ安装使用(二) RabbitMQ添加新用户并支持远程访问(三) RabbitMQ管理命令rabbitmqctl详解(四) RabbitMQ两种集群模式配 ...
搭建高可用的rabbitmq集群 + Mirror Queue + 使用C#驱动连接
我们知道rabbitmq是一个专业的MQ产品,而且它也是一个严格遵守AMQP协议的玩意,但是要想骚,一定需要拿出高可用的东西出来,这不本篇就跟大家说一下cluster的概念,rabbitmq是erl ...
RabbitMQ集群原理介绍
文章目录一.RabbitMQ默认集群原理 1. RabbitMQ集群元数据的同步 2. 为何RabbitMQ集群仅采用元数据同步的方式 3. RabbitMQ集群发送/订阅消息的基本原理 4. 客户 ...
你不知道的RabbitMQ集群架构全解
你不知道的RabbitMQ集群架构全解前言本文将系统的介绍一下RabbitMQ集群架构的特点.异常处理.搭建和使用中要注意的一些细节. 知识点一.为什么使用集群? 二.集群的特点三.集群异常处 ...
RabbitMQ集群和失败处理
RabbitMQ内建集群的设计用于完成两个目标:允许消费者和生产者在RabbitMQ节点在奔溃的情况下继续运行,以及通过添加更多的节点来线性扩展消息通信的吞吐量.当失去一个RabbitMQ节点时客户端 ...
RabbitMQ集群的学习
搭建RabbitMQ集群节点规划: 可以参照下图来规划自己的节点一.修改主机名,添加映射,关闭防火墙每一个节点根据自己的主机名规划配置我的节点与主机名 10.30.59.188 rabbitm ...
RabbitMQ集群搭建（七）
先来介绍一下RabbitMQ集群 RabbitMQ集群有两种模式,一种是普通模式,即默认的集群模式,另外一种为镜像模式,可以把队列做成镜像队列我们在学习两种模式之前,先来了解下一些关于RabbitM ...
Rabbitmq集群高可用测试
Rabbitmq集群高可用 RabbitMQ是用erlang开发的,集群非常方便,因为erlang天生就是一门分布式语言,但其本身并不支持负载均衡. Rabbit模式大概分为以下三种:单一模式.普通模 ...

四、RabbitMQ 集群

一、CentOS 集群

1. 修改三台服务器的主机名称

2. 配置各个节点的 hosts 文件，让各个节点都能互相识别对方

3. 确保各个节点的 cookie 文件相同

4. 启动 RabbitMQ 服务，顺带启动 Erlang 虚拟机

5. 节点二

6. 节点三

7. 集群状态

8. 需要重新设置用户

9. 解除集群节点

二、Docker 集群

三、HAProxy + Keepalived 实现高可用负载均衡

1. 整体架构图

2. HAProxy 实现负载均衡

3. HAProxy 搭建步骤

3.1 在 node1 和 node2 下载 HAProxy

3.2 .修改 node1 和 node2 的 haproxy.cfg

3.3 在两台节点启动 HAProxy

3.4 访问地址

4. Keepalived 实现双机（主备）热备

5. Keepalived 搭建步骤

5.1 下载 Keepalived

5.2 节点 node1 配置文件

5.3 节点 node2 配置文件

5.4 添加 haproxy_chk.sh

5.5 在 node1 和 node2 启动 Keepalived 命令

5.6 观察 Keepalived 的日志

5.7 观察最新添加的 vip

5.8 node1 模拟 Keepalived 关闭状态

5.9 使用 vip 地址来访问 RabbitMQ 集群

四、镜像队列

1. 使用镜像的原因

2. 搭建步骤

2.1 启动三台集群节点

2.2 在其中一个节点添加Policy

2.3 在 node1 上创建一个队列，node2 节点也存在镜像队列

2.4 .停掉 node1 之后，发现 node2 成为镜像队列

2.5 就算整个集群只剩下一台机器了，依然能消费队列里面的消息

五、联邦交换机（Federation Exchange）

1. 使用原因

2. 搭建步骤

2.1 需要保证每台节点单独运行

2.2 在每台机器上开启 federation 相关插件

2.3 原理图(先运行 consumer 在 node2 创建 fed_exchange)

2.4 在 downstream(node2) 配置 upstream(node1)

2.5 添加 policy

2.6 成功的提示

六、联邦队列（Federation Queue）

1. 使用原因

2. 搭建步骤

2.1 原理图

2.2 添加 upstream（同上）

2.3 添加 policy

七、Shovel

1. 使用原因

2. 搭建步骤

2.1 开启插件（需要的机器都开启）

2.2 原理图（在源头发送的消息直接会进入到目的地队列）

2.3 添加 Shovel 源和目的地

四、RabbitMQ 集群相关推荐

最新文章

热门文章

一、`CentOS` 集群

2. 配置各个节点的 `hosts` 文件，让各个节点都能互相识别对方

3. 确保各个节点的 `cookie` 文件相同

4. 启动 `RabbitMQ` 服务，顺带启动 `Erlang` 虚拟机

二、`Docker` 集群

三、`HAProxy + Keepalived` 实现高可用负载均衡

2. `HAProxy` 实现负载均衡

3. `HAProxy` 搭建步骤

3.1 在 `node1` 和 `node2` 下载 `HAProxy`

3.2 .修改 `node1` 和 `node2` 的 `haproxy.cfg`

3.3 在两台节点启动 `HAProxy`

4. `Keepalived` 实现双机（主备）热备

5. `Keepalived` 搭建步骤

5.1 下载 `Keepalived`

5.2 节点 `node1` 配置文件

5.3 节点 `node2` 配置文件

5.4 添加 `haproxy_chk.sh`

5.5 在 `node1` 和 `node2` 启动 `Keepalived` 命令

5.6 观察 `Keepalived` 的日志

5.8 node1 模拟 `Keepalived` 关闭状态

五、联邦交换机（`Federation Exchange`）

六、联邦队列（`Federation Queue`）