apache本身不直接提供主备集群级故障转移能力,需结合keepalived实现vip漂移、mod_proxy_balancer分组降级或lvs四层调度三种生产验证路径,通过分层协同保障请求不丢、连接不断、服务不中断。
apache 本身不直接提供主备集群级的故障转移能力,但结合外围高可用组件或模块,可实现请求不丢、连接不断、服务不中断的平滑切换。关键不在于 apache 单体,而在于分层协同设计:负载层做健康探测与流量接管,应用层做优雅重启与连接保持,后端服务层保障状态一致性。
以下是最常用且经过生产验证的三种路径,按推荐度排序:
用 Keepalived + Apache 实现 VIP 漂移式主备切换
适合前端 Web 层双机热备,无共享存储、低延迟要求场景。
- 主节点正常时,VIP(如 192.168.1.100)绑定在其网卡上,所有流量由它处理
- Keepalived 通过 VRRP 协议持续检测主节点 Apache 进程和端口(如
curl -f http://localhost/health) - 一旦主节点宕机或 Apache 崩溃,Keepalived 在 1–3 秒内触发 VIP 漂移到备节点
- 备节点 Apache 已提前启动并监听相同端口,用户 TCP 连接会因 VIP 不变而自然重连(需客户端配合重试)
-
不丢请求的关键点:
- Apache 配置中启用
GracefulShutdownTimeout 30,确保正在处理的请求完成后再退出 - Keepalived 的
notify_master脚本中执行apachectl graceful,避免 abrupt stop - 客户端使用短超时 + 自动重试(如 HTTP 重试库、浏览器刷新机制)
- Apache 配置中启用
用 mod_proxy_balancer + lbset 实现多级后端容灾
适合 Apache 作为反向代理,后端是多个应用服务器(如 Tomcat、Node.js)的场景。
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
- 不是“主备 Apache”,而是 Apache 统一调度多个后端节点,并按优先级分组降级
- 配置
lbset=0为主集群(同城双节点),lbset=1为备集群(异地机房),全部失效才切lbset=2 - 必须启用健康检查:
status=+H+ProxySet failonstatus=503,Apache 才能准确标记节点为 down - 请求不会丢失,因为:
- 当前 lbset 内某节点失败,请求自动轮到同组其他节点(秒级无感)
- 整个 lbset=0 全挂,Apache 自动降级到 lbset=1,无需人工干预或 DNS 切换
- 所有切换发生在代理层,客户端无感知,连接维持在 Apache 和后端之间
用 Apache 作为 LVS Real Server,由 LVS Director 做主备调度
适合超大流量、严格 SLA 场景(如电商大促)。
- LVS(IPVS)作为四层负载均衡器,部署双机(主+备),运行 Keepalived 实现 VIP 漂移
- Apache 仅作为真实服务器(Real Server),专注处理 HTTP 请求,不参与决策
- LVS 支持
--tcp-check或--http-check探测 Apache 健康状态 - 当某台 Apache 异常,LVS 立即剔除其 RIP,新连接不再发往该节点;已有连接继续处理直至自然结束
-
零丢包前提:
- Apache 开启
KeepAlive On+MaxKeepAliveRequests 100,复用连接减少新建开销 - LVS 使用 DR 模式(不改 IP,仅改 MAC),转发延迟低于 100μs
- 后端服务支持 session 复制或存入 Redis,避免单点状态丢失
- Apache 开启
真正“不丢任何请求”的核心逻辑是:
- 前置组件(Keepalived/LVS/mod_proxy)负责快速发现故障并隔离流量
- Apache 自身通过
graceful、graceful-stop、KeepAlive等机制保障已有连接走完生命周期 - 应用层配合健康接口、幂等设计、重试机制,容忍短暂网络抖动
不需要追求“绝对零中断”,而是让中断窗口压缩在毫秒到秒级,并确保业务语义上无数据丢失。









