Apache本身不引发脑裂,脑裂源于Keepalived/Pacemaker等HA组件的心跳失效或网络分区;解决关键在VIP唯一性、心跳可靠性、故障判定收敛性及资源互斥保障。

Apache 本身不是高可用集群软件,不直接涉及脑裂问题;但常被部署在基于 Keepalived、Pacemaker 或 ZooKeeper 等组件构建的高可用架构中。所谓“Apache 高可用架构中的脑裂”,实际是指承载 Apache Web 服务的 HA 环境(如 Keepalived + Apache 或 Pacemaker + Apache)因心跳失效、网络分区等原因,导致双节点同时接管 VIP 或服务资源,从而引发响应冲突、日志混乱甚至数据不一致。
明确架构角色:Apache 是被托管的服务,不是决策主体
Apache 进程无选举、无状态同步、不参与集群共识。它只是被 HA 软件调度的资源。是否发生脑裂,取决于底层集群管理器(如 Keepalived 的 VRRP 状态机,或 Pacemaker 的 CIB 决策引擎),而非 Apache 自身配置。
因此解决重点不在 Apache.conf,而在:
• VIP 绑定是否唯一
• 心跳链路是否可靠
• 故障判定逻辑是否收敛
• 资源抢占是否有互斥保障
针对 Keepalived + Apache 架构的实操防裂策略
这是最常见也最易出问题的轻量级组合。关键不是“让 Apache 不脑裂”,而是“不让 Keepalived 错误升主”:
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
-
禁用抢占 + 固化优先级:在备机配置中加入
nopreempt,主机 priority 设为 100,备机设为 90,避免网络抖动后备机抢主; -
改组播为单播心跳:绕过交换机组播转发缺陷,显式指定对端 IP,例如:
unicast_src_ip 192.168.1.10unicast_peer { 192.168.1.11 }; -
增加脚本健康检查权重:不只是检测 keepalived 进程存活,还要检查 Apache 是否真能响应 HTTP 请求,失败则自动降权(如
weight -5),使故障节点无法升主; -
防火墙放行协议号 112:VRRP 使用 IP 协议号 112(非端口),iptables 规则应为:
iptables -A INPUT -p 112 -j ACCEPT,云平台安全组需支持协议号放行。
升级到 Pacemaker + Corosync(推荐用于生产)
Keepalived 适合无状态服务漂移,但缺乏法定人数(quorum)和 fencing 支持,面对有状态依赖(如 Apache 后接本地会话文件、磁盘缓存)时风险高。Pacemaker 可从根本上规避脑裂:
-
启用法定人数校验:设置
no-quorum-policy=freeze或ignore,确保节点数不足半数时不执行任何资源操作; -
配置 STONITH 设备:即使没有物理 fence 设备,也可用
fence_virt(KVM)、fence_ipmilan(IPMI)或云厂商提供的 API fence(如阿里云fence_alicloud)强制隔离疑似异常节点; -
将 Apache 注册为集群资源:使用
apacheRA(Resource Agent),它内置启动检查、端口探测和优雅停止逻辑,比裸写 shell 脚本更健壮。
辅助验证与快速定位手段
不要等用户投诉才发觉脑裂。日常应建立交叉验证习惯:
- 定时执行
ip addr show | grep "inet.*192.168.1.100",两台机器不能同时显示该 VIP 处于 UP 状态; - 用
tcpdump -i eth0 ip proto 112抓包,确认 VRRP 报文持续双向收发; - 检查 Apache 日志时间戳与访问来源 IP,若同一秒内两个节点都记录了相同客户端请求,且返回不同内容,极可能已分流;
- 在负载均衡器(如 Nginx、HAProxy)后端加 health check,发现多节点同时 in-service 时触发告警。

















