LVS调度算法通过Keepalived的lb_algo指令配置并交由IPVS内核模块执行，wlc（加权最少连接）为默认推荐算法，适用于大多数Web/MySQL/Redis等四层代理场景，需结合健康检查与权重动态调整实现高效分发。
调优 Keepalived 中的 lvs_sched（即 LVS 调度算法）能显著提升四层集群在高并发、不均衡后端能力场景下的请求分发效率。关键不在“换算法”，而在于匹配业务流量特征与后端服务器真实负载能力。
理解 lvs_sched 的作用位置
LVS 调度算法由内核模块 IPVS 执行，Keepalived 本身不计算调度逻辑，而是通过配置文件中的 lb_algo 指令将算法写入 IPVS 规则。例如：
virtual_server 192.168.1.254 80 {
lb_algo wlc
...
}
该配置最终会触发 ipvsadm -A -t 192.168.1.254:80 -s wlc 命令生效。算法生效前提是后端节点健康、网络可达、LVS 模式（NAT/DR/TUN）已正确启用。
主流调度算法适用场景与调优建议
Keepalived 支持的常用算法（通过 lb_algo 设置）有：
• rr（轮询）：适合后端性能完全一致、长连接少、请求轻量的场景，如静态资源分发。
• wrr（加权轮询）：给不同规格服务器分配不同权重（如 10/8/6），需人工预估并定期校准，适用于异构硬件环境。
• lc（最少连接）：仅看当前活跃连接数，对突发短连接友好，但易忽略响应时长差异。
• wlc（加权最少连接）：默认推荐，综合连接数与权重，适合大多数 Web/MySQL/Redis 四层代理场景。
• lblc（局部性最少连接）：带会话保持倾向，适合读多写少且客户端 IP 相对固定的业务（如内部管理后台）。
不建议使用：
• dh（目标哈希）和 sh（源哈希）：强绑定 IP，容易导致单节点过载，且无法自动规避故障节点。
• sed（最短期望延迟）和 nq（从不排队）：依赖精确响应时间反馈，在四层无应用层反馈机制下实际效果不稳定。
结合健康检查做动态适配
单纯设置算法不够，必须让调度行为随节点状态实时变化。Keepalived 的 TCP_CHECK 或 HTTP_GET 检查结果会直接影响 IPVS 中 realserver 的可用状态：
• 若某节点连续失败 3 次（retry 3），IPVS 自动将其标记为 Inactive，不再参与任何调度；
• 恢复后自动重新加入，wlc 算法会立即基于新连接数重新平衡；
• 可配合 weight 动态调整：例如发现某台 Redis 实例 CPU 持续 >85%，可临时将其 weight 从 10 降为 5，wlc 会自然减少分发比例。
验证与监控要点
调优后必须观测真实效果，而非仅看配置是否生效：
• 查看当前调度规则：ipvsadm -ln --stats，关注各 realserver 的 ActiveConn 和 InActConn 是否趋于均衡；
• 对比不同算法下后端平均响应延迟（如用 curl -w "@format.txt" -o /dev/null -s http://vip/）；
• 检查 VIP 流量是否出现单点打满：用 ss -ant | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head 观察客户端 IP 分布；
• 日志中留意 Keepalived 是否频繁触发 Entering MASTER STATE 或 Real server down，这可能暴露算法与健康检查节奏不匹配的问题。
