Skip to main content
☘️ Septvean's Documents
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
  1. Documents
  2. /
  3. Operations
  4. /
  5. LVS
  6. /
  7. LVS 核心概念

LVS 核心概念

一、LVS 到底解决什么问题？

一句话：

LVS 解决的是「大量并发 TCP/UDP 连接如何高性能分发到多台后端服务器」的问题。

它的关注点只有一个：

连接怎么转发得最快、最稳定。

所以 LVS 的设计目标是：

  • 不解析应用层
  • 不关心 HTTP / URL / Cookie
  • 不处理业务逻辑
  • 只做 四层转发

二、LVS 在网络栈中的位置（非常关键）

LVS 工作在 Linux 内核网络栈的四层（Transport Layer）：

应用层   (HTTP / HTTPS / RPC)
--------------------------------
传输层   (TCP / UDP)   <- LVS 在这里
--------------------------------
网络层   (IP)
--------------------------------
链路层   (Ethernet)

对比：

  • LVS：四层（TCP/UDP）
  • Nginx / HAProxy：七层（HTTP）

这决定了 LVS 的一切特性。

三、LVS 的核心组成（3 个角色）

LVS 不是一台机器，而是一个逻辑集群。

1️⃣ Director（调度器）

  • 对外暴露 VIP
  • 接收客户端请求
  • 根据调度算法选择 RS
  • 转发数据包

Director 只做调度，不做业务。

2️⃣ VIP（Virtual IP）

  • 对外统一访问入口
  • 漂移在不同 Director 之间
  • 对客户端来说：永远不变

VIP 是 LVS 的"门面"。

3️⃣ RS（Real Server）

  • 真正处理业务请求
  • Web / API / DB / TCP 服务
  • 对 LVS 来说是"资源池"

四、LVS 的工作抽象模型

可以把 LVS 理解成：

客户端
   ↓
VIP（虚拟服务）
   ↓
调度算法
   ↓
Real Server（真实服务）

LVS 只关心：

  • 这个连接属于哪个虚拟服务？
  • 当前该选哪个 RS？

五、LVS 的「虚拟服务」是什么？

这是一个非常核心但容易忽略的概念。

在 LVS 里：

VIP + PORT + PROTOCOL = 一个虚拟服务

例如：

  • 10.0.0.10:80/TCP
  • 10.0.0.10:443/TCP
  • 10.0.0.10:53/UDP

每一个虚拟服务：

  • 独立调度算法
  • 独立 RS 列表
  • 独立权重和健康状态

六、LVS 为什么性能极高？（底层原因）

1️⃣ 完全在内核态

  • 无用户态 / 内核态切换
  • 无进程上下文切换

2️⃣ 不解析应用协议

  • 不拆 HTTP
  • 不解析 Header
  • 不做字符串处理

3️⃣ 数据结构极简

  • hash table + 链表
  • O(1) 查找

4️⃣ 可选"无回包路径"

  • DR / TUN 模式中
  • 响应流量不经过 Director

👉 所以 LVS 的瓶颈往往是网卡，而不是 CPU。

七、LVS 三种转发模式（理论视角）

1️⃣ NAT 模式（改地址） 

Client -> Director -> RS
Client <- Director <- RS
  • Director 是流量瓶颈
  • 简单但不适合大流量

2️⃣ DR 模式（直接路由） 

Client -> Director -> RS
Client <-──────────── RS
  • Director 只收请求
  • RS 直接回包
  • 性能最强

关键理论点：

请求和响应路径是不同的

3️⃣ TUN 模式（IP 隧道） 

Client -> Director -> (IPIP) -> RS
Client <-────────────────────── RS
  • 请求封装转发
  • 响应直返客户端
  • 适合跨网络

八、LVS 与 ARP 的关系（DR 模式本质）

在 DR 模式中：

  • Director 和 RS 同时拥有 VIP
  • 但 只有 Director 能回答 ARP

否则会发生：

客户端 -> 直接访问 RS（绕过 LVS）

所以本质要求是：

RS 必须"拥有 VIP，但不能对外宣称 VIP"

这就是关闭 ARP 的理论原因。

九、调度算法的本质（不是轮询那么简单）

调度算法解决的是：

“下一个连接该分给谁？”

LVS 的算法本质分两类：

1️⃣ 静态算法

  • 不关心当前负载
  • 只按规则分发

例如：

  • RR / WRR
  • SH（源 IP hash）

2️⃣ 动态算法

  • 关注 RS 当前状态
  • 更智能

例如：

  • LC / WLC
  • SED / NQ

核心认知：

LVS 的 “连接数” ≠ QPS，是 TCP 连接，而不是 HTTP 请求。

十、LVS 的连接模型（非常重要）

LVS 是 面向连接的负载均衡：

  • 一个 TCP 连接建立后
  • 整个生命周期都绑定到同一个 RS
  • 后续数据包不会重新调度

这保证了：

  • TCP 状态完整
  • 应用层无需感知 LVS

十一、Session 粘滞的理论基础

LVS 本身是四层，不理解 Session，但可以通过：

  1. 源地址 hash
  2. 连接持久化时间

来保证：

同一个客户端 -> 同一个 RS

这是传输层级别的"伪会话保持"。

十二、Keepalived 在 LVS 理论中的位置

Keepalived 不是 LVS 的一部分，而是：

  • VRRP -> 解决 VIP 高可用
  • 健康检查 -> 决定 RS 是否可用
  • 自动维护 LVS 内核规则

理论关系：

Keepalived 负责"谁对外"
LVS 负责"流量怎么分"

十三、LVS 的高可用本质

LVS 本身不具备 HA，需要：

  • 两台 Director
  • 一个 VIP
  • VRRP 协议

最终目标：

VIP 永远存在，但 Director 可以随时更换

十四、LVS 的适用与不适用场景（理论判断）

适合：

  • 高并发 TCP / UDP
  • Web / API 前置
  • Redis / MySQL / MQ
  • DNS / 游戏 / 推流

不适合：

  • 基于 URL / Header 路由
  • SSL 卸载
  • 复杂七层逻辑
  • 微服务网关（单独用）

十五、总结

LVS 是一个以内核为核心、以连接为单位、以性能为第一目标的四层负载均衡系统。