LVS负载均衡原理与实战：从IPVS内核转发到高可用架构-北京尧图网络

开头先讲一段我自己的经历。之前有个接口网关流量涨到一定规模之后我负责的Nginx服务器CPU软中断开始飙升单机扛不住扩容又不到时候。后来把它换成了Linux Virtual ServerLVS做接入层转发直接从内核层面把包分发出去CPU占用一下子降下来了。从那时起我就觉得搞负载均衡如果只盯着Nginx这类七层代理四层内核态的LVS迟早会是绕不开的一课。这篇文章就把LVS的核心知识点按我自己的理解从头捋一遍适合做运维、SRE、架构设计的同学尤其是那些刚接触LVS但不想只看文档、想真正搞懂它为什么这么设计、生产里怎么用的朋友。1. LVS到底解决了什么问题一次四层转发的选型思考1.1 内核态负载均衡模块与用户态管理工具先明确一个概念LVS不是一个独立安装的进程服务它由两部分组成——内核里的IPVS模块和用户态的ipvsadm管理命令。IPVS全称IP Virtual Server工作在内核网络栈里收到数据包之后直接根据规则改写、转发整个过程不经过用户态也不经过socket缓冲区所以性能比传统的用户态代理高很多。你可以先确认一下自己的机器里有没有加载这个模块lsmod | grep ip_vs modprobe ip_vs常见的发行版默认不会自动加载它但内核里一般都有这个能力。ipvsadm不是端口的监听程序它是管理员用来增删改查转发规则的工具相当于“控制面板”。这一点和Nginx很不一样Nginx本身是监听80/443端口的服务进程而LVS本身不监听任何业务端口它只负责把发到VIP虚拟IP的包按照你定义的规则转给后端的真实服务器。1.2 LVS集群的三个组成部分和核心IP概念一套传统的LVS集群由三部分组成负载调度器我们一般叫Director、真实服务器池RealServer以下简称RS、共享存储可选。Director入口流量先到它这里由它决定这个包发给哪个RSRS真正处理业务请求的服务器比如Web服务、API服务、数据库服务共享存储多台RS要读写同一份数据时才需要比如文件服务器的共享目录。现在的服务基本都无状态化了这个组件用得越来越少。理解LVS的配置有三个IP必须分清楚名称说明担任角色VIP虚拟IP对客户端暴露的入口地址Director和RS都可能持有DR模式DIPDirector的物理IP用于和RS通信仅DirectorRIPRealServer的真实IP真正干活的机器仅RS初学者最容易绕晕的就是VIP在DR模式下VIP不只属于DirectorRS也要在本地环回接口上绑定这个IP。为什么第二节详细说这是理解LVS模式的核心。1.3 一个请求从进入到返回的完整路径用最基础的NAT模式举个例子客户端发一个包到VIPDirector收到后把目标IP从VIP改成某个RIP转发给RSRS处理完把响应包回给DirectorDirector再把源IP改回VIP还给客户端。这个流程里客户端始终只和VIP打交道它并不知道后面有几台RS。这就像一个大公司的前台电话外面客户永远只拨总机号码前台接听后转到具体部门回电话也是先回到前台再转出来。好处是后端服务器对客户端完全透明坏处是前台容易累——这是NAT模式最大的瓶颈。理解了NAT模式再去看DR和TUN就顺了。下面三种模式分开讲。2. 三种工作模式怎么选DR、NAT、TUN的核心差异2.1 NAT模式所有流量都过Director简单但容易成为瓶颈NAT模式-m的原理就是网络地址转换。Director在数据链路层和网络层做手脚请求包进入Director目标IP是VIPDirector把它改写成某个RIP请求转发给RSRS的响应包先回到DirectorDirector再把源IP改回VIP发给客户端。因为请求和响应都要经过Director它的进出流量是加倍的。假设后端RS的总业务吞吐是2Gbps那Director至少要扛4Gbps的进出流量。所以NAT模式一般只适合后端机器少、流量不大的内部环境生产环境里很少用它作为大规模入口。配置上NAT模式反而最简单Director开双网卡开启内核的IP转发能力RS的网关指向Director即可。很多人第一次搭LVS都是用NAT模式练手的。它缺点是明显但确实能帮你把LVS的基本原理跑通。2.2 DR模式生产环境绝对主力MAC地址改写是关键DR模式Direct Routing-g是目前用得最广的模式。它的核心思想是Director只改写数据包的二层MAC地址不改IP然后把包直接发给RSRS处理完直接把响应包回给客户端不再绕回Director。怎么做到“不改IP却能把包给对的人”以太网通信靠的是MAC地址。Director和RS在同一二层网络里时Director把包的目的MAC改成目标RS的网卡MAC交换机就会把这个包送到RS手上。RS收到后看到目标IP还是VIP而它自己刚好在本地环回接口配了VIP于是正常接收处理。回程的时候RS直接以VIP作为源IP回给客户端整个回程路径完全绕开了Director这样Director只需要处理一半流量入向流量压力大幅下降。这里有几个点必须注意Director和RS必须在同一个二层网络比如同一个交换机下;RS必须在lo接口上绑定VIP掩码固定写255.255.255.255RS必须关闭对VIP的ARP应答否则它会和Director抢答VIP造成整个集群路由混乱。RS端的关键配置如下# 在每台RS上执行 sysctl -w net.ipv4.conf.all.arp_ignore1 sysctl -w net.ipv4.conf.all.arp_announce2 sysctl -w net.ipv4.conf.lo.arp_ignore1 sysctl -w net.ipv4.conf.lo.arp_announce2 ip addr add 192.0.2.10/32 dev lo这里的arp_ignore1意思是本机只回应“目标IP与本机收到请求的那个网卡IP相同”的ARP请求。RS的eth0上没有VIP所以外部问VIP是谁的MAC时RS不会抢答。arp_announce2让本机在向外发ARP请求时尽量不向外暴露VIP。这两个参数加起来才能确保VIP只出现在Director上由Director统一应答和接收。2.3 TUN模式IP隧道封装适合跨网段分发TUN模式IP Tunneling-i的原理是Director把原始IP包用IP-in-IP隧道重新封装一层发给RSRS解开隧道后发现里面目标IP还是VIP自己又绑了VIP就正常接收处理回程也走RS直回客户端。因为隧道封装可以让包“跳”过三层路由Director和RS可以不在同一网段甚至跨机房。但代价是每个包都要多一次封装/解封装CPU有额外开销而且所有RS要支持隧道协议且正确配置VIP的回环绑定。所以现实中用TUN的团队很少除非有跨网段的强需求否则优先DR。我自己通常把TUN理解为“为了跨网段放弃一点性能的DR变体”。2.4 三种模式的核心对比和选型建议模式NATDRTUN是否改IP是改目标IP否只改MAC是外层再封装一个IP回程是否经过Director是否否二层要求无Director和RS同网段可跨网段RS是否要绑VIP否是lo:0是lo:0性能最低最高中等生产使用率少极高极少选型建议很简单90%的场景无脑上DR前提是你有同网段的机器网络必须跨网段时才看TUNNAT用它做实验、学原理就好。3. 调度算法别背文档十个算法和业务场景的对照3.1 静态算法不看后端负载按规则硬分LVS内置了十种调度算法先分静态和动态两类。静态算法只按固定规则/权重分发不看RS当前连接数常见有RR、WRR、SH、DH四种RR轮询一个接一个轮流分适合后端配置完全一致的无状态服务WRR加权轮询给性能高的机器更大权重适合后端机器配置不齐的情况SH源地址哈希对客户端IP做哈希同一个源IP永远被分到同一台RS天然会话保持DH目标地址哈希对目标地址做哈希多用于多目标地址转发的场景实际用得不多。RR和WRR容易理解问题在于“不看负载”这件事如果一台RS处理得慢另一个RS已经空闲了RR还是机械地11分发。所以静态算法适合后端处理能力和瓶颈基本一致的服务比如纯静态资源的下载入口。3.2 动态算法看实时连接数按负载分配动态算法是面试常考的环节也是生产里真正有价值的部分算法全称核心逻辑适用场景LCLeast-Connections找连接数最少的RS后端处理能力接近WLCWeighted Least-Connections连接数/权重选值最小默认算法配置差异较大时SEDShortest Expected Delay考虑新连接预期延迟延迟敏感业务NQNever QueueSED基础上空闲RS优先本已有空闲机器时避免排队LBLCLocality-Based LC按目标IP做局部调度Cache类集群LBLCRLBLC with Replication支持缓存复制的局部调度分布式缓存命中率敏感WLC是LVS的默认算法也是我用的最多的。它的优势是把权重和实时连接数结合权重大的机器允许更多连接连接数多到一定程度后新请求自然会偏向更闲的机器。SED和NQ适合对时延很敏感的场景NQ算SED的一个优化版本——如果已经有空闲RS新请求就别再等了直接丢给空闲节点。LBLC/LBLCR则更冷门只在缓存集群里才能发挥价值普通业务不用动它们。3.3 会话保持与持久连接的实际配合很多人混淆SH算法和持久连接。SH是“永远按源IP哈希”只要RS列表不变同一个客户端总是去同一个RS而LVS的持久连接-p参数是“在一段时间窗口内把同一个客户端的请求都交给同一台RS”窗口一过就可能重新调度。使用示例# 创建一个持久连接600秒的VIP规则 ipvsadm -A -t 192.0.2.10:443 -s wlc -p 600 # 查看持久化信息 ipvsadm -L --persistent持久连接对本地Session、短时缓存命中这类场景很实用。比如你后端是几台没有做Session共享的应用服务器用户登录后需要在固定一台机器上保持状态那-p就很有必要。注意持久连接超时时间要按业务特点设置太大容易让RS之间负载不均衡太小又起不到会话保持作用。我习惯先给600秒观察一下连接分布再调整。4. 高可用配置与核心探活机制4.1 LVS自身不探活健康幻觉从哪来这是新手最容易踩的坑LVS内核只是转发机器它不检查RS是否存活。如果你只用ipvsadm加了一堆RS其中一台进程挂了LVS照样把包发过去客户端就会报连接超时。要解决“故障摘除”和“故障恢复”LVS自身是做不到的。生产里通常有两种做法一是交给专用的双机热备组件基于VRRP由它定期执行健康检查脚本脚本失败就自动把RS从规则里摘掉二是自己写脚本扫描。不管哪种核心都是“探活调规则”循环。探活不能只ping机器IP因为机器活着不代表业务活着——后面排障章节我会专门讲一个ping探活翻车的案例。4.2 主备Director的切换VIP漂移的本质Director本身是单点挂了的话整个入口就没了。所以生产里必须做Director双机甚至多机高可用原理是VRRP虚拟路由冗余协议。主备两个Director上都有一个VIP正常情况下只有主节点响应ARP和转发流量备节点通过心跳持续监控主节点状态。主节点故障后备节点接管VIP发出免费ARP广播让交换机把VIP的MAC地址更新到备节点从此流量走备节点转发。对客户端来说IP根本没变只是背后干活的人换了。这里有个关键点主备切换对已建立的TCP长连接完全是无感的吗不是。四层转发模式下连接表是跟着Director走的主备切换后备节点没有之前建立的连接记录那么长连接很可能断掉需要客户端重连。所以做高可用时要评估业务是否容忍短时重连不要天真地以为VIP漂移了连接就自动无缝保持。4.3 后端摘除与恢复的脚本化思路有了高可用组件框架真正决定服务质量的是健康检查脚本。我常用的探活思路很简单对RS的业务端口做TCP连接探测而不是只ping通。因为端口能立刻建立连接说明listen进程是活的ping通只能说明内核在响应。伪代码大致是这样while true; do for rs in 192.0.2.11 192.0.2.12; do # 尝试和RS的业务端口建立TCP连接 if timeout 1 bash -c echo /dev/tcp/$rs/80 2/dev/null; then # 存活不在规则里就加回来 ipvsadm -a -t 192.0.2.10:80 -r $rs:80 -g else # 故障先从规则里摘掉 ipvsadm -d -t 192.0.2.10:80 -r $rs:80 fi done sleep 2 done实际脚本要比上面复杂至少要有状态记录避免反复删除/添加还要区分“初次离线”和“长时间离线”做不同处理。另外一个经验是摘除RS时别直接ipvsadm -d硬删最好是先把权重改成0ipvsadm -e -t 192.0.2.10:80 -r 192.0.2.11:80 -g -w 0-w 0之后新连接不再分给这台RS但已建立的连接还能继续走完等连接数降到0再删除实现“平滑下线”。这个细节在平时升级后端服务时特别有用。5. 生产环境排障实录三个典型的LVS问题5.1 新增RealServer后全网访问开始“随机失败”有一次我给一个DR模式的集群加了一台新RS配置完ipvsadm规则后很快收到反馈部分用户访问正常部分用户访问超时而且越晚越看不出来规律。第一反应以为是新RS上的服务有问题查了半天日志服务明明是好的。后来在客户端一侧检查ARP表发现VIP对应的MAC地址不停在Director和新RS之间跳动。原因就是新RS的lo:0绑了VIP但忘了配置arp_ignore和arp_announce。外部设备发出“谁是VIP”的ARP广播时Director和新RS同时应答了不同客户端拿到不同MAC于是有的流量进了Director有的直接涌向了新RS。新RS如果业务正常那部分用户可能还能通但只要新RS有问题那部分用户就全完了。修复就是把新RS的ARP抑制参数补上重新下发规则之后全网ARP表重新收敛到Director问题立刻消失。这个案例的教训是DR模式下的RS配置ARP相关参数和VIP绑定是同等重要的漏一个都是灾难。5.2 健康检查只做ping失败的探活设计另一个比较典型的坑是探活方式太粗糙。某次团队里有人写了探活脚本每两秒ping一次后端的IPping通就认为机器活着。结果后端应用因为连接数打满进程进入了假死状态listen端口还在但已经不能正常accept新连接了。ping当然能通因为内核栈还活着TCP握手却迟迟无法完成。客户端连LVS入口没问题但包转发到这台RS之后就像进了黑洞。后来我把探活改成TCP端口探测并且要求必须在1秒内完成握手如果失败连续3次就把RS摘除恢复后连续2次成功再加回来。改完这套逻辑后类似故障基本都能在两三个心跳周期内摘掉。这里还想多说一句探活脚本里千万不要用ping VIP来探活RS。因为LVS的RS都会在lo上绑VIP你在RS本机ping自己的VIP实际上是ping到了lo接口上的本地地址通不通跟业务完全没有关系。5.3 ipvs连接表与timeout摘除节点后仍有流量还有一类问题容易被误解明明把某台RS从ipvsadm规则里删了为什么ipvsadm -L -n -c还能看到不少连接指向这台RS因为LVS有连接跟踪表已经建立的连接会继续按照原表转发不会因为规则删了就立刻掐断。正常来说这是合理行为——你不能要求正在下载的文件突然断掉。但如果你希望RS下架时连接快速收敛可以调整内核参数sysctl -w net.ipv4.vs.expire_nodest_conn1这个参数让连接在对应的RS不存在于规则里时立即过期避免残留在连接表里。另外可以通过ipvsadm -L --timeout查看三类连接的超时时间默认一般是TCP 900秒、TCP FIN 120秒、UDP 300秒。如果业务短连接居多适当调小可以加快连接表回收减小内存和哈希表压力。6. 与七层代理的边界LVS不是万能的6.1 四层转发与七层代理的核心区别很多人问我LVS和Nginx都有负载均衡为什么还要两套一起用回答这个问题要先分清它们的本质区别。LVS工作在四层传输层它能看到的是IP、端口、协议号不关心包里面装的是HTTP还是MySQL协议更不知道URL路径和cookie。Nginx这类七层代理工作在应用层能解析HTTP头部按域名、路径、请求头、Cookie做转发决策。维度LVSNginx/HAProxy工作层级四层传输层七层应用层转发粒度IP端口URL/HOST/Header/Cookie性能高内核态转发稍低用户态解析业务感知无强典型用途海量流量入口应用层路由、缓存、限流性能差异的根本原因在于LVS在内核态只是一个改包动作不涉及系统调用、进程调度和用户态拷贝七层代理每处理一个请求都要做完整的数据包拷贝和协议解析CPU开销完全不是一个量级。6.2 经典的LVS加Nginx分层负载架构生产里更聪明的做法是把两者组合成“LVS做入口Nginx做业务路由”的分层架构客户端 - LVSVIPDIP分发 - Nginx集群七层路由、限流、静态缓存 - 后端应用集群LVS只干一件事把巨大的连接流量平均分给下面的Nginx节点Nginx节点再根据自己的业务规则比如按Host转发到某个服务、按URL后缀做动静分离把请求送给合适后端。这样LVS不用懂业务Nginx也不用和几万并发硬碰硬。这套架构我在好几个项目里都验证过流量入口的稳定性非常好而且LVS故障域很小出问题也好排查。6.3 什么情况下不需要LVS如果后端只有一两台机器业务本身依赖七层路由比如一台机器要同时服务三个域名、每个域名路径不同或者团队里没人熟悉LVS的运维那确实没必要上LVS。Nginx做四层转发也能用只是性能上限低一些。LVS不是一个“必须用”的东西它是你在流量大到用户态代理撑不住之时真正的性价比选择。7. 从LVS到DPDK四层网关负载均衡技术的演进方向7.1 LVS的上限在哪里LVS虽然强但也不是无限。它依赖内核网络栈处理包在单机上会有CPU中断、锁竞争、内存拷贝这些天然开销。一台通用服务器的LVS转发能力能到几个Gbps甚至更高但面对10Gbps以上的单点流量或者极其变态的并发连接数就会开始吃力。过去这种超高场景都是靠专业硬件负载均衡设备扛价格也贵。软件方案的路线则发展到DPDK这类用户态包处理技术绕过内核协议栈用大页内存、轮询模式、无锁队列把包处理的每一环都搬到用户态自己控制。7.2 绕过内核的DPDK方案性能更高但复杂度也高基于DPDK的四层负载网守单机转发能力可以轻松上到几十Gbps甚至更高代表作就是DPVS这类项目。它算是“LVS思路的DPDK重写版”VIP、转发模式、调度算法的思想基本一脉相承但底层包处理路径完全不同。不过DPDK方案不是银弹。它需要专门绑核、规划大页内存、编程网卡队列运维和开发门槛比LVS高一大截而且用户态轮询会占满CPU虚拟机上很难发挥优势。所以我的建议很实际传统的LVS在绝大多数物理机场景仍然够用不用为了追新而迁移但如果你的业务就是纯四层超大流量入口又有能力维护DPDK方案那它是LVS之后值得研究的下一代路线。8. 用好LVS离不开的几个运维习惯最后分享几个我在实际使用中沉淀下来的习惯不一定写进文档里但对稳定性和效率影响很大。第一是规则一定要可恢复。手工敲的ipvsadm规则重启之后全部消失。我的习惯是把规则存成独立脚本或者让高可用组件在启动时自动拉起来。每次变更后执行一遍ipvsadm-save留一个可回溯的快照。第二是排障先抓包再改配置。LVS出问题时第一件事不是猜而是去Director和对应的RS上用tcpdump分别抓包。看包是不是进来了、有没有被分发、RS有没有回应。四层问题基本都在包路径上抓包能直接把问题定位到节点比自己瞎改参数快得多。第三是多关注内核参数的连带影响。比如Director上如果开了防火墙或者启用了反向路径过滤有可能出现包到了Director却被莫名丢弃的情况。遇到“转发不出去”的诡异问题先把防火墙临时关掉、把net.ipv4.conf.all.rp_filter改成0试试能帮你快速缩小排查范围。第四是变更顺序。升级后端或者替换RS时永远遵循“先降权重、再等连接收敛、最后删除”的顺序加新RS时先把服务和ARP配置验证没问题了再加ipvs规则。这个习惯避免了很多线上事故。LVS这套东西原理说透了其实不复杂难点全在细节模式选型、ARP抑制、探活脚本、连接表超时。把这些细节一点点吃进去再用排障手段把异常场景验证一遍就算是真正掌握了它。

LVS负载均衡原理与实战：从IPVS内核转发到高可用架构

相关推荐

Agent模型选型指南：从聪明到敢用的七个硬指标

发电厂配电室巡检机器人落地：从试点到标配的五项关键经验

uni-app微信小程序外卖闭环：端侧AI+微信支付完整实现

更多资讯

上下文工程实战：6个核心问题玩转Token预算与上下文管理

AI辅助写专著：人机协同全流程实操指南

核电设备管理数字化路径：EAM为基、全生命周期数据贯通

AI辅助教材编写：从查重原理到原创合规的完整实践

深入解读GIC400中断控制器：架构、寄存器与Linux内核实战

Git新手实战：从身份配置、SSH密钥到分支合并的完整流程

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？