RabbitMQ-运维

前言

运维-集群介绍

多机多节点

RabbitMQ集群对延迟⾮常敏感, 所以搭建RabbitMQ集群时, 多个节点应当在同⼀个局域⽹内

单机多节点

只有⼀个虚拟机, 我们启动N个节点, ⽤端⼝号来区分

单机多节点的⽅式, 也称为"伪集群"

多机多节点

下载

准备三台服务器，而且都在一个局域网内

然后三台机器分别安装Rabbitmq，版本最好保持一致

配置hosts⽂件

然后开始配置集群，配置hosts⽂件

这个就是节点名称

配置每个节点的hosts⽂件, 让各个节点都能互相识别对⽅

vim /etc/hosts

格式为: IP 主机名称
⽐如我的集群配置如下:

10.0.0.232 iZ2vc7a1n9gvhfp589oav8Z
10.0.0.233 iZ2vc7a1n9gvhfp589oav6Z
10.0.0.234 iZ2vc7a1n9gvhfp589oav7Z

这个ip是内网ip
输入
ifconfig

这个就是内网ip

more /etc/hostname

这个是查主机名称

为什么用内网ip
因为在同一个局域网
然后开始修改host

vim /etc/hosts

然后就是每台机器都是这样改

配置Erlang Cookie

RabbitMQ 节点和 CLI ⼯具(如rabbitmqctl) 使⽤Cookie来进⾏⾝份验证, 确认它们之间是否被允许相
互通信. 为了使两个节点可以通信, 它们必须具有相同的共享密钥, 称为 Erlang Cookie . Cookie是
⼀个字符串, 通常存储在本地⽂件中. 每个集群节点必须具有相同的Cookie.
Cookie ⽂件的位置:
RabbitMQ启动时, erlang 虚拟机会⾃动创建该⽂件, 通常位
于 /var/lib/rabbitmq/.erlang.cookie 和 $HOME/.erlang.cookie

先停⽌所有节点的服务

systemctl stop rabbitmq-server

在配置 Erlang Cookie

只需将⼀个节点上的 .erlang.cookie ⽂件分别拷⻉到另外两个节点上就可以
⽐如把node3节点的⽂件, 分别拷⻉到node1和node2对应的机器上
在node3上进⾏如下操作

拷⻉node3节点的⽂件到node1
scp /var/lib/rabbitmq/.erlang.cookie root@iZ2vc7a1n9gvhfp589oav8Z:/var/lib/rabbitmq/
然后是输入node1的密码就可以了

拷⻉node3节点的⽂件到node2
scp /var/lib/rabbitmq/.erlang.cookie root@iZ2vc7a1n9gvhfp589oav6Z:/var/lib/rabbitmq/

然后是输入node2的密码就可以了

说白了就是同步erlang.cookie

启动节点

以后端的⽅式启动三台RabbitMQ, 启动命令
rabbitmq-server -detached

构建集群

为了将集群中的三个节点连接起来, 需要告诉另外两个节点加⼊另⼀个节点, ⽐如node1和node2加⼊
node3节点.
加⼊node3之前, 必须重置两个新加⼊的成员, 也就是node1和node2
分别在要加⼊的两个机器上, 执⾏下⾯的操作命令：

#1. 关闭RabbitMQ服务
rabbitmqctl stop_app
#2. 重置当前节点
rabbitmqctl reset
#3.加⼊节点 后⾯跟的是node3节点
rabbitmqctl join_cluster rabbit@iZ2vc7a1n9gvhfp589oav7Z
#4. 启动服务
rabbitmqctl start_app

rabbit@iZ2vc7a1n9gvhfp589oav7Z是节点名称

查看集群状态

rabbitmqctl cluster_status

这样就可以都看到所有节点了

cluster搭建起来后, 如果在管理界⾯中, Nodes部分看到"Node statistics not available", 说明在该节点
上web管理插件还未启⽤

解决办法:
启动 rabbitmq_management 插件即可
在显⽰提⽰信息的节点上运⾏ rabbitmq-plugins enable rabbitmq_management

单机多节点

安装

启动两个节点

rabbitmqctl status #查看RabbitMQ状态

端⼝号介绍:
• 25672这是Erlang分布式节点通信的默认端⼝, Erlang是RabbitMQ的底层通信协议.
• 15672这是 Web管理界⾯的默认端⼝, 通过这个端⼝可以访问RabbitMQ的Web管理控制台, ⽤于
查看和管理消息队列.
• 5672这是 AMQP (Advanced Message Queuing Protocol) 协议的默认端⼝, ⽤于客⼾端与
RabbitMQ服务器之间的通信.

再启动两个节点

RABBITMQ_NODE_PORT=5673 RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener [{port,15673}]" RABBITMQ_NODENAME=rabbit2 rabbitmq-server -detached


RABBITMQ_NODE_PORT=5674 RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener [{port,15674}]" RABBITMQ_NODENAME=rabbit3 rabbitmq-server -detached

验证RabbitMQ启动成功

在云服务器开通 15673, 15674端⼝号

然后就是分别测试这些端口

搭建集群

停⽌服务并重置
停⽌⽬的是为了重置

rabbitmqctl -n rabbit2 stop_app
rabbitmqctl -n rabbit2 reset
rabbitmqctl -n rabbit3 stop_app
rabbitmqctl -n rabbit3 reset

把rabbit2, rabbit3添加到集群

rabbit@hcss-ecs-6fa6

rabbitmqctl -n rabbit2 join_cluster rabbit@hcss-ecs-2618


rabbitmqctl -n rabbit3 join_cluster rabbit@hcss-ecs-2618

这个报警就忽略掉

rabbit@hcss-ecs-2618是节点名称，可以在管理界面看，也可以用命令rabbitmqctl status来查看
这样就加入成功了

加入成功，但是没有运行成功

重启

rabbitmqctl -n rabbit2 start_app
rabbitmqctl -n rabbit3 start_app

查看集群状态
rabbitmqctl cluster_status -n rabbit

宕机演示

我们添加队列，选择主节点

弄好集群之后，账号都是共用的

而且虚拟机也是同步共用的

队列也是会同步的

这里可以发送消息
然后所有节点都有这个消息的
说明数据都是同步的

如果一个机器宕机呢

我们直接关闭Rabbit节点

rabbitmqctl -n rabbit stop_app

集群少了一个机器了

消息也丢失了
因为这个消息就是在这个节点上的，这个节点关了，消息就丢失了，虽然消息同步

仲裁队列介绍

每个队列都有自己的主节点
每个队列的消息就是放在自己对应的主节点上的，但是也会在从节点上显示
主节点宕机了，对应队列也完了
因为队列是没有复制的，所以主节点没了，数据就没了

RabbitMQ 的仲裁队列是⼀种基于 Raft ⼀致性算法实现的持久化、复制的 FIFO 队列. 仲裁队列提供队列复制的能⼒, 保障数据的⾼可⽤和安全性. 使⽤仲裁队列可以在 RabbitMQ 节点间进⾏队列数据的复制, 从⽽达到在⼀个节点宕机时, 队列仍然可以提供服务的效果.
仲裁队列官网

仲裁队列是RabbitMQ 3.8版本最重要的改动. 他是镜像队列的替代⽅案. 在 RabbitMQ 3.8 版本问世之前, 镜像队列是实现数据⾼可⽤的唯⼀⼿段, 但是它有⼀些设计上的缺陷, 这也是 RabbitMQ 提供仲裁队列的原因. 经典镜像队列已被弃⽤，并计划在将来版本中移除, 如果当前使⽤经典镜像队列的
RabbitMQ 安装需要迁移, 可以参考官⽅提供的迁移指南
官网

raft算法协议

论文介绍
Raft 是⼀种⽤于管理和维护分布式系统⼀致性的协议, 它是⼀种共识算法, 旨在实现⾼可⽤性和数据的持久性**. Raft 通过在节点间复制数据来保证分布式系统中的⼀致性，即使在节点故障的情况下也能保证数据不会丢失.**
在分布式系统中, 为了消除单点提⾼系统可⽤性, 通常会使⽤副本来进⾏容错, 但这会带来另⼀个问题,即如何保证多个副本之间的⼀致性？副本就是从节点
共识算法（Consensus Algorithm）就是做这个事情的, 它允许多个分布式节点就某个值或⼀系列值达成⼀致性协议. 即使在⼀些节点发⽣故障, ⽹络分区或其他问题的情况下, 共识算法也能保证系统的⼀致性和数据的可靠性.
常⻅的共识算法有: Paxos, Raft, Zab等
• Paxos: ⼀种经典的共识算法, ⽤于解决分布式系统中的⼀致性问题.
• Raft：⼀种较新的共识算法, Paxos 不易实现, raft是对Paxos算法的简化和改进, 旨在易于理解和实
现.
• Zab：ZooKeeper 使⽤的共识算法, 基于 Paxos 算法., ⼤部分和Raft相同, 主要区别是对于Leader的
任期, Raft叫做term, Zab叫做epoch, 状态复制的过程中, raft的⼼跳从Leader向Follower发送, ⽽
ZAB则相反.
• Gossip: Gossip算法每个节点都是对等的, 即没有⻆⾊之分. Gossip算法中的每个节点都会将数据改
动告诉其他节点（类似传⼋卦）

raft基本概念

Raft 使⽤ Quorum 机制来实现共识和容错, 我们将对 Raft 集群的操作必须得到⼤多数(> N/2)节点的同意才能提交.
节点指的是分布式系统中的⼀个独⽴成员
当我们向 Raft 集群发起⼀系列读写操作时, 集群内部究竟发⽣了什么呢? 我们先来简单了解⼀下.
Raft 集群必须存在⼀个主节点(Leader), 客⼾端向集群发起的所有操作都必须经由主节点处理. 所以
Raft 核⼼算法中的第⼀部分就是选主(Leader election). 没有主节点集群就⽆法⼯作, 先选出⼀个主节
点, 再考虑其它事情

主节点会负责接收客⼾端发过来的操作请求, 将操作包装为⽇志同步给其它节点, 在保证⼤部分节点都同步了本次操作后, 就可以安全地给客⼾端回应响应了. 这⼀部分⼯作在 Raft 核⼼算法中叫⽇志复制(Log replication).
因为主节点的责任⾮常⼤, 所以只有符合条件的节点才可以当选主节点.
为了保证集群对外展现的⼀致性, 主节点在处理操作⽇志时, 也⼀定要谨慎, 这部分在Raft核⼼算法中叫 安全性(Safety).Raft算法将⼀致性问题分解为三个⼦问题: Leader选举, ⽇志复制和安全性.
下⾯我们详细介绍下Raft的选主过程.

选主

选主(Leader election)就是在集群中抉择出⼀个主节点来负责⼀些特定的⼯作. 在执⾏了选主过程后, 集群中每个节点都会识别出⼀个特定的, 唯⼀的节点作为 leader.
节点⻆⾊
在 Raft 算法中，每个节点都处于以下三种⻆⾊之⼀
• Leader(领导者): 负责处理所有客⼾请求，并将这些请求作为⽇志项复制到所有 Follower. Leader
定期向所有 Follower 发送⼼跳消息, 以维持其领导者地位, 防⽌ Follower 进⼊选举过程.
• Follower(跟随者): 接收来⾃ Leader 的⽇志条⽬, 并在本地应⽤这些条⽬. 跟随者不直接处理客⼾请
求.
• Candidate(候选者): 当跟随者在⼀段时间内没有收到来⾃ Leader 的⼼跳消息时，它会变得不确定
Leader 是否仍然可⽤. 在这种情况下, 跟随者会转变⻆⾊成为 Candidate, 并开始尝试通过投票过程
成为新的 Leader

在正常情况下, 集群中只有⼀个 Leader, 剩下的节点都是 follower, 下图展⽰了这些状态和它们之间的转换关系

可以看出所有节点在启动时, 都是follow状态, 在⼀段时间内如果没有收到来⾃leader的⼼跳, 从
follower切换到candidate, 发起选举. 如果收到多数派(majority)的投票(含⾃⼰的⼀票) 则切换到
leader状态. Leader⼀般会⼀直⼯作直到它发⽣异常为⽌

任期

Raft 将时间划分成任意⻓度的任期(term). 每⼀段任期从⼀次选举开始, 在这个时候会有⼀个或者多个candidate 尝试去成为 leader. 在成功完成⼀次leaderelection之后,⼀个leader就会⼀直节管理集群直到任期结束. 在某些情况下, ⼀次选举⽆法选出 leader, 这个时候这个任期会以没有 leader ⽽结束(如下图t3). 同时⼀个新的任期(包含⼀次新的选举) 会很快重新开始

Term 更像是⼀个逻辑时钟(logic clock)的作⽤, 有了它，就可以发现哪些节点的状态已经过期. 每⼀个节点都保存⼀个 current term, 在通信时带上这个 term的值.
每⼀个节点都存储着⼀个当前任期号(current term number). 该任期号会随着时间单调递增. 节点之间通信的时候会交换当前任期号, 如果⼀个节点的当前任期号⽐其他节点⼩, 那么它就将⾃⼰的任期号更新为较⼤的那个值. 如果⼀个 candidate 或者 leader 发现⾃⼰的任期号过期了, 它就会⽴刻回到
follower 状态. 如果⼀个节点接收了⼀个带着过期的任期号的请求, 那么它会拒绝这次请求.
Raft 算法中服务器节点之间采⽤ RPC 进⾏通信, 主要有两类 RPC 请求:
• RequestVote RPCs: 请求投票, 由 candidate 在选举过程中发出
• AppendEntries RPCs: 追加条⽬, 由 leader 发出, ⽤来做⽇志复制和提供⼼跳机制

raft选取过程

Raft 采⽤⼀种⼼跳机制来触发 leader 选举, 当服务器启动的时候, 都是follow状态. 如果follower在
election timeout内没有收到来⾃leader的⼼跳(可能没有选出leader, 也可能leader挂了, 或者leader与
follower之间⽹络故障), 则会主动发起选举

步骤如下:

1. 率先超时的节点, ⾃增当前任期号然后切换为 candidate 状态, 并投⾃⼰⼀票
2. 以并⾏的⽅式发送⼀个 RequestVote RPCs 给集群中的其他服务器节点（企图得到它们的投票）
3. 等待其他节点的回复

在这个过程中, 可能出现三种结果
a. 赢得选举, 成为Leader(包括⾃⼰的⼀票)
b. 其他节点赢得了选举, 它⾃⾏切换到follower
c. ⼀段时间内没有收到majority投票, 保持candidate状态, 重新发出选举

投票要求:
• 每⼀个服务器节点会按照 先来先服务原则(first-come-first-served)只投给⼀个 candidate.
• 候选⼈知道的信息不能⽐⾃⼰的少

接下来对这三种情况进⾏说明:
第⼀种情况: 赢得了选举之后, 新的leader会⽴刻给所有节点发消息, ⼴⽽告之, 避免其余节点触发新的选举

第⼆种情况: ⽐如有三个节点A B C, A B同时发起选举, ⽽A的选举消息先到达C, C给A投了⼀票, 当B的消息到达C时, 已经不能满⾜上⾯提到的第⼀个约束, 即C不会给B投票, 这时候A就胜出了. A胜出之后, 会给B,C发⼼跳消息, 节点B发现节点A的term不低于⾃⼰的term, 知道有已经有Leader了, 于是把⾃⼰转换成follower.

第三种情况: 没有任何节点获得majority投票. ⽐如所有的 follower 同时变成 candidate, 然后它们都将
票投给⾃⼰, 那这样就没有 candidate 能得到超过半数的投票了. 当这种情况发⽣的时候, 每个
candidate 都会进⾏⼀次超时响应, 然后通过⾃增任期号来开启⼀轮新的选举, 并启动另⼀轮的
RequestVote RPCs. 如果没有额外的措施, 这种⽆结果的投票可能会⽆限重复下去

为了解决上述问题，Raft 采⽤ 随机选举超时时间（randomized election timeouts） 来确保很少产⽣
⽆结果的投票，并且就算发⽣了也能很快地解决。为了防⽌选票⼀开始就被⽠分，选举超时时间是从⼀个固定的区间（⽐如，150-300ms）中随机选择。这样可以把服务器分散开来以确保在⼤多数情况下会只有⼀个服务器率先结束超时，那么这个时候，它就可以赢得选举并在其他服务器结束超时之前发送⼼跳

Raft 动画演⽰在线地址

消息复制

每个仲裁队列都有多个副本, 它包含⼀个主和多个从副本. replication factor 为 5的仲裁队列将会有 1个主副本和 4 个从副本. 每个副本都在不同的 RabbitMQ 节点上
客⼾端(⽣产者和消费者)只会与主副本进⾏交互, 主副本再将这些命令复制到从副本. 当主副本所在的节点下线, 其中⼀个从副本会被选举成为主副本, 继续提供服务.

消息复制和主副本选举的操作, 需要超过半数的副本同意. 当⽣产者发送⼀条消息, 需要超过半数的队列副本都将消息写⼊磁盘以后才会向⽣产者进⾏确认, 这意味着少部分⽐较慢的副本不会影响整个队列的性能.

仲裁队列使用与演示

@Bean("quorumQueue")
public Queue quorumQueue() {
 return QueueBuilder.durable("quorum.queue").quorum().build();
}

这个类型也是仲裁队列的意思
创建时选择Type为Quorum, 指定主副本

这里端口号随便写一个，记得开通

然后是发送消息

声明就是多了一个quorm而已

+2的意思就是有两个副本

leader是rabbit3，这个是因为我们配置的优先是rabbit3

还显示了在线成员

这个创建仲裁队列，node就是选择主节点，记得在有权限的虚拟机上操作

可以看到这个队列的主节点就是rabbit2了

然后发送消息都是会同步的，而且主节点宕机了也不会有事

我们把rabbit3停了

可以看出，选主了，主节点变成rabbiti了

然后重启rabbit3

但是rabbit不是主节点了现在

可以看到, 仲裁队列后⾯有⼀个 + 2 字样, 代表这个队列有2个镜像节点.
仲裁队列默认的镜像数为5, 即⼀个主节点, 4个从副本节点.
如果集群中节点数量少于 5, ⽐如我们搭建了3个节点的集群, 那么创建的仲裁队列就是 1 主 2 从.
如果集群中的节点数⼤于 5 个的话, 那么就只会在 5 个节点中创建出 1主 4 从

意思就是七个节点也是1主 4 从

HAProxy安装

我们这个项目的缺点就是5674宕机了，就运行不了了

怎么办呢
虽然集群没有问题，但是程序有问题了
有两个问题
1.如果我们访问的是node1, 但是node1挂了, 咱们的程序也会出现问题, 所以最好是有⼀个统⼀的⼊
⼝, ⼀个节点故障时, 流量可以及时转移到其他节点.
2. 如果所有的客⼾端都与node1建议连接, 那么node1的⽹络负载必然会⼤⼤增加, ⽽其他节点⼜由于
没有那么多的负载⽽造成硬件资源的浪费

这时候要负载均衡了

引⼊负载均衡之后, 各个客⼾端的连接可以通过负载均衡分摊到集群的各个节点之中, 从⽽避免前⾯的问题.

这⾥主要讨论的是如何有效地对RabbitMQ集群使⽤软件负载均衡技术,⽬前主流的⽅式有在客⼾端内
部实现负载均衡,或者使⽤HAProxy、LVS等负载均衡有软件来实现. 咱们这⾥讲⼀下使⽤HAProxy来实现负载均衡.

负载均衡不是平均分配
接下来我们来安装HAProxy, 实现负载均衡.
HAProxy（High Availability Proxy）是⼀个开源的负载均衡器和TCP/HTTP应⽤程序的代理服务器, 它被设计⽤来提供⾼可⽤性, 负载均衡和代理功能. HAProxy主要⽤于分发⽹络流量到多个后端服务器, 以提⾼⽹络的可靠性和性能

安装

#更新软件包
sudo apt-get update
#查找haproxy
sudo apt list|grep haproxy
#安装haproxy
sudo apt-get install haproxy

验证安装

#查看服务状态
sudo systemctl status haproxy
#查看版本
haproxy -v 
#如果要设置HAProxy服务开机⾃启，可以使⽤：
sudo systemctl enable haproxy

修改haproxy.cfg

就是怎么分发

vim /etc/haproxy/haproxy.cfg

# haproxy web 管理界面
listen stats
    bind *:8100       
    mode http
    stats enable
    stats realm Haproxy\ Statistics    
    stats uri /
    stats auth admin:admin
# 配置负载均衡
listen rabbitmq
    bind *:5670
    mode tcp
    balance roundrobin
    server  rabbitmq1 127.0.0.1:5672  check inter 5000 rise 2 fall 3
    server  rabbitmq2 127.0.0.1:5673  check inter 5000 rise 2 fall 3
    server  rabbitmq3 127.0.0.1:5674  check inter 5000 rise 2 fall 3

# haproxy web 管理界⾯---》浏览器要访问的
listen stats #设置⼀个监听器, 统计HAProxy的统计信息
	 bind *:8100 #指定了监听器绑定到的IP地址和端⼝
	 mode http #监听器的⼯作模式为HTTP
	 stats enable #启⽤统计⻚⾯
	 stats realm Haproxy\ Statistics
	 stats uri /
	 stats auth admin:admin #haproxy登录账号和密码
# 配置负载均衡
listen rabbitmq #设置监听器
	 bind *:5670 #监听器绑定到的IP地址和端⼝, 也就是集群前端IP, 供producer和consumer
	来进⾏选择，由于5672端⼝已经默认使⽤, 这⾥选择5670端⼝
	 mode tcp #由于RabbitMQ使⽤AMQP协议，它是⼀个基于TCP的协议，所以这⾥使⽤TCP模
式
	 balance roundrobin #指定负载均衡策略为轮询
	 #负载均衡中的集群节点配置，这⾥选择的rabbit节点
	 server rabbitmq1 127.0.0.1:5672 check inter 5000 rise 2 fall 3
	 server rabbitmq2 127.0.0.1:5673 check inter 5000 rise 2 fall 3
	 server rabbitmq3 127.0.0.1:5674 check inter 5000 rise 2 fall 3

rabbitmq3是给haproxy 用的，不是节点名称
还有bind *:8100的8100和 bind *:5670的5670可以换的
check inter 5000 rise 2 fall 3是健康检查，就是每隔五秒钟检查一次，检查五次，但是不会放弃这个节点的

还需要开通8100和5670端口号

然后复制到vim /etc/haproxy/haproxy.cfg这个里面
拼接进去

重启haproxy

sudo systemctl restart haproxy

查看HAProxy

http://124.71.229.73:8100/

rabbit3就是一个停掉的状态


这样就变好了

HAProxy使用

这里改成5670就可以了

配置的5670是HAProxy的一个端口号

发现成功发送了
现在把rabbit节点停掉



继续发送消息

发现还是可以发送的
说明有一个节点宕机不影响HAProxy的使用，不影响集群的使用，不影响程序的使用
如何HAProxy挂了呢
那么所有都访问不了了
因为配置的端口就是HAProxy的-

如果HAProxy主机突然宕机或者⽹卡失效,那么虽然RabbitMQ集群没有任何故障, 但是对于外界的客
⼾端来说所有的连接都会被断开,结果将是灾难性的. 确保负载均衡服务的可靠性同样显得⼗分重要.
通常情况下, 会使⽤Keepalived 等⾼可⽤解决⽅案对haproxy做主备, 在HAProxy主节点故障时⾃动
将流量转移到备⽤节点

总结