LVS 负载均衡完全指南

想象一下你经营着一家大型连锁餐厅,顾客络绎不绝。如果只有一名服务员,根本忙不过来。这时候你需要一个"迎宾经理"站在门口,把顾客均匀地分配给多个服务员,这就是负载均衡的本质------LVS 就是 Linux 世界里的这位"迎宾经理"。


📑 目录

  1. [LVS 基本原理](#LVS 基本原理)
  2. 名词解释(命令与术语)
  3. [LVS 的四种工作模式](#LVS 的四种工作模式)
  4. [LVS 调度算法](#LVS 调度算法)
  5. [LVS 持久连接](#LVS 持久连接)
  6. [ipvsadm 命令详解](#ipvsadm 命令详解)
  7. [VIP 和 RIP 不在同一网段](#VIP 和 RIP 不在同一网段)
  8. [LVS 模式对比](#LVS 模式对比)
  9. 企业应用场景
  10. 实战建议
  11. 总结
  12. 官方文档与参考

🏗️ LVS 基本原理

什么是 LVS?

LVS (Linux Virtual Server) 是 Linux 虚拟服务器,它是一种高性能的负载均衡解决方案。LVS 的工作原理就像一个智能交通指挥员,站在网络路口,把进来的请求分发到后面多台真实服务器上。

官方/社区定义简述 (来源:linuxvirtualserver.orgIPVS):LVS 在 Linux 内核中实现传输层(四层)负载均衡 ,即 IP Virtual Server (ip_vs)。它在服务器集群前端充当负载均衡器,将基于 TCP/UDP 的请求转发到多台 Real Server,对外则呈现为单一虚拟服务与一个 IP(VIP) 。支持 LVS/NAT、LVS/DR、LVS/TUN 等转发方式及多种调度算法;管理工具为 ipvsadm

核心概念解析

概念 英文 解释 生活类比
VIP Virtual IP 虚拟 IP,对外的统一入口 餐厅的总机电话号码
RIP Real IP 真实服务器的 IP 地址 每个服务员的工号
Director Director LVS 负载均衡器 迎宾经理/指挥员
RS Real Server 真实提供服务的服务器 实际干活的服务员
ipvs IP Virtual Server Linux 内核的负载均衡模块 指挥员的工作手册

📖 名词解释(命令与术语)

以下对文档中出现的命令、参数、概念做简要解释,并配上生活例子与「为什么」,便于记忆与理解。

常用命令与参数

命令/参数 含义 说明 生活例子 为什么?
ipvsadm -A 添加虚拟服务 指定 VIP:Port + 调度算法,建立「对外服务」 像「开一个新窗口:只接待 80 号业务」 为什么先 -A 再 -a?先定义「服务入口」,再往这个入口下挂 Real Server
ipvsadm -a 添加真实服务器 在某个虚拟服务下挂一台 RS(-r RIP:Port) 像「给这个窗口分配一个服务员」 为什么 -r 要写端口?RS 上的服务端口可与 VIP 端口不同(如 VIP:80 → RIP:8080)
ipvsadm -L -n 列出规则(数字格式) 显示虚拟服务与 RS 列表,-n 不解析主机名 像「看当前排班表」 为什么用 -n?避免 DNS 反查拖慢,排障时 IP 更直观
ipvsadm -L -n --rate 带速率查看 显示每秒连接数、包数等 像「看每个窗口的接待量统计」 为什么看 rate?判断是否均衡、哪台 RS 压力大
ipvsadm -C 清空规则 删除所有虚拟服务与 RS 像「清空排班表」 为什么慎用?生产上误执行会立刻断流,一般先 -D 删单个服务
-t / -u / -f 协议类型 -t TCP,-u UDP,-f 防火墙标记 像「电话业务、传真业务、VIP 套餐号」 为什么有 -f?多端口共用一个持久连接(如 80+443)时用 iptables 打 mark,LVS 按 mark 转发
-g / -i / -m 工作模式 -g DR,-i TUN,-m NAT 见下文「四种工作模式」 为什么 DR 常用?响应直连客户端,Director 压力小、性能高
-s 调度算法 rr/wrr/lc/wlc/sed/nq/sh/dh 等 像「派单规则:轮询、谁闲给谁」 为什么 Web 常用 wlc?兼顾权重与当前连接数,适应长短连接混合
-p 秒数 持久连接 同一客户端在指定秒数内打到同一 RS 像「老顾客指定服务员」 为什么默认 600?会话保持与连接复用的折中;太长 RS 下线后仍可能被分到已死的 RS

核心概念

名词 含义 生活例子 为什么?
VIP Virtual IP,对外统一入口 餐厅总机号 为什么用 VIP?客户端只记一个地址,后端扩缩容、故障切换对客户端透明
RIP Real Server 的 IP 每个服务员的工号 为什么通常内网?RS 不需公网 IP,节省且安全;DR 下 RS 与 Director 多在同网段
DIP Director 的 IP(与 RS 通信的接口) 前台的内线号 为什么 NAT 下 RS 网关要指 DIP?响应要回到 Director 做 SNAT 再回客户端
CIP Client IP,客户端 IP 顾客的来电显示 为什么 DR 下 RS 能看到 CIP?DR 只改 MAC 不改 IP,RS 可直接回包给客户端
PPC 持久单端口 同一服务的会话保持 为什么叫 Port?按「VIP:Port」维度持久,不同端口可打到不同 RS
PCC 持久整客户端 该客户端所有端口都到同一 RS 为什么用 VIP:0?0 表示「任意端口」,等价于按客户端维度绑定 RS
PNFM 防火墙标记持久 多端口共用一个 mark,一起持久 为什么 80+443 要一起?HTTP 跳 HTTPS 时若换 RS 可能丢 cookie 或证书会话

调度算法对比(为什么选哪种?)

算法 适用场景 为什么?
RR/WRR 连接长短相近、无状态 实现简单、公平;WRR 可给性能好的 RS 更大权重
LC/WLC 长连接、连接数差异大 连接多的 RS 少分新连接,避免雪崩;WLC 再结合权重
SH 同一源 IP 希望固定 RS 缓存亲和、会话固定;源不变则 RS 不变
DH 同一目标 IP 固定 RS(少用) 目标固定时用于缓存场景

🔄 LVS 的四种工作模式

1️⃣ NAT 模式(网络地址转换)

请求 VIP
修改目标IP为RIP
修改目标IP为RIP
响应给Director
响应给Director
修改源IP为VIP
👤 客户端
⚖️ Director
🖥️ RS1
🖥️ RS2

为什么 NAT 下 RS 网关必须指 Director? 请求时 Director 把目标改成了 RIP,所以 RS 收到包;响应时 RS 要先把包发回 Director,Director 才能把源改回 VIP 再回给客户端。若 RS 网关指别处,回包就不会经过 Director,客户端收不到或收到错误源 IP。

NAT 模式特点:

  • 请求和响应都要经过 Director
  • RS 的网关必须指向 Director 的 DIP
  • Director 容易成为瓶颈

生活类比:就像顾客通过前台点餐,前台把单子传给厨房,厨房做好后再由前台端给顾客。前台很累!

2️⃣ DR 模式(直接路由)

请求 VIP
修改MAC地址
修改MAC地址
直接响应
直接响应
👤 客户端
⚖️ Director
🖥️ RS1

配置VIP
🖥️ RS2

配置VIP

为什么 DR 下 RS 要在 lo 上配 VIP 且抑制 ARP? 响应包源 IP 是 VIP,若 RS 不在 lo 上绑 VIP,出包源会变成 RIP,客户端会拒收。绑在 lo 上并 arp_ignore/arp_announce 后,只有 Director 能对外响应 VIP 的 ARP,避免多台机器抢答 VIP 导致混乱。

DR 模式特点:

  • 请求经过 Director,响应直接返回客户端
  • RS 需要在 lo 接口配置 VIP(不响应 ARP)
  • 性能最好,最常用

生活类比:就像顾客在前台点餐,前台只负责指派服务员,服务员直接服务顾客,不需要经过前台。前台轻松多了!

3️⃣ TUN 模式(IP 隧道)

请求 VIP
📦 IP封装
📦 IP封装
解封装直接响应
解封装直接响应
👤 客户端
⚖️ Director
🖥️ RS1

隧道
🖥️ RS2

隧道

为什么 TUN 能跨网段? 请求包被 Director 封装成「新 IP 头 + 原包」,目标为新 IP 头的 RIP,可经路由到不同网段;RS 解封装后用原包里的 VIP 回给客户端,响应不经过 Director。

TUN 模式特点:

  • RS 和 Director 可以在不同网段
  • 需要支持 IP 隧道协议
  • 配置较复杂

生活类比:就像顾客通过外卖平台下单,平台把订单"打包"送到远处的餐厅,餐厅做好后直接快递给顾客。

4️⃣ FULLNAT 模式

请求 VIP
源→DIP 目标→RIP
源→DIP 目标→RIP
响应给Director
响应给Director
恢复源IP为VIP
👤 客户端
⚖️ Director
🖥️ RS1
🖥️ RS2

为什么 FULLNAT 下 RS 网关不用指 Director? 源和目标都被改了,RS 看到的源是 DIP、目标是本机 RIP,回包自然回给 DIP(Director);Director 再改回 VIP 还给客户端。RS 可放在任意路由可达处。

FULLNAT 模式特点:

  • 同时修改源 IP 和目标 IP
  • RS 网关不需要指向 Director
  • 需要额外模块支持

🎲 LVS 调度算法

静态调度算法

算法 原理 生活类比
RR (Round Robin) 轮询,依次分发 发牌员依次给每个人发牌
WRR (Weighted RR) 加权轮询,按权重分发 老员工多派单,新员工少派单
DH (Destination Hashing) 目标地址哈希,同一 IP 到同一 RS 同一顾客总是分配给同一服务员
SH (Source Hashing) 源地址哈希 同一顾客总是找固定的服务员

动态调度算法

算法 原理 生活类比
LC (Least Connection) 最少连接,分给连接数少的 哪个服务员手头活少就派给谁
WLC (Weighted LC) 加权最少连接 综合考虑权重和连接数
SED (Shortest Expect Delay) 最短预期延迟 估算哪个能最快响应
NQ (Never Queue) 永不排队,优先分配给空闲 RS 只要有人闲着就先派给他

🎲 LVS 调度算法
📌 静态算法
📊 动态算法
🔄 RR 轮询
⚖️ WRR 加权轮询
🎯 DH 目标哈希
📍 SH 源哈希
📉 LC 最少连接
⚖️ WLC 加权最少连接
⏱️ SED 最短预期延迟
✅ NQ 永不排队


📌 LVS 持久连接

为什么需要持久连接?

想象你在网购,结账时突然被分配到另一个服务器,购物车清空了!这就是会话保持问题。LVS 持久连接就是为了解决这个问题。
第一次访问
持久化
后续访问
👤 客户端访问
⚖️ LVS
🖥️ RS1
📝 持久连接模板

600秒

三种持久连接类型

类型 全称 说明 命令参数
PPC Persistent Port Connections 持久单个端口(服务) -p 默认 600 秒
PCC Persistent Client Connections 持久所有服务,同一客户端所有请求到同一 RS -p 120 + 持久粒度为 0
PNFM Persistent Net Filter Mark 通过防火墙标记实现多端口持久 iptables mark + -p

生活类比

  • PPC:你每次来餐厅,经理都记住你点的是"川菜",每次都把你分配给会做川菜的厨师
  • PCC:你只要来餐厅,经理记住你这个人,无论点什么菜都分配给固定的服务员
  • PNFM:你点了套餐(包含多个菜品),经理保证这些菜品都由同一服务员服务

配置示例

bash 复制代码
# PPC: 持久单个端口 600 秒
ipvsadm -A -t 192.168.1.100:80 -s wrr -p 600

# PCC: 持久客户端所有连接
ipvsadm -A -t 192.168.1.100:0 -s wrr -p 120

# PNFM: 使用防火墙标记
iptables -t mangle -A PREROUTING -d $VIP -p tcp --dport 80 -j MARK --set-mark 10
iptables -t mangle -A PREROUTING -d $VIP -p tcp --dport 443 -j MARK --set-mark 10
ipvsadm -A -f 10 -s wrr -p 300

端口姻亲 (Port Affinity)

端口姻亲是指多个不同端口之间的关联关系。比如 HTTPS (443) 和 HTTP (80) 需要保持会话一致性。

生活类比:就像你点了"夫妻套餐",虽然包含两个不同的菜品,但希望由同一个厨师来做,保证口味一致。


🛠️ ipvsadm 命令详解

ipvsadm 是 LVS 的管理工具,就像指挥员的操作面板。

命令格式

bash 复制代码
ipvsadm [选项] [命令]

核心命令

命令 说明 示例
-A 添加虚拟服务 ipvsadm -A -t 192.168.1.100:80
-D 删除虚拟服务 ipvsadm -D -t 192.168.1.100:80
-a 添加真实服务器 ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.10
-d 删除真实服务器 ipvsadm -d -t 192.168.1.100:80 -r 192.168.1.10
-E 编辑虚拟服务 ipvsadm -E -t 192.168.1.100:80 -s wlc
-e 编辑真实服务器 ipvsadm -e -t ... -r ... -w 3
-L 查看规则 ipvsadm -L -n
-C 清空规则 ipvsadm -C
-R 从文件恢复 ipvsadm -R < ipvs.rules
-S 保存规则到文件 ipvsadm -S > ipvs.rules

协议类型

参数 协议 说明
-t TCP TCP 协议服务
-u UDP UDP 协议服务
-f FIREWALL_MARK 防火墙标记服务

完整配置示例

bash 复制代码
# 1. 添加虚拟服务 (VIP:Port)
ipvsadm -A -t 192.168.1.100:80 -s wlc

# 2. 添加真实服务器
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.10:80 -g -w 1
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.11:80 -g -w 2
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.12:80 -g -w 3

# 3. 查看规则
ipvsadm -L -n

# 输出示例:
# TCP  192.168.1.100:80 wlc
#   -> 192.168.1.10:80             Route   1      0          0
#   -> 192.168.1.11:80             Route   2      0          0
#   -> 192.168.1.12:80             Route   3      0          0

# 4. 持久连接
ipvsadm -A -t 192.168.1.100:80 -s wrr -p 600

# 5. 保存规则
ipvsadm -S > /etc/sysconfig/ipvsadm

工作模式参数

参数 模式 说明
-g DR 直接路由模式(默认)
-i TUN 隧道模式
-m NAT NAT 模式

🌐 VIP 和 RIP 不在同一网段的实现

场景描述

有时候 VIP(公网 IP)和 RIP(内网 IP)不在同一网段,这就像你的餐厅总机电话是城市的,但实际厨房在郊区。

解决方案

访问 VIP
路由
内网路由
内网路由
👤 客户端

公网
⚖️ Director

公网+内网
🌐 Router
🖥️ RS1

内网
🖥️ RS2

内网

实现要点:

  1. Director 需要配置双网卡(公网 + 内网)
  2. 确保 Director 到内网 RS 的路由可达
  3. DR 模式下,RS 的 VIP 配置在 lo 接口,且设置 ARP 隐藏
bash 复制代码
# RS 上配置 VIP 到 lo 接口
ip addr add 192.168.1.100/32 dev lo:0

# 抑制 ARP 响应
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

生活类比:就像你在网上下单配送,前台(公网)接收订单后,通过内部配送系统把订单送到郊区厨房,做好后再送回前台发货。


📊 LVS 模式对比

TUN模式
DR模式
NAT模式
对比维度
🚀 性能
🌐 网络拓扑
🔧 配置复杂度
🖥️ RS要求
低 - 双向流量
简单 - RS网关指向Director
低 - 最简单
必须私有IP
高 - 响应直连
同一网段最佳
中 - 需配置ARP抑制
需配置VIP且抑制ARP
高 - 响应直连
可跨网段
高 - 需支持IP隧道
需支持隧道协议

特性 NAT DR TUN
性能 ⭐⭐ ⭐⭐⭐ ⭐⭐⭐
配置难度 简单 中等 复杂
网络要求 RS 网关指向 Director 最好同网段 可跨网段
RS 数量 受限于 Director 几乎无限 几乎无限
适用场景 小规模 中大规模 跨地域大规模

🏢 企业应用场景

LVS 在企业中常作为四层流量入口,承担高并发、高可用分流;与 Keepalived、Nginx、HAProxy 等组合成多层架构。以下为常见企业应用场景。

典型企业架构中的位置

后端
七层/业务层
入口层
用户侧
访问 VIP
👤 用户/客户端
🛡️ Keepalived

VIP 主备
⚖️ LVS Director

四层负载
🌐 Nginx/HAProxy

七层、SSL、路由
🖥️ 应用 1
🖥️ 应用 2

说明:用户只访问一个 VIP;Keepalived 保证该 VIP 在主 Director 上;LVS 把 TCP 流量分给多台 Nginx/HAProxy;七层再按域名、路径转发到具体应用。LVS 负责「接得住、分得匀」,七层负责「认得出、转得准」。

互联网 / 门户与电商

场景 LVS 的角色 常见搭配 说明
Web/HTTPS 入口 四层入口,将海量连接分到多台 Nginx/HAProxy LVS-DR + Keepalived + Nginx(SSL 终结、反向代理) 单机 Nginx 连接数、带宽有限,LVS 先做多机分担
大促/秒杀 同一 VIP 后挂大量 RS,WLC 或 WRR 分摊流量 DR 模式 + 持久连接(会话保持)+ 健康检查(Keepalived 或脚本) 保证高可用与会话不丢,必要时配合限流、降级
静态资源/CDN 回源 对静态资源集群做四层负载,或对源站做负载 LVS 将回源请求分到多台源站或缓存节点 简单、高性能,七层策略可在源站或 CDN 边缘做

游戏、视频与长连接

场景 LVS 的角色 说明
游戏服/长连接 四层负载,同一客户端长连固定到一台 RS(会话保持) 用 PCC 或 PPC + 较长持久时间,避免中途换服断线
视频/直播推流 多路 TCP/UDP 分流到多台推流节点或转码集群 LVS 按端口或 firewall mark 分流,后端做业务处理
IM/WebSocket 入口四层分担,配合七层做 WebSocket 路由与会话保持 四层先分散连接,七层再做协议与路由

内部服务与数据库

场景 LVS 的角色 说明
微服务/API 网关入口 对多台 API 网关或 BFF 做四层负载 内网 DR 即可,网关自身做路由、鉴权、限流
数据库读库负载 对多台只读从库做四层负载,应用连一个 VIP 写走主库,读走 LVS VIP,后端挂多个从库;注意持久连接避免同一会话跨库
缓存集群入口 对 Redis/Memcached 多实例做四层负载(少用) 更多直接用集群模式;若用 LVS 多为多实例代理、会话保持重要

金融、政企与高可用

场景 LVS 的角色 说明
双活/多活入口 多机房各有一套 LVS+Keepalived,DNS 或全局调度把用户指到不同 VIP LVS 负责机房内多机分担;跨机房由 DNS、GTM、或专有流量调度完成
合规与审计 四层只做转发,审计、防入侵在七层或独立设备 LVS 不解析内容,合规策略放在 Nginx/HAProxy 或 WAF 上
会话保持与合规 敏感业务要求同一用户固定到同一后端 使用 SH(源地址哈希)或持久连接(PCC/PPC),并配合后端会话复制或共享存储

选型小结(企业里怎么用 LVS)

需求 建议
高并发 Web 入口 LVS-DR + Keepalived + Nginx/HAProxy,LVS 做四层分担
需要 SSL、域名、路径路由 LVS 后挂 Nginx/HAProxy 做七层,LVS 不解析 HTTP
长连接、游戏、IM LVS + 持久连接(PCC 或 PPC),调度算法 WLC 或 WRR
读库、缓存等多后端 LVS 做单 VIP 多 RS,注意持久与健康检查
多机房、双活 每机房一套 LVS+Keepalived,跨机房用 DNS/GTM 或专有调度

💡 实战建议

选择合适的模式

  • 小规模内网环境:NAT 模式最简单
  • 中大规模同网段:DR 模式是首选
  • 跨地域部署:考虑 TUN 或 FULLNAT

调度算法选择

  • 一般 Web 服务:WLC(加权最少连接)
  • 需要会话保持:WLC + 持久连接
  • 静态资源:RR 或 WRR 即可
  • 特定用户绑定:SH(源地址哈希)

监控要点

bash 复制代码
# 查看 LVS 状态
ipvsadm -L -n --rate

# 查看连接数
ipvsadm -L -n --sort

# 持续监控
watch -n 1 'ipvsadm -L -n'

🎯 总结

LVS 是 Linux 世界中最成熟、性能最好的负载均衡解决方案之一。它就像一个经验丰富的交通指挥员,能够智能地把流量分配到最合适的服务器上。

核心要点记忆口诀:

  • NAT 模式像前台,所有流量都要过
  • DR 模式像指路,指完就让直连走
  • TUN 模式像快递,打包发送跨网络
  • 持久连接保会话,记得设置 -p 参数

最后提醒:负载均衡不是万能的,后端服务健康检查也很重要!记得配合 Keepalived 或 Heartbeat 使用,实现真正的高可用!


📚 官方文档与参考

资源 链接/说明 用途
LVS 项目首页 Linux Virtual Server 项目介绍与架构
IPVS 软件说明 IPVS - Advanced Layer-4 Switching 转发方式、调度算法、内核支持
LVSKB Wiki IPVSipvsadm 配置示例与命令说明
内核 ipvs 参数 ipvs-sysctl 内核 net.ipv4.vs.* 等参数
配合使用 本仓库 Keepalived 指南HA 高可用 LVS Director 高可用、VIP 漂移

LVS 与其它负载方案对比(相近方案)

维度 LVS (ip_vs) Nginx HAProxy
层级 四层(TCP/UDP) 七层为主,可做四层 stream 四层 + 七层
实现位置 内核 用户态进程 用户态进程
性能 极高(内核转发)
功能 转发 + 调度,无 HTTP 解析 反向代理、缓存、SSL、正则 负载、健康检查、ACL、多后端
典型场景 大流量四层入口、与 Keepalived 搭 Director HA Web 反向代理、API 网关 TCP/HTTP 负载、与 Keepalived 搭主备
生活类比 只负责「把电话转接到分机」 能看内容再决定转给谁、还能代答 既能转电话也能看内容再转
相关推荐
AC赳赳老秦2 小时前
软件组件自动化的革命:DeepSeek 引领高效开发新时代
运维·人工智能·算法·云原生·maven·devops·deepseek
Web极客码2 小时前
用 SSH Key 认证提升文件传输安全:SFTP/SSH 加固实战(适合站点运维与外贸站)
运维·安全·ssh
zhojiew2 小时前
在中国区EKS集群使用 kgateway 代理 Lambda 函数的实践过程
运维·envoy
小李独爱秋3 小时前
模拟面试:什么是容器技术,Docker是什么?
运维·docker·容器·面试·职场和发展
yangyanping201084 小时前
系统监控Prometheus之Docker安装部署Prometheus
运维·docker·容器·prometheus
盟接之桥4 小时前
制造业EDI数字化:连接全球供应链的桥梁
linux·运维·服务器·网络·人工智能·制造
大梦想家~4 小时前
在职牛马,因为考过阿里云ACP,浅说下一次过的强度
运维·云计算·网络工程师·阿里云acp·云计算工程师·阿里云acp考试·阿里云acp备考
暴力求解5 小时前
Linux-进程(三)进程的孤儿状态和僵尸状态
linux·运维·服务器
乾元5 小时前
数据投毒:如何通过训练数据污染埋下“后门”
运维·人工智能·网络协议·安全·网络安全·系统架构·自动化