Keepalived 本身不直接实现多节点负载均衡，而是通过与 LVS 协同，在单 VIP 下支撑多台真实服务器达成生产级负载均衡；其核心是主备调度器 + 多 RS 的 DR 模式，Keepalived 管 VIP 高可用，LVS 负责流量分发。
Keepalived 本身不直接实现“多节点负载均衡集群”意义上的横向扩展式负载分发，它本质是主备高可用架构，但可以通过组合 LVS（IPVS）+ 多台真实服务器（Real Server），在单个 VIP 下支撑多节点后端服务，从而达成生产级的多节点负载均衡效果。关键在于：Keepalived 负责 VIP 高可用，LVS 负责流量分发，两者协同构成完整集群。
主备调度器 + 多台真实服务器（标准 DR 模式）
这是最常见、最推荐的多节点负载均衡部署方式。Keepalived 只部署在两台调度器（Director）上（一主一备），它们共享同一个 VIP；后端可挂载任意数量的真实服务器（RS），所有 RS 同时对外提供服务：
- 前端用户只访问 VIP（如 192.168.1.100），完全感知不到调度器主备切换
- Master 调度器通过 IPVS 规则，按算法（rr、wrr、lc 等）把请求分发给后端 3 台、5 台甚至几十台 RS
- Backup 调度器不转发流量，但实时同步 IPVS 规则，并监听心跳——一旦 Master 故障，秒级接管 VIP 和转发能力
- 所有 RS 使用 DR 模式：响应直接返回客户端，不经过调度器，吞吐更高、延更低
Keepalived 配置中定义多节点后端池
在 virtual_server 块中明确列出全部真实服务器，并设置权重与健康检查，这才是“多节点”的实际落点：
- 每个
real_server对应一台后端节点（如 192.168.1.10、192.168.1.11、192.168.1.12） - 支持
weight参数，可按性能差异分配流量（例如高性能机器设 weight 3，普通机器设 1） - 启用
HTTP_GET或TCP_CHECK健康检查，自动剔除宕机节点，恢复后自动加回 - 调度算法选
rr（轮询）、wrr（加权轮询）或lc（最少连接），直接影响多节点间负载是否均衡
避免误区：Keepalived 不等于多活负载均衡器集群
Keepalived 的调度器节点之间是主备关系，不是多活分担关系。也就是说：
- 不能配置三台 Keepalived 节点同时作为 Master 并分摊 VIP 流量（VRRP 协议不支持）
- 若需真正多活（如多个 VIP 或多组 VRRP 实例），需拆分为多个独立 VRRP 组，每组仍是一主一备
- 横向扩展能力体现在后端 RS 数量上，而非 Keepalived 节点数量上；调度器扩容建议用 DNS 轮询或前置 F5/云 LB，而非堆 Keepalived 节点
增强可用性：结合脚本实现服务级故障联动
仅靠网络层心跳不够可靠，建议让 Keepalived 检测关键业务进程状态，触发更精准的主备切换：
- 编写检测脚本（如检查 Nginx 是否存活、LVS 规则是否生效）
- 在
vrrp_script中调用该脚本，并绑定到vrrp_instance - 当 Master 上 Nginx 崩溃，即使机器在线，也会主动降优先级，促使 Backup 接管 VIP
- 这样能确保“服务可用”才是真正可用，而非仅“机器开机”
