在 CentOS 上防止 RabbitMQ 网络分区的关键做法
一 架构与部署层面的预防
- 优先将集群部署在同一局域网（LAN），避免跨机房/跨地域直接组集群；跨广域场景应使用 Federation 或 Shovel 解耦，而不是直接互联集群。这样可显著降低分区概率与影响范围。
- 采用奇数节点（如 3/5/7），并尽量分布在不同物理机/机柜，避免单点失效导致同时失联。
- 保证稳定、低延迟、充足带宽与一致的MTU/交换机/路由配置；启用多路径/冗余网络，减少链路抖动与瞬时中断。
- 对关键业务队列启用镜像队列（quorum queue 优先），并合理设置镜像副本数，避免单分区导致的数据不可用或脑裂加剧。
二 内核与系统参数优化（CentOS）
- 开启并优化 TCP keepalive，更快发现死连接（示例为 sysctl 配置，需按环境调优）：
- net.ipv4.tcp_keepalive_time = 600
- net.ipv4.tcp_keepalive_intvl = 15
- net.ipv4.tcp_keepalive_probes = 5
- 适度增大 ARP 缓存与邻居表，减少短暂网络抖动导致的邻居震荡：
- net.ipv4.neigh.default.gc_thresh1 = 2048
- net.ipv4.neigh.default.gc_thresh2 = 4096
- net.ipv4.neigh.default.gc_thresh3 = 8192
- 启用 RPF 严格模式与合理的 conntrack 超时，减少异常流量干扰；为 RabbitMQ 节点设置稳定的主机名与 DNS/hosts 解析，避免节点名漂移。
- 使用 systemd 为 rabbitmq-server 设置Restart=on-failure，减少异常退出后的自愈等待时间；为关键链路配置告警与旁路（如 BGP/VRRP/双上联）。
三 RabbitMQ 关键配置与运维策略
- 合理设置 net_ticktime（默认 60 秒）：这是判定节点“失联”的基准，过小会误判，过大则分区发现延迟。仅在明确网络质量较差时再适度调大，并充分测试。
- 选择分区处理策略（在 /etc/rabbitmq/rabbitmq.conf 中配置，示例为经典配置格式）：
- ignore：默认，不做自动处理，适合网络极可靠环境。
- pause_minority：节点自判是否为少数派，若是则停止应用（类似 stop_app），网络恢复后自动启动；适合奇数节点集群，优先保证 CP。
- autoheal：分区恢复后，选择客户端连接数最多的分区为“胜者”，重启其他分区节点；更偏向服务连续性。
- pause_if_all_down：当与指定节点列表均不可达时自停，可配合 ignore/autoheal 决定后续动作；适合跨机房“多数派仲裁”场景。
- 示例配置（classic 配置格式，路径 /etc/rabbitmq/rabbitmq.config）：
- [
{rabbit, [
{tcp_listeners, [5672]},
{cluster_partition_handling, pause_minority},
{net_ticktime, 60}
]}
]
- 变更与演练：
- 修改分区策略后需按顺序重启各节点使其生效；严禁使用 kill -9，优先使用 rabbitmqctl stop_app / start_app 进行优雅操作。
- 定期做分区演练（如临时丢弃节点间通信端口 25672 的流量），验证策略与恢复流程；演练后检查 partitions 是否为空并清理告警。
四 监控 告警与快速处置
- 监控与发现：
- 日志关键字：如 “Mnesia reports that this RabbitMQ cluster has experienced a network partition”“net_tick_timeout”。
- 管理界面与 API：/api/nodes 中 partitions 字段非空即发生分区；告警联动恢复预案。
- 快速处置要点：
- 选择信任分区，对“非信任分区”节点执行 stop_app → start_app 后重新加入；必要时滚动重启信任分区以清除告警。
- 若采用 pause_minority，在分区期间少数派节点会自动停止应用，恢复连通后会自动拉起；如为 2 节点或可能出现 2v2/3v3 等对称分区，谨慎评估策略副作用。
