RabbitMQ运维

1. 单机多节点

1.1 搭建RabbitMQ

①安装RabbitMQ

略

②确认RabbitMQ运⾏没问题

#查看RabbitMQ状态

rabbitmqctl status

节点名称:

端口号:

25672:Erlang分布式节点通信的默认端⼝, Erlang是RabbitMQ的底层通信协议.
15672: Web管理界⾯的默认端⼝, 通过这个端⼝可以访问RabbitMQ的Web管理控制台, ⽤于查看和管理消息队列
5672: AMQP 协议的默认端⼝, ⽤于客⼾端与 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端⼝号:

分别测试:

119.91.154.99:15673/

119.91.154.99:15674/

1.2 搭建集群

①停⽌服务并重置

rabbitmqctl -n rabbit2 stop_app

rabbitmqctl -n rabbit2 reset

rabbitmqctl -n rabbit3 stop_app

rabbitmqctl -n rabbit3 reset

运行结果:

②把rabbit2, rabbit3添加到集群

rabbit@localhost是主节点的node Name

rabbitmqctl -n rabbit2 join_cluster rabbit@localhost

rabbitmqctl -n rabbit3 join_cluster rabbit@localhost

③重启rabbit2,rabbit3

rabbitmqctl -n rabbit2 start_app

rabbitmqctl -n rabbit3 start_app

④查看集群状态

rabbitmqctl cluster_status -n rabbit

通过主节点(rabbit)管理界⾯, 可以看到集群其他节点:

2. 宕机演示

2.1 添加队列

添加bit虚拟机,其它节点也有了这个虚拟机

在bit虚拟机中添加队列:

2.2 添加之后,可以看到三个节点都有队列了

2.3 往testQueue队列中发送⼀条数据(从任⼀节点都可以)

发送之后, 观察3个节点的队列中均有消息:

2.4 关闭主节点

关闭后可以看到rabbit2和rabbit3没有该队列的数据了

也就是说, 这个数据只在主节点存在, 从节点没有

如何解决这个问题呢, 就需要引⼊"仲裁队列"

3. 仲裁队列(Quorum Queues)

RabbitMQ 的仲裁队列是⼀种基于 Raft ⼀致性算法实现的持久化、复制的 FIFO 队列. 仲裁队列提供队列复制的能⼒, 保障数据的⾼可⽤和安全性.

使⽤仲裁队列可以在 RabbitMQ 节点间进⾏队列数据的复制, 从⽽达到在⼀个节点宕机时, 队列仍然可以提供服务的效果

3.1 Raft协议介绍

Raft 是⼀种⽤于管理和维护分布式系统⼀致性的协议, 它是⼀种共识算法, 旨在实现⾼可⽤性和数据的持久性. Raft 通过在节点间复制数据来保证分布式系统中的⼀致性，即使在节点故障的情况下也能保证数据不会丢失.

在分布式系统中, 为了消除单点提⾼系统可⽤性, 通常会使⽤副本来进⾏容错, 但这会带来另⼀个问题, 即如何保证多个副本之间的⼀致性？

共识算法就是做这个事情的, 它允许多个分布式节点就某个值或⼀系列值达成⼀致性协议. 即使在⼀些节点发⽣故障, ⽹络分区或其他问题的情况下, 共识算法也能保证系统的⼀致性和数据的可靠性.

常⻅的共识算法有: Paxos, Raft, Zab等,此处用Raft算法

3.2 Raft 基本概念

Raft 使⽤ Quorum 机制来实现共识和容错, 我们将对 Raft 集群的操作必须得到⼤多数(> N/2)节点的同意才能提交.

Raft 集群必须存在⼀个主节点(Leader), 客⼾端向集群发起的所有操作都必须经由主节点处理. 所以 Raft 核⼼算法中的第⼀部分就是选主(Leader election). 没有主节点集群就⽆法⼯作, 先选出⼀个主节点, 再考虑其它事情

主节点会负责接收客⼾端发过来的操作请求, 将操作包装为⽇志同步给其它节点, 在保证⼤部分节点都同步了本次操作后, 就可以安全地给客⼾端回应响应了. 这⼀部分⼯作在 Raft 核⼼算法中叫⽇志复制 (Log replication).

因为主节点的责任⾮常⼤, 所以只有符合条件的节点才可以当选主节点. 为了保证集群对外展现的⼀致 , 主节点在处理操作⽇志时, 也⼀定要谨慎, 这部分在Raft核⼼算法中叫安全性(Safety).

Raft算法将⼀致性问题分解为三个⼦问题: Leader选举, ⽇志复制和安全性.

选主(Leader election)

选主(Leader election)就是在集群中抉择出⼀个主节点来负责⼀些特定的⼯作.

在执⾏了选主过程后, 集群中每个节点都会识别出⼀个特定的, 唯⼀的节点作为 leader

角色

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. 在成功完成⼀次leader election之后,⼀个leader就会⼀直节管理集群直到任期结束. 在某些情况下, ⼀次选举⽆法选出 leader, 这个时候这个任期会以没有 leader ⽽结束. 同时⼀个新的任期(包含⼀次新的选举) 会很快重新开始

Term 更像是⼀个逻辑时钟(logic clock)的作⽤, 有了它，就可以发现哪些节点的状态已经过期. 每⼀个节点都保存⼀个 current term, 在通信时带上这个 term的值.

每⼀个节点都存储着⼀个当前任期号(current term number). 该任期号会随着时间单调递增. 节点之间通信的时候会交换当前任期号, 如果⼀个节点的当前任期号⽐其他节点⼩, 那么它就将⾃⼰的任期号更新为较⼤的那个值. 如果⼀个 candidate 或者 leader 发现⾃⼰的任期号过期了, 它就会⽴刻回到 follower 状态. 如果⼀个节点接收了⼀个带着过期的任期号的请求, 那么它会拒绝这次请求.

Raft 算法中服务器节点之间采⽤ RPC 进⾏通信, 主要有两类 RPC 请求:

RequestVote RPCs: 请求投票, 由 candidate 在选举过程中发出
AppendEntries RPCs: 追加条⽬, 由 leader 发出, ⽤来做⽇志复制和提供⼼跳机制

选举过程

Raft 动画演⽰官方在线地址: https://raft.github.io/

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

所有节点均为follow状态:

步骤如下:

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

S1节点率先超时,把任期号改为2,切换为candidate 状态, 并投⾃⼰⼀票:

在这个过程中, 可能出现三种结果

赢得选举, 成为Leader(包括⾃⼰的⼀票)
其他节点赢得了选举, 它⾃⾏切换到follower
⼀段时间内没有收到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.

S5收到S1的心跳消息,发现S1的term不低于自己,知道有leader了,把自己切换为follower:

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

注意:

为了解决上述问题，Raft 采⽤随机选举超时时间来确保很少产⽣⽆结果的投票，并且就算发⽣了也能很快地解决。

为了防⽌选票⼀开始就被⽠分，选举超时时间是从⼀个固定的区间（⽐如，150-300ms）中随机选择。这样可以把服务器分散开来以确保在⼤多数情况下会只有⼀个服务器率先结束超时，那么这个时候，它就可以赢得选举并在其他服务器结束超时之前发送⼼跳。

3.3 Raft 协议下的消息复制

每个仲裁队列都有多个副本, 它包含⼀个主和多个从副本. replication factor 为 5的仲裁队列将会有 1个主副本和 4 个从副本. 每个副本都在不同的 RabbitMQ 节点上

客⼾端(⽣产者和消费者)只会与主副本进⾏交互, 主副本再将这些命令复制到从副本. 当主副本所在的节点下线, 其中⼀个从副本会被选举成为主副本, 继续提供服务.

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

3.4 仲裁队列的使⽤

①创建仲裁队列

1)使⽤Spring框架代码创建

2)使⽤管理平台创建

创建时选择Type为Quorum, 指定主副本

②创建后观察管理平台

+2表示有两个副本

点进去看队列详情:

对比普通队列:

③接收/发送消息

3.5 宕机演示

① 给仲裁队列 quorum_queue 发送消息

②停掉队列主副本所在的节点

观察其他节点, 可以看到quorum_queue 队列的内容依然存在:

并且, 因为主副本所在节点宕机了, quorum_queue 主副本从rabbit@localhost 转移到了 rabbit3@localhost+1

队列详细信息: 只剩下两个成员了:

4. HAProxy 负载均衡

⾯对⼤量业务访问、⾼并发请求,可以使⽤⾼性能的服务器来提升RabbitMQ服务的负载能⼒.

当单机容量达到极限时, 可以采取集群的策略来对负载能⼒做进⼀步的提升, 但这⾥还存在⼀些问题.

试想如果⼀个集群中有3个节点, 我们在写代码时, 访问哪个节点呢?

答案是访问任何⼀个节点都可以.

这时候就存在两个问题:

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

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

这⾥讲⼀下使⽤HAProxy来实现负载均衡.

4.1 安装

安装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

解释:

server rabbitmq1 : 定义RabbitMQ服务的内部标识, 这⾥的rabbitmq1 是指haproxy内部使⽤的, 不是指RabbitMQ的节点名称
127.0.0.1:5672 : RabbitMQ真实的IP和端⼝
check inter 5000 : 定义每隔多少毫秒检查RabbitMQ服务是否可⽤
rise 2 : 定义RabbitMQ服务在发⽣故障之后,需要多少次健康检查才能被再次确认可⽤.
fall 3 : 定义需要经历多少次失败的健康检查之后,HAProxy才会停⽌使⽤此RabbitMQ服务

重启HAPROXY

sudo systemctl restart haproxy

查看HAProxy

通过119.91.154.99:8100访问

4.2 使用

①修改配置文件

spring:
  rabbitmq:
    addresses: amqp://admin:[email protected]:5670/ops

②声明队列 test_cluster

③发送消息

④测试

⑤宕机演示

停⽌其中⼀个节点, 继续测试步骤2的代码:

再次发送:

显⽰队列中有两条数据

⑥集群恢复

观察消息也同步到当前节点了: