lvs突破调度瓶颈首选dr模式，通过仅修改mac地址实现请求分发、响应直回客户端，使调度器不承担双向流量；配合keepalived主备切换与健康检查，及按业务特征选择wrr/sh/lc等算法，协同提升扩展性。
LVS 解决大规模集群调度瓶颈，核心不在“加机器”，而在“减负担”——它把流量调度从应用层下移到内核网络层，并通过模式选择和架构设计，让调度器不成为数据通路的必经节点。
DR 模式是突破调度瓶颈的首选方案
DR（Direct Routing）让 LVS 调度器只处理请求分发，不参与响应返回。客户端请求到达 LVS 后，LVS 仅修改目标 MAC 地址，将包直接投递给真实服务器（Real Server）；而真实服务器用同一 VIP 直接回包给客户端，完全绕过 LVS。这样调度器不再承担双向流量，吞吐量不受带宽和连接数限制，单台 LVS 可轻松支撑上百台后端节点。
避免 NAT 模式带来的单点瓶颈
NAT 模式要求所有请求和响应都经过 LVS：请求时改目标 IP，响应时再改源 IP。这导致 LVS 成为全链路网关，CPU、内存、网卡带宽全部承压。并发一高，调度器自身先扛不住。实测中，NAT 模式下 LVS 往往在 2–3 万并发时即出现丢包或延迟飙升，而 DR 模式下同等硬件可承载 10 倍以上连接。
配合 Keepalived 实现无感故障切换
单台 LVS 仍是单点风险。生产环境必须部署主备调度器，用 Keepalived 管理 VIP 的漂移。主 LVS 故障时，VIP 秒级迁移到备用机，客户端几乎无感知。关键在于：Keepalived 不仅管 VIP，还主动探活后端 RS，自动剔除异常节点，确保调度始终落在健康服务器上。
调度算法要匹配业务特征，而非盲目轮询
- 短连接、静态资源多 → 用 WRR（加权轮询），按服务器性能分配权重
- 长连接、会话保持需求强 → 用
sh（源地址哈希），同一 IP 固定落到同一 RS - 后端负载差异大 → 用
lc（最少连接）或wlc（加权最少连接），实时感知压力
LVS 本身不解决后端服务瓶颈，它只是把“不该由它干的活”彻底甩掉。真正的扩展能力来自 DR 模式的分流逻辑 + Keepalived 的高可用兜底 + 合理的调度策略协同。
