高性能四层调度集群应采用DR模式，结合wlc算法与动态健康检查，通过IPVS统计验证负载均衡效果。
构建高性能四层调度集群，核心在于发挥 LVS 的内核级转发能力，避开七层解析开销，同时让调度逻辑贴合真实业务负载特征。这不是堆硬件或盲目换算法，而是围绕“流量特征—后端能力—健康状态”三者做闭环适配。
选对模式：DR 模式是性能最优解
四层集群的吞吐上限，首先卡在数据路径上。NAT 模式所有流量双向经过调度器，天然存在单点瓶颈；TUN 模式引入隧道封装开销；而 DR（Direct Routing）模式只在入向请求时由调度器分发，响应直接从真实服务器返回客户端，绕过调度器，CPU 和带宽利用率都最低。
使用 DR 模式需满足两个硬条件：
- 调度器与所有真实服务器必须在同一物理/二层网络（同网段）
- 真实服务器需抑制 ARP 响应 VIP，避免地址冲突：设置 arp_ignore=1 和 arp_announce=2，并在 lo 接口绑定 VIP（掩码为 255.255.255.255）
配准算法：wlc 是默认起点，不是终点
Keepalived 中通过 lb_algo wlc 配置加权最少连接算法，它综合当前活跃连接数与节点权重计算分发倾向，公式为 (active_conn × 256 + inactive_conn) / weight，比纯轮询更适应长连接、响应不均的场景（如 MySQL、Redis、WebSocket 服务）。
但 wlc 效果依赖两点：
- 权重要反映真实能力：不能仅按 CPU 核数设 weight=8/4/2，应结合压测结果或历史负载（如某台 Redis 平均响应延迟比其他高 30%，weight 可设为 6 而非 10）
- 连接数统计要准确：确保 IPVS 内核模块正常工作，避免因 realserver 状态异常（如未配置健康检查）导致连接数滞留
活用健康检查：让调度真正“动态”
静态配置再合理，也扛不住节点突发抖动。Keepalived 的 TCP_CHECK 或 HTTP_GET 不只是“通/不通”的开关，它是调度决策的实时输入源：
- 连续失败 retry 3 次后，IPVS 自动将该 realserver 标记为 Inactive，wlc 算法立即剔除其参与计算
- 恢复后自动 re-activate，无需人工干预，wlc 会基于最新连接数重新摊平流量
- 支持运行时 动态调权：例如监控发现某台应用服务器 CPU > 90%，可通过脚本临时执行 ipvsadm -e -t VIP:PORT -r RIP:PORT -w 5，降低其分发比例，等负载回落再调回
验证不是走形式：看 stats，别只看规则
配置写完不等于生效，生效不等于高效。关键要看 IPVS 内核实际调度行为：
- 查规则和统计：ipvsadm -ln --stats，观察各 realserver 的 Conns（连接数） 和 PPS（包处理速率） 是否趋近均衡
- 查实时连接分布：ipvsadm -lnc，确认活跃连接是否按预期分散，而非集中在一两台
- 对比调度器与后端负载：若 LVS CPU
