LVS 是Linux 虚拟服务器的简称，由章文嵩博士开发，是基于 Linux 内核的开源负载均衡器，通过 IP 层和传输层实现服务器集群的负载均衡，能将前端请求分发到后端多台真实服务器（RS），提升服务的并发处理能力和高可用性，广泛应用于高并发的 Web、数据库等服务集群场景。
LVS 的核心优势是性能高 （基于内核态处理，无用户态开销）、稳定性强 （Linux 内核原生支持）、配置灵活（支持多种工作模式和调度算法），且支持 TCP/UDP 协议的服务，可配合 Keepalived 实现主备切换，解决单点故障问题。
一、LVS 核心工作模式
VS 的工作模式核心差异在于数据包的转发方式 、与后端 RS 的网络拓扑 和IP 地址的使用方式，主流有 4 种模式，其中 NAT、DR 是生产环境最常用的模式，TUN 模式适用于跨机房场景，FULLNAT 为解决 NAT 的部分缺陷设计。
| 工作模式 | 核心转发原理 | 网络拓扑要求 |
|---|---|---|
| NAT 模式 | 前端负载均衡器（Director）作为请求的入口和响应的出口，对请求包做目标 IP 转换 （将 VIP 转为 RS 的 IP），对响应包做源 IP 转换（将 RS 的 IP 转为 VIP），所有数据包均经过 Director | Director 与 RS 必须在同一内网，RS 的网关必须指向 Director 的内网 IP |
| DR 模式 | 利用数据链路层的 MAC 地址转发 ，Director 仅将请求包的目标 MAC 地址改为目标 RS 的 MAC 地址，IP 地址（VIP）不变，响应包由 RS 直接发送给客户端（无需经过 Director） | Director 与 RS 必须在同一二层网络（同一交换机 / 同一 VLAN），禁止二层隔离 |
| TUN 模式 | Director 将请求包封装在新的 IP 包中，通过IP 隧道转发给 RS，RS 接收到隧道包后解封装，处理请求后直接将响应包发送给客户端（VIP 不变，无需经过 Director） | Director 与 RS 可跨不同网段 / 不同机房，网络需支持 IP 隧道（GRE 协议） |
| FULLNAT 模式 | 结合源 NAT 和目标 NAT，对请求包同时做 ** 源 IP（客户端 IP→Director 内网 IP）和目标 IP（VIP→RS 内网 IP）** 转换，响应包反向转换，Director 与 RS 无需在同一内网，RS 网关也无需指向 Director | Director 与 RS 可在不同内网，无二层 / 三层拓扑限制 |
模式核心要点
- DR/TUN 模式的核心优化：响应包不经过 Director，避免了 NAT 模式的带宽瓶颈，因此并发能力远高于 NAT；
- VIP（Virtual IP）：对外提供服务的虚拟 IP，是客户端访问的入口；
- DIP（Director IP）：负载均衡器的内网 IP，用于与后端 RS 通信；
- RIP（Real Server IP）：后端真实服务器的 IP。
二、LVS 核心调度算法
LVS 的调度算法分为静态调度算法 和动态调度算法两类：
- 静态算法 ：仅根据固定规则分发请求，不考虑后端 RS 的实际负载（如连接数、CPU / 内存使用率），算法简单、效率高；
- 动态算法 ：根据后端 RS 的实时负载状态分发请求，能更合理地利用服务器资源，避免单台 RS 过载，适用于服务器配置不同或负载波动大的场景。
| 算法分类 | 调度算法名称 | 英文简称 | 核心规则 | 优缺点 | 适用场景 |
|---|---|---|---|---|---|
| 静态调度算法 | 轮询 | RR | 将请求按顺序依次分发到每台 RS，每台 RS 的请求数基本均衡 | 优点：算法最简单，无额外开销；缺点：不考虑 RS 的性能和负载，配置不同的 RS 会导致资源浪费 | 后端 RS配置完全相同、负载均匀的场景，如同配置的 Web 集群 |
| 静态调度算法 | 加权轮询 | WRR | 为每台 RS 设置权重（weight），权重越高，分配到的请求数越多（请求数与权重成正比） | 优点：支持 RS 配置差异化，合理利用资源；缺点：不考虑 RS 实时负载 | 后端 RS配置不同（如 CPU / 内存有差异）、负载相对稳定的场景 |
| 静态调度算法 | 源地址哈希 | SH | 根据客户端的源 IP 地址 做哈希计算，将同一客户端的所有请求分发到同一台 RS | 优点：实现会话粘滞（会话保持），无需额外会话存储；缺点：若某一 IP 段的客户端多，会导致对应 RS 过载，哈希结果固定，扩展性差 | 对会话保持要求高的场景，如电商购物车、后台管理系统（需注意负载均衡） |
| 静态调度算法 | 目标地址哈希 | DH | 根据请求的目标 IP 地址做哈希计算，将同一目标 IP 的请求分发到同一台 RS | 优点：适合缓存服务，提升缓存命中率；缺点：目标 IP 集中时会导致 RS 过载 | 缓存类服务，如 DNS、CDN、Memcached 集群 |
| 动态调度算法 | 最少连接 | LC | 实时统计每台 RS 的当前活跃连接数 ，将新请求分发到连接数最少的 RS | 优点：根据实时负载分发，避免过载；缺点：未考虑 RS 的性能差异，配置高的 RS 可能被低估 | 后端 RS 配置相近、负载波动大的场景，如高并发 Web、API 服务 |
| 动态调度算法 | 加权最少连接 | WLC | 在 LC 基础上增加权重 ，计算公式：(当前连接数/权重)，将请求分发到计算结果最小的 RS |
优点：兼顾 RS 的性能和实时负载，最贴合生产实际；缺点：算法略复杂，有轻微计算开销 | 生产环境最常用，适用于绝大多数场景（RS 配置不同、负载波动大） |
| 动态调度算法 | 最少期望连接 | LBLCR | 对 WLC 的优化，引入期望连接数概念，考虑 RS 的连接数增长趋势，优先分发到负载增长最慢的 RS | 优点：负载均衡更精准，适合突发流量场景；缺点：计算开销略高于 WLC | 突发流量多、负载波动剧烈的场景，如秒杀、直播服务 |
| 动态调度算法 | 基于局部性的最少连接 | LBL | 结合 SH 和 LC，对同一客户端的请求，若对应 RS 有空闲连接则分发到该 RS，否则按 LC 分发 | 优点：兼顾会话粘滞和负载均衡；缺点：配置稍复杂 | 既需要会话保持，又要求负载均衡的场景，如电商、社交平台 |
| 动态调度算法 | 最快响应时间 | RTO | 统计每台 RS 的活跃连接数 和平均响应时间 ，计算公式：(活跃连接数/权重)+平均响应时间，分发到计算结果最小的 RS |
优点：优先选择响应最快的 RS，提升用户体验；缺点：需统计响应时间，开销较高 | 对响应速度要求高的场景，如低延迟的 API、金融交易服务 |
| 动态调度算法 | 加权源地址哈希 | WSH | 在 SH 基础上增加权重，同一客户端的请求优先分发到权重高且已分配的 RS，实现会话粘滞的同时兼顾 RS 性能 | 优点：解决 SH 的负载不均问题；缺点：哈希计算略复杂 | 需会话保持且 RS 配置不同的场景 |
调度算法核心要点
- 生产环境首选 ：加权最少连接（WLC） 是最通用的算法，兼顾性能和负载均衡，适配 90% 以上的业务场景；
- 会话保持需求 ：优先选择源地址哈希（SH） 或加权源地址哈希（WSH），无需额外中间件（如 Redis）存储会话，性能更高；
- 缓存服务优化 ：目标地址哈希（DH） 能提升缓存命中率，减少后端存储的访问压力；
- 突发流量场景 ：最少期望连接（LBLCR） 能更好地应对流量波动，避免单台 RS 被突发请求打满。
三、LVS 的核心组件
LVS 的实现依赖 Linux 内核的ip_vs 模块和用户态的ipvsadm工具：
- ip_vs ：Linux 内核的核心模块，负责处理数据包的转发、调度，是 LVS 的核心，需通过
modprobe ip_vs加载； - ipvsadm：LVS 的用户态配置工具，用于创建 / 删除虚拟服务、添加 / 删除后端 RS、配置调度算法和工作模式等，所有 LVS 的配置均通过该工具完成。
四、LVS 的典型部署架构
生产环境中，LVS 通常与Keepalived 和Nginx/Apache 配合，形成 "LVS+Keepalived+Nginx" 的三层负载均衡架构：
- 第一层（LVS）：实现四层（TCP/UDP）负载均衡，负责分发大流量的 TCP 请求，解决 Nginx 的单机并发瓶颈；
- 第二层（Keepalived）：为 LVS 提供主备切换，监控 LVS 的状态，当主 LVS 故障时自动切换到备 LVS，解决单点故障；
- 第三层（Nginx/Apache）：实现七层（HTTP/HTTPS）负载均衡，负责根据 URL、域名等分发请求，处理动静分离、SSL 解密等业务逻辑。