1. 先从一次“服务器被打爆”说起前几年我给某电商平台做架构改造618大促前一周运营搞了一波集中拉新流量直接涨了快20倍。后端三台应用服务器CPU全部跑满数据库连接数被打穿页面开始随机白屏。那次的临时方案是加机器、重启、限流勉强撑了过去但谁都知道这不是长久之计——流量总是会再来的靠堆机器解决不了架构问题。后来我们认真调研负载均衡方案把市面上的 Nginx、HAProxy、LVS 都拉出来做了一轮压测和场景对比。最后核心入口层我选了 LVS理由很简单它工作在四层跑在内核态转发数据包的时候几乎不产生额外开销扛并发和高吞吐的能力在同级别方案里是天花板级别的存在。本文就把我这些年配置和使用 LVS 的原理、实战步骤和踩坑经验一次性讲清楚想搞定高并发架构的同学建议先读完前两节原理部分后面配置才能看得明白。LVS 全称是 Linux Virtual Server中文常叫 Linux 虚拟服务器。它由章文嵩博士发起但本文不聊历史故事只聊工程。核心思想就一句话用一台调度器也叫 Director、负载均衡器把一堆真实服务器Real Server组织成一个对外只有一个 IP 的虚拟服务。用户永远只和这个虚拟 IPVIP打交道至于背后是哪台机器在响应用户完全无感。2. 核心架构数据包到底是怎么被“转手”的2.1 三个角色必须分清理解 LVS 先要分清三个角色VIPVirtual IP对外暴露的虚拟服务地址是负载均衡器上的一个 IP。用户请求都打在这个 IP 上。Director调度器跑着 LVS 服务的机器核心组件叫ipvs通过ipvsadm工具来管理规则。它负责接收请求再按调度算法转发给后端。RSReal Server真正处理业务请求的服务器跑着 Nginx、Tomcat、MySQL 之类的服务。信息流大概是这样的用户访问 VIP → 请求到达 Director → Director 根据预设算法挑一台 RS → 数据包经过特定的转发机制到达 RS → RS 处理完把响应返回给用户。这里有一个新手最容易产生误区的地方很多人以为 LVS 和 Nginx 一样是“中转站”客户端的请求和响应都得经过它。其实不一定这取决于工作模式。在 DR 模式下响应的数据包是直接从 RS 绕过 Director 回到客户端的Director 只处理“进站”的流量这一点等会儿讲 DR 模式时会重点说明。2.2 真正干活的是内核里的 IPVS很多人有个疑问LVS 是不是一个像 Nginx 一样的用户态进程答案是否定的。LVS 的核心功能是在 Linux 内核中实现的那部分叫 IP Virtual Server也就是ipvs模块。用户态的ipvsadm只是用来增删改查内核里 IPVS 规则的管理工具。打个生活化的比方IPVS 就像一条地铁线路的调度系统每条进站指令被送到调度中心后调度系统瞬间决定把车派到哪个站台ipvsadm则是调度员手里的对讲机用来告诉调度系统“今天新增一条线路”“某条线路暂时停运”。真正执行决策的永远是内核里的调度系统而不是对讲机本身。所以配置 LVS 的时候规则配完立刻生效甚至不用重启服务。它不像改 Nginx 配置那样要 reload因为它根本就不是一个守护进程你改的是内核里的一张转发规则表。2.3 为什么高并发场景选 LVS 而不是 Nginx这里简单做个选型对比方便读者理解我当时为什么把 LVS 放在最外层维度LVS四层HAProxy四层Nginx七层工作层次传输层IP端口传输层IP端口应用层HTTP协议工作位置内核态用户态用户态相同请求量下的CPU占用很低中等较高最高并发支撑能力极高高常规水平特色能力三种模式灵活转发精细的四层健康检查反向代理、缓存、改写Nginx 不是不好但在四层转发这个维度上它做得再好也存在用户态到内核态切换的系统调用成本。而 LVS 在 DR 模式下请求到了 Director 后内核只是修改一下 MAC 帧的目标地址然后直接扔回网卡发出去整个转发过程近乎零拷贝。这个特点让它在超大规模并发入口场景下依然是首选。3. 三种工作模式选错模式等于白搭LVS 有三种最常见的模式NAT、DR、TUN后面衍生出来的 FullNAT 我也可以顺便介绍一下。每种模式的数据流转差异极大选错模式会带来奇怪的网络问题而且排查起来非常痛苦。3.1 NAT 模式最简单但容易成为瓶颈NATNetwork Address Translation模式在配置上最无脑原理也好理解Director 就像一个路由器客户端请求进来Director 做一次目标地址转换把目标 IP 从 VIP 改成某台 RS 的内网 IPRS 处理完的响应再反向通过 Director 时Director 再改一次源地址把源 IP 从 RS 的内网 IP 改回 VIP。这个模式的优势是后端 RS 只需要配置私网 IP 就行网关指向 Director对外完全不可见安全性好。但缺点也致命所有的响应流量都要从 Director 走一遍。如果请求 1KB、响应 10MB那 Director 的网络吞吐就会被响应流量直接压垮。有人统计过这种场景下 NAT 模式的吞吐极限大概只有 DR 模式的十分之一左右。NAT 模式的适用场景非常有限RS 和 Director 必须在同一个局域网且业务流量不大、响应体积较小的时候才值得用。比如内网管理系统、后台报表系统这类低频服务。3.2 DR 模式实际生产中最常见的方案DRDirect Routing直接路由模式是我最推荐生产环境使用的模式。它的核心思路是“进站走 Director出站走 RS 自己”。请求进来的时候用户请求到达 DirectorDirector 通过改写数据帧的目标 MAC 地址把数据包原封不动地转给选中的 RS。注意这里只是改 MACIP 层完全没动数据包里的目标 IP 仍然是 VIP。响应回去的时候RS 是直接把这个数据包发给客户端的完全不过 Director。因为目标 IP 是 VIP而 VIP 同时配置在 Director 和每一台 RS 的 loopback 接口上所以网卡能正常处理这个数据包。DR 模式最直观的好处就是 Director 只处理一半流量性能和吞吐上限一下子拉高了很多。但天下没有免费的午餐DR 模式有一个先决条件Director 和所有 RS 必须处于同一个二层网络也就是同一台交换机下面。因为帧级别的 MAC 改写没法跨路由器传播。3.3 DR 模式中 RS 上必须做的“隐藏动作”DR 模式最容易翻车的点就在这里所有 RS 都在 loopback 接口上配置了 VIP那客户端的 ARP 请求谁来响应如果每台 RS 都抢着响应 ARP那客户端就根本不知道 VIP 到底在哪台机器上。解决办法是在每台 RS 上用 sysctl 修改两个内核参数arp_ignore1只回答目标 IP 是本机网卡 IP 的 ARP 请求lo 接口上的 VIP 不参与 ARP 应答。arp_announce2不论自己有多少 IP对外通告的时候只用网卡上最匹配的 IP。这两个参数的意义通俗地讲就是让所有 RS 对外“隐身”不抢 VIP 的 ARP 应答同时 Director 的 VIP 正常通告让客户端把请求全部送到 Director 手里。我见过很多新手配置 DR 模式RS 的 Web 服务也正常启动了LVS 规则也觉得没问题但浏览器就是打不开。跑查了半天发现是 ARP 冲突数据包被随机送到了某台 RS而那台 RS 上没有对应的连接信息就把包丢了。所以这几行 sysctl 参数一定要记住。3.4 TUN 模式和 FullNAT 模式简要说明TUN 模式利用 IP 隧道技术把数据包封装一层新的 IP 头可以通过互联网跨地域转发。RS 不要求和 Director 在同一网段适合两地三中心那样的异地多活架构。但缺点是封装拆封有额外开销MTU 问题也会偶尔冒出来。FullNAT 模式是后来一些商业负载均衡产品常用的思路Director 在转发时同时修改源 IP 和目标 IP把源地址改成自己的内网 IP目标地址改成 RS 的内网 IP。这样做的最大好处是不用 RS 配置 VIP 那一堆 ARP 参数甚至跨网段也不怕。代价是需要给内核打特定补丁标准内核不带这个功能维护成本相对高。4. 调度算法一台新请求该送谁家4.1 常用算法逐个拆解LVS 的调度算法一共有十几种生产环境真正高频用到的就下面这几个rr轮询一个接一个轮流分配完全不看后端当前压力。适用于后端性能差不多的场景。wrr加权轮询给每台 RS 配一个权重权重高的分到的请求比例就高。这是我最常用的算法因为后端机器性能往往不齐新老机器混跑是常态。lc最少连接谁当前的连接数少就把请求给谁。它比轮询对后端压力的感知好一截但要注意的是它只统计 LVS 层面看到的并发连接数某些长连接应用下会失真。wlc加权最少连接最少连接加权重不仅看连接数还看服务器能力。这个算法在大多数场景下的均衡效果都还不错。sh源地址哈希按客户端 IP 的哈希值固定分配到同一台 RS。这个算法天然有会话保持的效果适合有状态服务。dh目标地址哈希按请求的目标地址做哈希常用于多级缓存架构把同一个目标的请求固定打到某台后端。4.2 怎么根据业务选算法我个人做选型时习惯这样判断如果后端是无状态的 Web API且机器配置差不多优先考虑wrr配置直观、排查方便。如果后端是短连接、请求时长差异较大的服务比如有些接口要查数据库十几秒有些接口两三毫秒就返回那么wlc比wrr均衡效果好很多因为轮询只看请求数不看请求耗时。如果有登录态、购物车这类需要保持会话的业务并且应用层没有做统一的 Session 共享那么sh是最省事的做法。顺带提醒一个坑有些人压根不分析业务就把算法设成lc或wlc结果后端有慢查询接口LVS 只看到连接建立得很少实际连接一直被占用却不释放。这种情况我建议在应用层做精细化治理LVS 算法只是框架性的手段。5. 手写一整套 LVS 配置从安装到生效5.1 环境规划下面以一个最典型的电商场景为例做个完整配置。假设我们有一台 Director内网 IP 为192.168.1.100额外配置 VIP192.168.1.200操作系统为某 Linux 发行版内核自带 IPVS 模块。两台 RSIP 分别是192.168.1.11和192.168.1.12上面跑 Nginx监听 80 端口。业务类型无状态 Web API长短请求混合采用 DR 模式 wlc算法。5.2 Director 端完整操作先确认内核模块和工具是否就绪# 检查内核是否已加载 ipvs 相关模块 modprobe ip_vs modprobe ip_vs_wrr modprobe ip_vs_wlc # 查看当前 LVS 规则此时应为空 ipvsadm -L -n如果ipvsadm命令不存在先安装管理工具。不同系统的包管理命令不同我用常见的命令来演示逻辑都一样# 以常见的包管理器为例安装 ipvsadm yum install -y ipvsadm # 或 apt install -y ipvsadm然后给 Director 配置 VIP。这里有个小知识点VIP 别名配置在 eth0 上和物理 IP 在同一个网段。配置完要确保 VIP 能 ping 通这说明 ARP 通告正常。# 添加 VIP 到 eth0:0 子接口 ifconfig eth0:0 192.168.1.200 netmask 255.255.255.255 up # 或 ip addr add 192.168.1.200/32 dev eth0:0接下来就是核心的 LVS 规则配置了。第一条命令创建虚拟服务第二条到第三条命令把两个 RS 加进来# 创建 VIP:Port 的虚拟服务使用 wlc 算法 ipvsadm -A -t 192.168.1.200:80 -s wlc # 添加第一台 RS使用 DR 模式权重为 100 ipvsadm -a -t 192.168.1.200:80 -r 192.168.1.11:80 -g -w 100 # 添加第二台 RS使用 DR 模式权重为 80 ipvsadm -a -t 192.168.1.200:80 -r 192.168.1.12:80 -g -w 80配置完成后用以下命令验证ipvsadm -L -n --stats输出中RemoteAddress那一列就是 RS 的地址Weight是权重ActiveConn和InActConn分别表示当前活动连接和非活动连接数。看到这些数据说明规则已经生效。注意一点用-g表示 DR 模式-m表示 NAT 模式-i表示 TUN 模式。很多人随手抄命令忘了这个参数导致流量转发出错。5.3 RS 端完整操作DR 模式下RS 的配置远比 Director 麻烦。核心就两件事配置 VIP 到回环接口并屏蔽 ARP 响应。# 把 VIP 配置到 lo:0 上 ifconfig lo:0 192.168.1.200 netmask 255.255.255.255 up # 或 ip addr add 192.168.1.200/32 dev lo:0然后修改内核参数cat /etc/sysctl.conf EOF net.ipv4.conf.all.arp_ignore 1 net.ipv4.conf.all.arp_announce 2 net.ipv4.conf.lo.arp_ignore 1 net.ipv4.conf.lo.arp_announce 2 EOF sysctl -p这两行参数的含义前面已经解释过让 RS 对 VIP 保持“监听但不回应”的状态收包可以但不参与 ARP 广播竞争。这一步漏掉的话跨交换机抓包的时候你会看到客户端在直接和某台 RS 建立 TCP 握手LVS 完全成了“摆设”。5.4 开机自启动的持久化配置手敲的ifconfig和ipvsadm规则重启机器之后会全部消失。生产环境要想一劳永逸我建议用配置文件管理。Director 端把 LVS 规则保存到文件并设置开机自动恢复。一种常见做法是把规则写入/etc/sysconfig/ipvsadm启动ipvsadm.service服务另一种是写一个 systemd 启动脚本在 ExecStart 里逐行执行ipvsadm命令。第二种方式更灵活适合规则复杂、带有注释的场景。RS 端把 VIP 绑定和 sysctl 参数写进/etc/rc.local记得给可执行权限或者同样用 systemd unit 管理。这块工作量不大但在线上环境非常重要。我亲眼见过某团队大促当天凌晨重启机器结果所有 LVS 规则全部丢失流量直接裸奔打到 RS 上还好业务本身扛住了。这种事发生一次就够了。5.5 用 keepalived 接管配置和健康检查手动配置 LVS 有一个大短板不健康检查。如果某台 RS 挂了ipvsadm里的规则不会自动摘除这台机器请求依然会被调度到它上面然后白屏。生产环境我强烈建议直接用 keepalived 来承载 LVS 配置。keepalived 本身是基于 VRRP 协议的高可用方案同时内置了 LVS 管理模块既能做 Director 的主备切换也能对后端 RS 做定期健康检查。简单看一下配置骨架两个 Director 节点分别配一套主节点配置如下global_defs { router_id LVS_DIRECTOR } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 123456 } virtual_ipaddress { 192.168.1.200 } } virtual_server 192.168.1.200 80 { delay_loop 6 lb_algo wlc lb_kind DR persistence_timeout 20 protocol TCP real_server 192.168.1.11 80 { weight 100 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } real_server 192.168.1.12 80 { weight 80 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } }备份节点只需要把state改成BACKUPpriority改小一些即可。keepalived 会自动在 Master 节点上绑定 VIP、配置 IPVS 规则、执行健康检查一旦某台 RS 的 80 端口连续探测失败就自动把它的权重设为 0摘出调度池。这套组合是目前 Linux 生态下很经典的四层高可用方案。6. 会话保持、超时调优与性能验证6.1 会话保持怎么配我服务的很多业务早期没有做 Session 共享这时候 LVS 层面的会话保持就很重要了。在ipvsadm命令里加一个-p参数即可# 新建虚拟服务时指定持久超时时间单位秒 ipvsadm -A -t 192.168.1.200:80 -s wlc -p 600-p 600表示同一个来源 IP 的请求在 600 秒内都被调度到同一台 RS。keepalived 配置文件里对应的是persistence_timeout 20单位同样是秒。这个参数不是越大越好。如果后端是基于 Cookie 做会话保持的分布式应用LVS 层的-p反而可能造成某台机器热点过高。常规做法无状态服务不开持久保持有状态服务开个 5 到 10 分钟即可。6.2 TCP 超时参数调优IPVS 内核里维护着一张连接跟踪表记录每条 TCP/UDP 连接的转发信息。Linux 内核默认的一些超时时间在某些业务场景下不太合适。比如 TCP 长连接场景客户端和服务端之间空闲 2 分钟不发数据连接可能就被内核回收了应用层毫不知情下次发数据直接收到 RST。常用调整项如下# 查看当前超时配置 ipvsadm -L -n --timeout # 修改 TCP 空闲超时时间秒 ipvsadm --set 120 30 300 # 格式TCP 空闲超时、TCP 关闭后 FIN 等待超时、UDP 超时我一般建议 TCP 空闲超时时间不低于业务心跳间隔的两倍。比如客户端每 30 秒发一个心跳包那--set 90 30 300是合理的选择。太小会导致大量连接被过早回收太大又会占用太多内核连接表项。6.3 性能验证压测结果怎么解读配置完成后先要验证一下别急着提前庆祝。我的验证分三步先用 curl 反复请求 VIP 地址观察响应内容是否在后端两台机器上交替出现。如果只固定在某一台那可能是调度算法配成了sh或者持久化超时没关。再用并发工具压测。以一个开源的压测工具为例模拟并发时观察 LVS 的活动连接数变化ipvsadm -L -n --stats看ActiveConn是否均匀分布InActConn是否堆积。如果其中一台的ActiveConn高出另一台几倍就要检查是不是权重设置的差距和实际机器性能的差距不成比例。最后看 Director 自身的指标。LVS 处理数据包的工作量不大Director 的 CPU 通常非常空闲。如果 Director CPU 出现明显饱和多半是你把 NAT 模式当成了 DR 模式在用或者网卡出现了软中断热点。用top观察si软中断占比结合网卡队列信息来分析。7. 我踩过的坑给你省几个月弯路7.1 ARP 大坑明明通了却时而断之前遇到过一个现象客户端访问 VIP 时好时坏丢包率波动很大。抓包之后发现客户端发起 ARP 请求时多台机器都在应答MAC 地址漂来漂去。这就是典型的 ARP 冲突。后来把所有 RS 的arp_ignore和arp_announce统一设置为 1 和 2并同时修改了all和对应网卡接口两处配置后问题彻底消失。这里有个细节很多人忽略sysctl 配置文件里只改all或只改具体网卡接口名都可能不生效。规范做法是两个都写因为内核在处理某些协议时all和具体接口的配置都会影响最终结果。7.2 权重不是你以为的那个意思wrr和wlc的 Weight 数值不是绝对的“能力值”它只是一个相对比例。我在实际配置里见过有些人为了追求绝对均衡把权重全部设成 100结果所有机器承担的量完全相同完全没发挥出加权调度的作用。正确的做法是先跑一周压测摸清每台机器的 CPU、内存、磁盘 IO 余量再回来设置权重。比如新机器能扛 2000 QPS老机器只能扛 800 QPS那权重比例设为 5:2 是比较合理的。7.3 keepalived 主备切换的血泪教训keepalived 的主备切换依赖于 VRRP 报文交互但如果交换机开启了某些网络隔离特性例如端口隔离、组播过滤配置不当VRRP 报文可能直接被丢导致两台 Director 同时认为自己是 MASTER同时绑定 VIP出现 IP 冲突。解决方式优先用单播方式配置 VRRP不要依赖组播。keepalived 支持unicast_src_ip和unicast_peer两个配置项显式指定对方 IP这样报文走单播更可靠。7.4 RS 的本地回程路由问题某些场景下RS 上有多个网卡或者配置了复杂的路由策略响应数据包可能从错误的网卡发出客户端看到源 IP 不对直接丢弃应答。排查方式是登录到 RS 上执行curl --interface eth0 http://对端某个正常的IP如果响应正常但是业务流量不通八成是策略路由或反向路由过滤rp_filter在作祟。适当调整rp_filter设置例如改为 0 或 2或者明确指定从哪块网卡发出响应流量通常能解决。7.5 监控别漏掉连接跟踪表LVS 依赖内核的nf_conntrack连接跟踪机制连接数一旦超过内核上限新连接直接无法建立。检查方法cat /proc/sys/net/netfilter/nf_conntrack_max cat /proc/sys/net/netfilter/nf_conntrack_count如果count接近max需要适当调大上限同时注意服务器的内存余量。不过现在新内核里 IPVS 的很多场景可以绕过完整的 conntrack 跟踪这会大幅降低连接表内存消耗具体是否生效要看内核版本和模块参数建议先在小流量环境验证。8. 最后的几点心里话LVS 不是一个“装一下、配一下”就能用得很好的东西它非常考验对网络协议栈的理解。如果只是照抄命令出了问题就抓瞎如果把 TCP/IP 原理、ARP 行为、内核连接跟踪机制吃透了LVS 从配置到排障其实都非常顺手。我后来参与的几套高并发架构入口层无一例外都用了 LVS 或基于 LVS 原理的商业负载均衡产品。它的稳是那种“你几乎感觉不到它存在”的稳。把调度算法、工作模式、健康检查、超时参数一次性调对之后它就安静地跑在机房里每天默默转发成百上千万个请求。如果你正在搭建自己的高并发系统或者只是想把负载均衡这块知识体系补完整我的建议是先建两台虚拟机手动配一遍 NAT 模式再配一遍 DR 模式故意把 ARP 参数删掉体验一次问题现象亲手sysctl改回去。这种“故意搞坏再修好”的练习方式比看十篇教程都长记性。
1. 先从一次“服务器被打爆”说起前几年我给某电商平台做架构改造618大促前一周运营搞了一波集中拉新流量直接涨了快20倍。后端三台应用服务器CPU全部跑满数据库连接数被打穿页面开始随机白屏。那次的临时方案是加机器、重启、限流勉强撑了过去但谁都知道这不是长久之计——流量总是会再来的靠堆机器解决不了架构问题。后来我们认真调研负载均衡方案把市面上的 Nginx、HAProxy、LVS 都拉出来做了一轮压测和场景对比。最后核心入口层我选了 LVS理由很简单它工作在四层跑在内核态转发数据包的时候几乎不产生额外开销扛并发和高吞吐的能力在同级别方案里是天花板级别的存在。本文就把我这些年配置和使用 LVS 的原理、实战步骤和踩坑经验一次性讲清楚想搞定高并发架构的同学建议先读完前两节原理部分后面配置才能看得明白。LVS 全称是 Linux Virtual Server中文常叫 Linux 虚拟服务器。它由章文嵩博士发起但本文不聊历史故事只聊工程。核心思想就一句话用一台调度器也叫 Director、负载均衡器把一堆真实服务器Real Server组织成一个对外只有一个 IP 的虚拟服务。用户永远只和这个虚拟 IPVIP打交道至于背后是哪台机器在响应用户完全无感。2. 核心架构数据包到底是怎么被“转手”的2.1 三个角色必须分清理解 LVS 先要分清三个角色VIPVirtual IP对外暴露的虚拟服务地址是负载均衡器上的一个 IP。用户请求都打在这个 IP 上。Director调度器跑着 LVS 服务的机器核心组件叫ipvs通过ipvsadm工具来管理规则。它负责接收请求再按调度算法转发给后端。RSReal Server真正处理业务请求的服务器跑着 Nginx、Tomcat、MySQL 之类的服务。信息流大概是这样的用户访问 VIP → 请求到达 Director → Director 根据预设算法挑一台 RS → 数据包经过特定的转发机制到达 RS → RS 处理完把响应返回给用户。这里有一个新手最容易产生误区的地方很多人以为 LVS 和 Nginx 一样是“中转站”客户端的请求和响应都得经过它。其实不一定这取决于工作模式。在 DR 模式下响应的数据包是直接从 RS 绕过 Director 回到客户端的Director 只处理“进站”的流量这一点等会儿讲 DR 模式时会重点说明。2.2 真正干活的是内核里的 IPVS很多人有个疑问LVS 是不是一个像 Nginx 一样的用户态进程答案是否定的。LVS 的核心功能是在 Linux 内核中实现的那部分叫 IP Virtual Server也就是ipvs模块。用户态的ipvsadm只是用来增删改查内核里 IPVS 规则的管理工具。打个生活化的比方IPVS 就像一条地铁线路的调度系统每条进站指令被送到调度中心后调度系统瞬间决定把车派到哪个站台ipvsadm则是调度员手里的对讲机用来告诉调度系统“今天新增一条线路”“某条线路暂时停运”。真正执行决策的永远是内核里的调度系统而不是对讲机本身。所以配置 LVS 的时候规则配完立刻生效甚至不用重启服务。它不像改 Nginx 配置那样要 reload因为它根本就不是一个守护进程你改的是内核里的一张转发规则表。2.3 为什么高并发场景选 LVS 而不是 Nginx这里简单做个选型对比方便读者理解我当时为什么把 LVS 放在最外层维度LVS四层HAProxy四层Nginx七层工作层次传输层IP端口传输层IP端口应用层HTTP协议工作位置内核态用户态用户态相同请求量下的CPU占用很低中等较高最高并发支撑能力极高高常规水平特色能力三种模式灵活转发精细的四层健康检查反向代理、缓存、改写Nginx 不是不好但在四层转发这个维度上它做得再好也存在用户态到内核态切换的系统调用成本。而 LVS 在 DR 模式下请求到了 Director 后内核只是修改一下 MAC 帧的目标地址然后直接扔回网卡发出去整个转发过程近乎零拷贝。这个特点让它在超大规模并发入口场景下依然是首选。3. 三种工作模式选错模式等于白搭LVS 有三种最常见的模式NAT、DR、TUN后面衍生出来的 FullNAT 我也可以顺便介绍一下。每种模式的数据流转差异极大选错模式会带来奇怪的网络问题而且排查起来非常痛苦。3.1 NAT 模式最简单但容易成为瓶颈NATNetwork Address Translation模式在配置上最无脑原理也好理解Director 就像一个路由器客户端请求进来Director 做一次目标地址转换把目标 IP 从 VIP 改成某台 RS 的内网 IPRS 处理完的响应再反向通过 Director 时Director 再改一次源地址把源 IP 从 RS 的内网 IP 改回 VIP。这个模式的优势是后端 RS 只需要配置私网 IP 就行网关指向 Director对外完全不可见安全性好。但缺点也致命所有的响应流量都要从 Director 走一遍。如果请求 1KB、响应 10MB那 Director 的网络吞吐就会被响应流量直接压垮。有人统计过这种场景下 NAT 模式的吞吐极限大概只有 DR 模式的十分之一左右。NAT 模式的适用场景非常有限RS 和 Director 必须在同一个局域网且业务流量不大、响应体积较小的时候才值得用。比如内网管理系统、后台报表系统这类低频服务。3.2 DR 模式实际生产中最常见的方案DRDirect Routing直接路由模式是我最推荐生产环境使用的模式。它的核心思路是“进站走 Director出站走 RS 自己”。请求进来的时候用户请求到达 DirectorDirector 通过改写数据帧的目标 MAC 地址把数据包原封不动地转给选中的 RS。注意这里只是改 MACIP 层完全没动数据包里的目标 IP 仍然是 VIP。响应回去的时候RS 是直接把这个数据包发给客户端的完全不过 Director。因为目标 IP 是 VIP而 VIP 同时配置在 Director 和每一台 RS 的 loopback 接口上所以网卡能正常处理这个数据包。DR 模式最直观的好处就是 Director 只处理一半流量性能和吞吐上限一下子拉高了很多。但天下没有免费的午餐DR 模式有一个先决条件Director 和所有 RS 必须处于同一个二层网络也就是同一台交换机下面。因为帧级别的 MAC 改写没法跨路由器传播。3.3 DR 模式中 RS 上必须做的“隐藏动作”DR 模式最容易翻车的点就在这里所有 RS 都在 loopback 接口上配置了 VIP那客户端的 ARP 请求谁来响应如果每台 RS 都抢着响应 ARP那客户端就根本不知道 VIP 到底在哪台机器上。解决办法是在每台 RS 上用 sysctl 修改两个内核参数arp_ignore1只回答目标 IP 是本机网卡 IP 的 ARP 请求lo 接口上的 VIP 不参与 ARP 应答。arp_announce2不论自己有多少 IP对外通告的时候只用网卡上最匹配的 IP。这两个参数的意义通俗地讲就是让所有 RS 对外“隐身”不抢 VIP 的 ARP 应答同时 Director 的 VIP 正常通告让客户端把请求全部送到 Director 手里。我见过很多新手配置 DR 模式RS 的 Web 服务也正常启动了LVS 规则也觉得没问题但浏览器就是打不开。跑查了半天发现是 ARP 冲突数据包被随机送到了某台 RS而那台 RS 上没有对应的连接信息就把包丢了。所以这几行 sysctl 参数一定要记住。3.4 TUN 模式和 FullNAT 模式简要说明TUN 模式利用 IP 隧道技术把数据包封装一层新的 IP 头可以通过互联网跨地域转发。RS 不要求和 Director 在同一网段适合两地三中心那样的异地多活架构。但缺点是封装拆封有额外开销MTU 问题也会偶尔冒出来。FullNAT 模式是后来一些商业负载均衡产品常用的思路Director 在转发时同时修改源 IP 和目标 IP把源地址改成自己的内网 IP目标地址改成 RS 的内网 IP。这样做的最大好处是不用 RS 配置 VIP 那一堆 ARP 参数甚至跨网段也不怕。代价是需要给内核打特定补丁标准内核不带这个功能维护成本相对高。4. 调度算法一台新请求该送谁家4.1 常用算法逐个拆解LVS 的调度算法一共有十几种生产环境真正高频用到的就下面这几个rr轮询一个接一个轮流分配完全不看后端当前压力。适用于后端性能差不多的场景。wrr加权轮询给每台 RS 配一个权重权重高的分到的请求比例就高。这是我最常用的算法因为后端机器性能往往不齐新老机器混跑是常态。lc最少连接谁当前的连接数少就把请求给谁。它比轮询对后端压力的感知好一截但要注意的是它只统计 LVS 层面看到的并发连接数某些长连接应用下会失真。wlc加权最少连接最少连接加权重不仅看连接数还看服务器能力。这个算法在大多数场景下的均衡效果都还不错。sh源地址哈希按客户端 IP 的哈希值固定分配到同一台 RS。这个算法天然有会话保持的效果适合有状态服务。dh目标地址哈希按请求的目标地址做哈希常用于多级缓存架构把同一个目标的请求固定打到某台后端。4.2 怎么根据业务选算法我个人做选型时习惯这样判断如果后端是无状态的 Web API且机器配置差不多优先考虑wrr配置直观、排查方便。如果后端是短连接、请求时长差异较大的服务比如有些接口要查数据库十几秒有些接口两三毫秒就返回那么wlc比wrr均衡效果好很多因为轮询只看请求数不看请求耗时。如果有登录态、购物车这类需要保持会话的业务并且应用层没有做统一的 Session 共享那么sh是最省事的做法。顺带提醒一个坑有些人压根不分析业务就把算法设成lc或wlc结果后端有慢查询接口LVS 只看到连接建立得很少实际连接一直被占用却不释放。这种情况我建议在应用层做精细化治理LVS 算法只是框架性的手段。5. 手写一整套 LVS 配置从安装到生效5.1 环境规划下面以一个最典型的电商场景为例做个完整配置。假设我们有一台 Director内网 IP 为192.168.1.100额外配置 VIP192.168.1.200操作系统为某 Linux 发行版内核自带 IPVS 模块。两台 RSIP 分别是192.168.1.11和192.168.1.12上面跑 Nginx监听 80 端口。业务类型无状态 Web API长短请求混合采用 DR 模式 wlc算法。5.2 Director 端完整操作先确认内核模块和工具是否就绪# 检查内核是否已加载 ipvs 相关模块 modprobe ip_vs modprobe ip_vs_wrr modprobe ip_vs_wlc # 查看当前 LVS 规则此时应为空 ipvsadm -L -n如果ipvsadm命令不存在先安装管理工具。不同系统的包管理命令不同我用常见的命令来演示逻辑都一样# 以常见的包管理器为例安装 ipvsadm yum install -y ipvsadm # 或 apt install -y ipvsadm然后给 Director 配置 VIP。这里有个小知识点VIP 别名配置在 eth0 上和物理 IP 在同一个网段。配置完要确保 VIP 能 ping 通这说明 ARP 通告正常。# 添加 VIP 到 eth0:0 子接口 ifconfig eth0:0 192.168.1.200 netmask 255.255.255.255 up # 或 ip addr add 192.168.1.200/32 dev eth0:0接下来就是核心的 LVS 规则配置了。第一条命令创建虚拟服务第二条到第三条命令把两个 RS 加进来# 创建 VIP:Port 的虚拟服务使用 wlc 算法 ipvsadm -A -t 192.168.1.200:80 -s wlc # 添加第一台 RS使用 DR 模式权重为 100 ipvsadm -a -t 192.168.1.200:80 -r 192.168.1.11:80 -g -w 100 # 添加第二台 RS使用 DR 模式权重为 80 ipvsadm -a -t 192.168.1.200:80 -r 192.168.1.12:80 -g -w 80配置完成后用以下命令验证ipvsadm -L -n --stats输出中RemoteAddress那一列就是 RS 的地址Weight是权重ActiveConn和InActConn分别表示当前活动连接和非活动连接数。看到这些数据说明规则已经生效。注意一点用-g表示 DR 模式-m表示 NAT 模式-i表示 TUN 模式。很多人随手抄命令忘了这个参数导致流量转发出错。5.3 RS 端完整操作DR 模式下RS 的配置远比 Director 麻烦。核心就两件事配置 VIP 到回环接口并屏蔽 ARP 响应。# 把 VIP 配置到 lo:0 上 ifconfig lo:0 192.168.1.200 netmask 255.255.255.255 up # 或 ip addr add 192.168.1.200/32 dev lo:0然后修改内核参数cat /etc/sysctl.conf EOF net.ipv4.conf.all.arp_ignore 1 net.ipv4.conf.all.arp_announce 2 net.ipv4.conf.lo.arp_ignore 1 net.ipv4.conf.lo.arp_announce 2 EOF sysctl -p这两行参数的含义前面已经解释过让 RS 对 VIP 保持“监听但不回应”的状态收包可以但不参与 ARP 广播竞争。这一步漏掉的话跨交换机抓包的时候你会看到客户端在直接和某台 RS 建立 TCP 握手LVS 完全成了“摆设”。5.4 开机自启动的持久化配置手敲的ifconfig和ipvsadm规则重启机器之后会全部消失。生产环境要想一劳永逸我建议用配置文件管理。Director 端把 LVS 规则保存到文件并设置开机自动恢复。一种常见做法是把规则写入/etc/sysconfig/ipvsadm启动ipvsadm.service服务另一种是写一个 systemd 启动脚本在 ExecStart 里逐行执行ipvsadm命令。第二种方式更灵活适合规则复杂、带有注释的场景。RS 端把 VIP 绑定和 sysctl 参数写进/etc/rc.local记得给可执行权限或者同样用 systemd unit 管理。这块工作量不大但在线上环境非常重要。我亲眼见过某团队大促当天凌晨重启机器结果所有 LVS 规则全部丢失流量直接裸奔打到 RS 上还好业务本身扛住了。这种事发生一次就够了。5.5 用 keepalived 接管配置和健康检查手动配置 LVS 有一个大短板不健康检查。如果某台 RS 挂了ipvsadm里的规则不会自动摘除这台机器请求依然会被调度到它上面然后白屏。生产环境我强烈建议直接用 keepalived 来承载 LVS 配置。keepalived 本身是基于 VRRP 协议的高可用方案同时内置了 LVS 管理模块既能做 Director 的主备切换也能对后端 RS 做定期健康检查。简单看一下配置骨架两个 Director 节点分别配一套主节点配置如下global_defs { router_id LVS_DIRECTOR } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 123456 } virtual_ipaddress { 192.168.1.200 } } virtual_server 192.168.1.200 80 { delay_loop 6 lb_algo wlc lb_kind DR persistence_timeout 20 protocol TCP real_server 192.168.1.11 80 { weight 100 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } real_server 192.168.1.12 80 { weight 80 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } }备份节点只需要把state改成BACKUPpriority改小一些即可。keepalived 会自动在 Master 节点上绑定 VIP、配置 IPVS 规则、执行健康检查一旦某台 RS 的 80 端口连续探测失败就自动把它的权重设为 0摘出调度池。这套组合是目前 Linux 生态下很经典的四层高可用方案。6. 会话保持、超时调优与性能验证6.1 会话保持怎么配我服务的很多业务早期没有做 Session 共享这时候 LVS 层面的会话保持就很重要了。在ipvsadm命令里加一个-p参数即可# 新建虚拟服务时指定持久超时时间单位秒 ipvsadm -A -t 192.168.1.200:80 -s wlc -p 600-p 600表示同一个来源 IP 的请求在 600 秒内都被调度到同一台 RS。keepalived 配置文件里对应的是persistence_timeout 20单位同样是秒。这个参数不是越大越好。如果后端是基于 Cookie 做会话保持的分布式应用LVS 层的-p反而可能造成某台机器热点过高。常规做法无状态服务不开持久保持有状态服务开个 5 到 10 分钟即可。6.2 TCP 超时参数调优IPVS 内核里维护着一张连接跟踪表记录每条 TCP/UDP 连接的转发信息。Linux 内核默认的一些超时时间在某些业务场景下不太合适。比如 TCP 长连接场景客户端和服务端之间空闲 2 分钟不发数据连接可能就被内核回收了应用层毫不知情下次发数据直接收到 RST。常用调整项如下# 查看当前超时配置 ipvsadm -L -n --timeout # 修改 TCP 空闲超时时间秒 ipvsadm --set 120 30 300 # 格式TCP 空闲超时、TCP 关闭后 FIN 等待超时、UDP 超时我一般建议 TCP 空闲超时时间不低于业务心跳间隔的两倍。比如客户端每 30 秒发一个心跳包那--set 90 30 300是合理的选择。太小会导致大量连接被过早回收太大又会占用太多内核连接表项。6.3 性能验证压测结果怎么解读配置完成后先要验证一下别急着提前庆祝。我的验证分三步先用 curl 反复请求 VIP 地址观察响应内容是否在后端两台机器上交替出现。如果只固定在某一台那可能是调度算法配成了sh或者持久化超时没关。再用并发工具压测。以一个开源的压测工具为例模拟并发时观察 LVS 的活动连接数变化ipvsadm -L -n --stats看ActiveConn是否均匀分布InActConn是否堆积。如果其中一台的ActiveConn高出另一台几倍就要检查是不是权重设置的差距和实际机器性能的差距不成比例。最后看 Director 自身的指标。LVS 处理数据包的工作量不大Director 的 CPU 通常非常空闲。如果 Director CPU 出现明显饱和多半是你把 NAT 模式当成了 DR 模式在用或者网卡出现了软中断热点。用top观察si软中断占比结合网卡队列信息来分析。7. 我踩过的坑给你省几个月弯路7.1 ARP 大坑明明通了却时而断之前遇到过一个现象客户端访问 VIP 时好时坏丢包率波动很大。抓包之后发现客户端发起 ARP 请求时多台机器都在应答MAC 地址漂来漂去。这就是典型的 ARP 冲突。后来把所有 RS 的arp_ignore和arp_announce统一设置为 1 和 2并同时修改了all和对应网卡接口两处配置后问题彻底消失。这里有个细节很多人忽略sysctl 配置文件里只改all或只改具体网卡接口名都可能不生效。规范做法是两个都写因为内核在处理某些协议时all和具体接口的配置都会影响最终结果。7.2 权重不是你以为的那个意思wrr和wlc的 Weight 数值不是绝对的“能力值”它只是一个相对比例。我在实际配置里见过有些人为了追求绝对均衡把权重全部设成 100结果所有机器承担的量完全相同完全没发挥出加权调度的作用。正确的做法是先跑一周压测摸清每台机器的 CPU、内存、磁盘 IO 余量再回来设置权重。比如新机器能扛 2000 QPS老机器只能扛 800 QPS那权重比例设为 5:2 是比较合理的。7.3 keepalived 主备切换的血泪教训keepalived 的主备切换依赖于 VRRP 报文交互但如果交换机开启了某些网络隔离特性例如端口隔离、组播过滤配置不当VRRP 报文可能直接被丢导致两台 Director 同时认为自己是 MASTER同时绑定 VIP出现 IP 冲突。解决方式优先用单播方式配置 VRRP不要依赖组播。keepalived 支持unicast_src_ip和unicast_peer两个配置项显式指定对方 IP这样报文走单播更可靠。7.4 RS 的本地回程路由问题某些场景下RS 上有多个网卡或者配置了复杂的路由策略响应数据包可能从错误的网卡发出客户端看到源 IP 不对直接丢弃应答。排查方式是登录到 RS 上执行curl --interface eth0 http://对端某个正常的IP如果响应正常但是业务流量不通八成是策略路由或反向路由过滤rp_filter在作祟。适当调整rp_filter设置例如改为 0 或 2或者明确指定从哪块网卡发出响应流量通常能解决。7.5 监控别漏掉连接跟踪表LVS 依赖内核的nf_conntrack连接跟踪机制连接数一旦超过内核上限新连接直接无法建立。检查方法cat /proc/sys/net/netfilter/nf_conntrack_max cat /proc/sys/net/netfilter/nf_conntrack_count如果count接近max需要适当调大上限同时注意服务器的内存余量。不过现在新内核里 IPVS 的很多场景可以绕过完整的 conntrack 跟踪这会大幅降低连接表内存消耗具体是否生效要看内核版本和模块参数建议先在小流量环境验证。8. 最后的几点心里话LVS 不是一个“装一下、配一下”就能用得很好的东西它非常考验对网络协议栈的理解。如果只是照抄命令出了问题就抓瞎如果把 TCP/IP 原理、ARP 行为、内核连接跟踪机制吃透了LVS 从配置到排障其实都非常顺手。我后来参与的几套高并发架构入口层无一例外都用了 LVS 或基于 LVS 原理的商业负载均衡产品。它的稳是那种“你几乎感觉不到它存在”的稳。把调度算法、工作模式、健康检查、超时参数一次性调对之后它就安静地跑在机房里每天默默转发成百上千万个请求。如果你正在搭建自己的高并发系统或者只是想把负载均衡这块知识体系补完整我的建议是先建两台虚拟机手动配一遍 NAT 模式再配一遍 DR 模式故意把 ARP 参数删掉体验一次问题现象亲手sysctl改回去。这种“故意搞坏再修好”的练习方式比看十篇教程都长记性。
