RabbitMQ-网络分区（Network Partitions）处理

作者介绍：简历上没有一个精通的运维工程师，下面的思维导图也是预计更新的内容和当前进度(不定时更新)。

中间件，我给它的定义就是为了实现某系业务功能依赖的软件，包括如下部分:

Web服务器

代理服务器

ZooKeeper

Kafka

RabbitMQ(本章节)

前面介绍了网络分区的基本情况，哪当真的网络分区发生以后，我们应该如何来恢复这个网络分区呢？虽然上个小节介绍了通过自动降级来避免网络分区的出现，但是真实环境是很复杂的，甚至说网络分区必定会出现的，所以我们还需要掌握网络分区的处理方式。

如何处理网络分区

1. 识别与确认： 使用 UI/CLI/日志确认分区发生、哪些节点在哪个分区、哪个是多数派（活跃分区）。
2. 解决根本原因：首要任务！ 修复网络问题（检查网络设备、云服务状态、防火墙规则、DNS、主机可达性）。不解决网络问题，恢复无从谈起。
3. 等待自动恢复 (推荐用于 pause-minority): 在 pause-minority 模式下且网络问题修复后，暂停的节点通常能自动重新连接到多数派节点并开始同步恢复。这是最安全、首选的方式。如果能自动回复，其实不叫网络分区，而是只是节点故障（我这里尝试了多种方法均未能实现模拟网络分区，只能算是节点离线故障）。
4. 手动恢复 (谨慎使用！): 如果自动恢复失败或需要干预，可以使用 rabbitmqctl forget_cluster_node 命令将已脱离且数据可能过时/不一致的节点（通常是原少数派节点）从集群配置中移除，然后再将其作为新节点重新加入集群并同步数据。此操作有数据丢失风险，需充分评估。

这个方式也本来是打算用来手工恢复的方法。由于没有模拟成功网络分区，所以我们这里模拟把mq03节点当作异常的节点，把他剔除集群在加入回来来模拟。

当前集群的情况：

Running Nodes

rabbit@rabbitmq01
rabbit@rabbitmq02
rabbit@rabbitmq03

#当然我这个正式环境需要先停止mq进程 

[root@rabbitmq03 rabbitmq]# /opt/rabbitmq_server-3.8.35/sbin/rabbitmqctl stop_app
Stopping rabbit application on node rabbit@rabbitmq03 ...
[root@rabbitmq03 rabbitmq]# 

[root@rabbitmq02 root]# /opt/rabbitmq_server-3.8.35/sbin/rabbitmqctl forget_cluster_node  rabbit@rabbitmq03
Removing node rabbit@rabbitmq03 from the cluster
[root@rabbitmq02 root]# 

这个时候整个集群就由3个节点变成2个节点。如果真实环境应该是需要先执行stop_app

[root@rabbitmq03 rabbitmq]# /opt/rabbitmq_server-3.8.35/sbin/rabbitmqctl  join_cluster rabbit@rabbitmq01
Clustering node rabbit@rabbitmq03 with rabbit@rabbitmq01
[root@rabbitmq03 rabbitmq]# /opt/rabbitmq_server-3.8.35/sbin/rabbitmqctl  start_app
Starting node rabbit@rabbitmq03 ...
[root@rabbitmq03 rabbitmq]# 

这个时候节点就算恢复成功。

如何预防网络分区？

• 健壮的网络基础设施： 使用高质量网络设备、冗余链路（双网卡绑定）、合理的网络拓扑、避免单点故障。在云环境中，确保实例位于同一可用区（AZ）内以获得最佳网络（但需权衡与可用性），或使用支持低延迟跨 AZ 的网络方案。
• 集群规模与放置： 使用奇数个节点（3, 5, 7），这样更容易形成明确的多数派。将节点放置在低延迟、高带宽、稳定的网络环境中。避免跨地理区域的集群（除非使用 Federation/Shovel）。
• 监控与告警： 密切监控网络健康状况（延迟、丢包率）、节点资源使用情况（CPU, Mem, Disk, FD）和 RabbitMQ 集群状态。设置告警以便在分区发生或网络状况恶化时立即知晓。
• 调整心跳：net_ticktime 参数控制 Erlang 节点间的心跳间隔。适当增加（默认 60s）可能对不稳定的网络有一定容忍度，但会增加故障检测时间。需谨慎调整。
• 考虑 Federation / Shovel： 对于需要跨地域或不可靠网络连接的场景，优先考虑使用 Federation 或 Shovel 来链接独立的 RabbitMQ 实例/集群，而不是构建一个大的跨地域集群。这避免了网络分区问题，但牺牲了全局队列镜像。
• 使用 Quorum Queues： 对于需要强一致性的队列，优先使用 Quorum Queues 代替传统的镜像队列。Quorum 队列基于 Raft 共识协议，天生设计为在发生网络分区时自动处理脑裂问题，并在恢复时以更可预测的方式处理冲突，通常比传统镜像队列在分区场景下表现更优、更安全。

总结： RabbitMQ 的网络分区是集群在高可用部署中需要面对的关键挑战。默认的 pause-minority 模式通过牺牲少数派分区的可用性来换取整个集群的数据一致性（防止脑裂）。理解其原理、影响、检测方法和（自动/手动）恢复步骤对于运维 RabbitMQ 集群至关重要。预防措施（健壮网络、奇数节点、监控、Quorum Queues）应优先考虑。在处理恢复时，尤其是在手动干预时，务必保持高度谨慎，避免数据丢失。