RabbitMQ-网络分区（Network Partitions）

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

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

Web服务器

代理服务器

ZooKeeper

Kafka

RabbitMQ(本章节)

没处理过RabbitMQ网络分区的运维，不是好运维。虽然这是一句玩笑话，但是也从侧面说明网络分区的问题在RabbitMQ里面重要性。

虽然我们用镜像队列解决了RabbitMQ高可用的问题，但是高可用也给我们来了他最大的问题：网络分区，下面我们就来详细介绍RabbitMQ的网络分区。

RabbitMQ 的网络分区（Network Partition）是指集群中的节点之间由于网络故障导致彼此失去连接，从而将原本统一的集群分裂成多个独立运作的子集群（称为“分区”）的现象。这是分布式系统（尤其是基于 Erlang 的 RabbitMQ）中一个需要特别关注的问题，因为它会破坏数据一致性，导致脑裂（Split-Brain）的发生。

以下是关于 RabbitMQ 网络分区的详细介绍：

1. 根本原因

• 网络中断： 节点间的网络连接暂时或永久性中断（交换机、路由器故障、网线问题、防火墙配置错误、云网络分区等）。
• 资源耗尽： 节点因 CPU、内存、磁盘 I/O 或文件描述符耗尽而无法及时响应其他节点的心跳，被其他节点误判为离线。
• 不稳定的网络： 高延迟或频繁丢包可能导致心跳超时，触发分区。

2. 核心问题：脑裂 (Split-Brain) 当一个集群被分区后，每个分区内的节点都认为自己是“活着的”，而其他分区的节点是“死掉的”或“不可达的”。这会导致严重问题：

• 队列与消息的歧义： 同一个队列（尤其是镜像队列）可能在不同分区中同时存在一个活跃的 Master（主副本）。两个 Master 都能接收生产者的消息并服务消费者。
• 数据不一致： 由于两个 Master 独立处理消息（发布、消费、确认），它们各自维护的消息状态（队列内容、消息顺序、消费状态）会迅速分叉，变得不一致。
• 客户端混乱： 连接到不同分区的客户端可能看到完全不同的队列状态，或者操作成功但实际只在一个分区生效。

3. RabbitMQ 的处理策略：pause-minority 模式 (默认且推荐) RabbitMQ 默认采用 pause-minority 模式来自动处理网络分区，旨在防止脑裂：

• 原理： 每个节点都会持续监控与其他节点的连接状态。当节点检测到它无法连接到集群中的大多数节点时（即它自己处于少数派分区），它会自动暂停（pause）自己。
• 效果：
  • 多数派分区： 能连接到集群中超过半数节点的分区会继续正常运行。它拥有“法定人数”（Quorum），可以安全地处理操作。
  • 少数派分区： 无法连接到集群中超过半数节点的分区会自动暂停其 RabbitMQ 应用（Erlang 进程）。节点进程仍在运行，但不再接受客户端连接、处理消息或参与集群操作。它看起来像是“挂起”或“冻结”了。
• 目的： 确保在发生分区时，最多只有一个分区（即拥有大多数节点的那个分区）能够保持活跃并处理流量，从而避免了脑裂和不一致。
• 恢复： 当网络恢复，暂停的节点（少数派）重新能够连接到集群中的大多数节点时，它会自动解除暂停状态，并从当前有效的多数派分区同步状态和数据（可能需要处理冲突）。

注：这个自动降级也并不是万能的，还需要关注更多的信息。

4. 如何检测网络分区？ RabbitMQ 提供了多种途径：

• 管理 UI： 首页顶部会有醒目的红色警告横幅 “Partition(s) detected”，并列出受影响的节点及其所在分区。Nodes 页面中，被暂停的节点状态会显示为 Partition。
• CLI 命令：
  • rabbitmq-diagnostics cluster_status：输出中会明确显示 partitions 部分，列出每个分区包含的节点。
  • rabbitmqctl cluster_status：较老版本，输出格式不同，但也会包含分区信息。

• 日志文件： RabbitMQ 节点的日志文件（通常在 /var/log/rabbitmq/ 下）会记录检测到分区、节点暂停/恢复等关键事件，包含详细原因。