keepalived 仅支持四层高可用，不提供七层负载均衡能力；其核心职责是保障 lvs 调度器的 vip 漂移与主备切换，七层路由（如 url、header、ssl）必须由 nginx/haproxy 承担，大规模场景需分层部署并横向扩展。
Keepalived 本身不支持七层（应用层）负载均衡，它只负责四层调度器（如 LVS）的高可用和 VIP 漂移。所谓“四七层复合”，实际是分层部署：LVS（四层）做入口流量分发 + Nginx/HAProxy（七层）做内容路由，Keepalived 仅保障 LVS 调度器本身的高可用。超大规模场景下，不能靠单点 LVS+Keepalived 承担七层逻辑，必须解耦架构。
LVS 层只做纯四层转发，不碰七层逻辑
LVS 工作在内核态，仅基于 IP+端口做连接级转发（DR/NAT/TUN 模式），无法解析 HTTP 头、URL、Host、Cookie 等七层信息。强行让 LVS 做七层判断会破坏其高性能本质，也超出设计边界。Keepalived 的配置中 不包含任何 URL 匹配、Header 改写或 SSL 卸载能力，它的职责就是监控 LVS 进程、检测网卡状态、管理 VIP 和主备切换。
- 所有七层策略（如 /api → 后端服务A，/static → CDN，/admin → 鉴权集群）必须由后端的 Nginx 或 HAProxy 完成
- LVS 只需将 443/80 流量按轮询、加权最小连接等算法，均匀打到一组 Nginx 节点上
- 若需 TLS 终止，应在 Nginx 层统一处理，LVS 保持透传 TCP 连接即可
超大规模需分层部署+横向扩展
单组 LVS+Keepalived 主备对有吞吐瓶颈（通常受限于网卡带宽、连接跟踪表大小、ARP 响应延迟）。突破方法不是增强单点，而是分层水平伸缩：
- 接入层：用多组 LVS+Keepalived 集群，每组绑定不同 VIP 段（如 vip-01: 10.10.1.100，vip-02: 10.10.1.101），前端 DNS 或 Anycast 分流
- 七层层：每组 LVS 后挂载 10–50 台 Nginx 节点，Nginx 自身再做 upstream 健康检查、缓存、限流、WAF
- 真实服务层：Nginx 再将请求按 path/host 路由至不同业务集群（如用户中心、订单、支付），实现真正语义化分发
Keepalived 配置关键点（面向超大规模）
为支撑万级并发和快速故障收敛，Keepalived 配置需强化健壮性：
- 降低 advert_int 到 0.5 秒：加快主备检测速度（默认 1 秒），但需确保网络抖动不引发误切
- 启用 nopreempt + priority 差值 ≥ 50：避免脑裂，防止 backup 因短暂网络延迟抢主；恢复后不自动回切，减少抖动
- 添加 notify_master / notify_backup 脚本：主升备降时触发 ipvsadm 规则重载、清空 conntrack 表、上报监控事件
- 禁用 IPv6 VRRP（除非全栈支持）：避免因 IPv6 RA 或邻居发现异常导致 VIP 异常丢失
- interface 显式指定为业务网卡（如 eth0），而非 bond0 或 vlan 子接口：确保 ARP 响应走正确路径
替代方案建议：LVS+Keepalived 不是唯一路径
当节点规模超 200+、QPS 过百万时，可考虑更现代的组合：
- 用 BGP+ECMP 替代 VRRP：每个 LVS 节点宣告相同 VIP 的 /32 路由，由上游交换机 ECMP 分流，天然多活无单点
- 用 MetalLB（K8s 环境）或 FRR（裸机）替代 Keepalived：提供更细粒度的健康通告与 BGP 集成能力
- 用 DPDK 加速 LVS：绕过内核协议栈，提升单机吞吐至 20M+ PPS，适合超低延时金融场景
