本文不聊配置命令的复制粘贴而是把LVS负载均衡集群这套理论完整梳理一遍。适合刚接触集群概念、准备做负载均衡选型、或者面试前想把LVS彻底搞明白的读者。我会把三种工作模式、调度算法、高可用机制这些核心内容讲透同时穿插一些实际部署中的取舍和坑帮你建立一套可落地的知识框架。1. 负载均衡集群的全貌LVS在其中扮演什么角色1.1 集群的分类与LVS的定位把多台服务器组织起来对外提供同一类服务这就是集群。根据目标不同集群通常分三类高可用集群解决“挂了怎么办”高性能计算集群解决“算得够不够快”负载均衡集群解决“请求分给谁处理”。LVSLinux Virtual Server属于负载均衡集群工作在网络四层传输层核心作用是把进入的流量按照预设策略分发到后端的多台真实服务器上。说直白点它就是大门口的保安把访客分流到不同的服务窗口既不让某个窗口挤爆也不让某个窗口闲着。在真实架构里LVS通常处在整个系统的入口位置前面接公网或机房交换机的流量后端挂着一组业务服务器。它处理的是TCP/UDP请求的转发不关心HTTP请求里具体是哪个URL、Cookie是什么这是它和七层负载均衡最本质的区别。1.2 LVS与Nginx、HAProxy的分工经常有人把LVS和Nginx、HAProxy放在一起比较其实它们并不完全是替代关系。Nginx和HAProxy主要工作在七层能根据HTTP头、URL路径、Cookie等应用层信息做精细化路由LVS工作在四层只根据IP和端口转发数据包。生产环境里更常见的做法是分层配合LVS放在最前面扛大流量把请求分发到一组Nginx或业务网关网关层再做七层路由和业务逻辑处理。因为LVS在内核态完成转发不涉及用户态的数据拷贝和分析吞吐能力和并发处理能力都非常强性能天花板明显高于纯用户态软件。1.3 LVS的核心组成模块LVS这套体系由几个关键部分组成ipvs是内核里的IP虚拟服务器模块也是LVS真正干活的引擎ipvsadm是用户态管理工具用来定义虚拟服务器和调度规则VIP是虚拟IP客户端访问的就是这个IP后端的服务器称为Real ServerRS一组RS加上它们之间的调度规则组成了一个完整的LVS集群。理解LVS的架构时脑海里要有这张简化的请求链路图客户端访问VIP请求到达Director调度器的网卡内核的ipvs模块按照调度算法选出一台RS然后完成数据包的改写和转发。所有调度逻辑都内嵌在内核协议栈中这既是LVS高效的根本原因也决定了它只能做四层转发。2. 三种工作模式的理论基础与取舍2.1 NAT模式最直观的流量转发NAT模式的核心是网络地址转换。客户端把请求发给VIPDirector收到后根据调度算法选出一台RS然后把数据包的目标地址改写为RS的IP并转发出去。RS处理完请求后把响应包发回给Director因为RS把Director当成网关Director再将源地址改回VIP还给客户端。在这个过程中请求和响应都必须经过Director。这带来一个直接后果Director成为流量瓶颈。入站流量和出站流量都压在它一张网卡和一颗CPU上。我见过不少初期方案选NAT模式的团队流量一上来Director的CPU和网卡先被打满RS的负载还没上去。NAT模式适合RS和Director在同一网段、且对性能要求不极致的场景相当于用一台机器做流量中转站。但必须开启IP转发功能否则数据包到了Director就被丢弃。另外注意NAT模式下Director必须配置为RS的网关RS的默认路由要指向Director否则响应包无法正确回程。2.2 DR模式生产环境的主流选择DR模式直接路由是生产环境中使用最多的LVS工作模式性能接近物理上限。它的原理是Director只处理入站请求把数据包的目标MAC地址改成RS的MAC地址在二层网络内直接发给RS。RS处理后响应包绕过Director直接以VIP作为源地址返回给客户端。这里有个关键问题需要解决客户端的请求目标是VIPRS收到的数据包目标IP是VIPRS怎么知道自己应该接收并处理这个包答案是在每台RS的lo接口loopback上配置VIP同时抑制ARP响应。否则RS会把VIP回答给网络里的ARP请求造成IP冲突和路由混乱。具体配置要求是在RS上设置arp_ignore1和arp_announce2含义是只回答目标IP是本机网络接口IP的ARP请求且对外通告时必须用本机的IP而非VIP。不调整这两个参数LVS集群根本跑不起来要么网络异常要么客户端请求被某台RS直接抢答。DR模式避免了响应流量经过Director所以Director的负载压力大幅下降。但它也有个限制Director和所有RS必须在同一个二层网络里无法跨网段调度。如果你的后端服务器分散在不同机房DR模式的物理拓扑就不成立了。2.3 TUN模式跨越网段的隧道方案TUN模式的全称是IP隧道原理是Director把客户端请求封装在一个新的IP包中源IP是Director目标IP是RS通过隧道发给远端的RSRS解封装取出原始请求包处理然后直接把响应包发回客户端。TUN模式解决了DR模式跨网段的问题适合后端RS分布在多个机房的场景。但封装和解封装都有额外开销对网络质量要求更高实际使用频率远低于DR模式。除非你的调度器与RS确实跨地域、跨机房否则我一般不推荐首选TUN。这三种模式的选择本质上是在性能、网络拓扑和实现复杂度之间做权衡。对比项NAT模式DR模式TUN模式响应包路径经过Director直接返回客户端直接返回客户端后端网络要求同一网段同一二层网络可跨网段Director压力高进出都走低只进不出中有封装开销RS配置要求默认路由指Directorlo配VIP抑制ARP支持IP隧道典型场景小规模、初期验证大规模、高性能入口多机房分布式RS2.4 工作模式背后的网络要点做LVS方案时网络层面有几个核心点直接决定能不能成功。VIP必须是公网可达的IP或者至少是业务网段内客户端能访问到的IP否则请求到不了DirectorRS的VIP配置必须在回环接口而非物理网卡上并配合ARP抑制参数交换机端如果做了严格的端口安全、防MAC欺骗策略DR模式可能需要额外放通否则RS发出的包会被交换机丢弃。第二个容易踩坑的是sysctl参数。不管是哪种模式Director都需要开启net.ipv4.ip_forward1。NAT模式的RS需要确认IP转发未开启RS不需要转发但默认路由必须指向DirectorDR模式的RS要确保物理网卡不要配置VIP避免误答ARP。这些细节在测试环境不太容易暴露一旦上到生产网络任何一项配置错误都会表现为大面积请求超时或网络风暴排查起来成本很高。所以我在搭建LVS环境的第一步永远是跑通最小联通性验证VIP能ping通、RS能ping通、客户端能通过VIP访问到RS上的业务然后再做调度配置。3. 调度算法从轮询到最少连接3.1 静态算法轮询、加权轮询与哈希静态调度算法不考虑后端服务器的实时负载规则固定、逻辑简单。轮询RR把请求按顺序轮流分给每台RS每台RS收到的请求数几乎一样适合后端机器配置齐整、业务处理耗时接近的场景。加权轮询WRR给每台RS配置权重比如性能强的机器权重设为3弱的设为1请求就会按3:1的比例分配。哈希类算法包括目标地址哈希DH和源地址哈希SH。DH根据目标IP的哈希值分配RS常用于多级调度场景SH根据客户端源IP的哈希值分配RS相同客户端的请求始终落到同一台RS上。源码地址哈希在无状态服务场景里天然实现了会话保持但要注意如果某个客户端IP的请求量特别大哈希会造成严重的倾斜把一台RS打满。3.2 动态算法根据连接数做决策动态调度算法会实时感知每台RS的当前连接数把新请求分给负载更低的机器。最基础的是最少连接LC选择当前连接数最少的RS。加权最少连接WLC在此基础上引入权重计算连接数除以权重选择结果最小的RS。WLC是很多LVS配置里的默认算法综合了权重和实时负载两个维度适应性很强。另外两个算法值得单独说。SED最短预期延迟考虑的是连接数加1之后除以权重它比WLC更敏感在RS权重差距较大的场景下能减少“重机器被轻权重拖慢”的问题。NQ永不排队是SED的改进版基本策略是在RS有空闲连接时直接分配没有空闲才使用SED。动态算法里还有两个针对缓存场景的变种LBLC基于局部性的最少连接会根据目标IP找出最近使用的RS适合缓存集群LBLCR带复制的基于局部性的最少连接会维护一个目标IP到服务器组的映射组内再选最少连接的RS。这两个算法在缓存场景里很实用但配置相对复杂。3.3 根据业务特征选择合适的算法算法没有绝对的哪个最好只有哪个更贴合业务特征这是我反复强调的一点。如果后端是短连接业务比如一次API请求几毫秒就结束RS之间的资源消耗比较均匀WRR就够用了。如果后端是长连接业务比如WebSocket、游戏长连接、数据库连接池连接数直接反映压力建议用WLC或SED。如果同一客户端必须稳定打到同一台RS比如有状态服务优先用SH算法或在虚拟服务器上开启持久性persistence确保固定时间窗口内同一源IP绑定到同一RS。我实际部署中经常这样组合入口层用LVS的WLC算法做通用分发会话保持交给SH算法或持久性参数七层应用层再做细粒度的路由。这样既保证压力均衡也保留了有状态服务的会话约束。需要提醒的是切换调度算法通常会导致一部分现有连接被重置因为LVS的连接跟踪表项是按旧算法建立的。如果你在业务高峰做算法调整要评估连接闪断的风险。4. 高可用、健康检查与Keepalived如何补完LVS4.1 没有健康检查的LVS是非常脆弱的LVS本身只管转发它并不关心后端RS是否还活着。如果某台RS宕机LVS依然按原调度策略把请求转发过去结果就是这批请求全部失败。实际生产环境中RS挂掉是常态所以健康检查机制是LVS方案里绝对不可缺失的一环。Keepalived承担两个核心职责为Director提供高可用能力同时实现对后端RS的健康检查。它通过VRRP协议让两台Director组成主备关系主节点持有VIP并处理流量备节点实时监控主节点状态主节点故障时备节点接管VIP整个集群对外地址不变客户端无感知。健康检查的实现方式很多TCP端口探测、HTTP状态码探测、脚本自定义探测等。常见的坑是探测频率设置不当——太频繁会给RS带来额外压力太慢则故障切换不及时。我的建议是健康检查间隔设置在2到3秒之间连续2次失败即标记RS为不可用连续2次成功再恢复上线既保证敏感度又避免抖动。4.2 VRRP协议与脑裂风险VRRP的原理可以理解为一组设备竞争同一个虚拟IP的“持有权”持有VIP的设备定期发送心跳通告。优先级高的设备优先持有VIP优先级相同则比较IP大小。Keepalived底层就是利用VRRP在集群节点间传递状态。脑裂指的是主备两台Director都认为自己应该持有VIP同时对外应答造成网络路由混乱。常见诱因是心跳线网络拥塞或震荡导致备机收不到主机的通告备机误判主机故障后强行抢占VIP。预防脑裂的措施包括使用独立的物理网卡或专用心跳链路、在Keepalived配置里设置较合理的通告时间、必要时引入仲裁机制比如通过第三方接口判断是否接管。一旦怀疑脑裂登录两台Director检查VIP和Keepalived日志就能立刻确认。4.3 双Director的经典拓扑生产环境里最经典的LVS高可用拓扑是两台Director组成主备共享同一VIP通过Keepalived做状态同步多台RS挂在同一个二层网络中通过健康检查动态调整参与调度的节点。需要注意一个细节Director与RS之间如果在两个不同网段通信必须依赖路由这在DR模式下不成立。所以实际设计中我会把VIP规划在业务网段里Director物理网卡和RS都在同一网段备机只保留VIP的接管能力平时不参与转发。备份节点上也配置相同的ipvs规则这样接管后无需重新加载规则就能直接工作。健康检查脚本在复杂业务里经常需要定制。比如某RS虽然TCP端口能连通但应用层状态异常Keepalived默认只能检测端口这时可以用curl或自定义脚本探测特定URL。我的经验是把健康检查脚本写得很克制——只判断核心接口的返回码不要把业务逻辑全量跑一遍否则检查本身会拖垮RS。4.4 会话保持与状态同步LVS做四层转发时同一个TCP连接只会被路由到同一台RS前提是调度算法和连接跟踪表保持一致。但如果客户端断开重连新连接可能被调度到另一台RS这对无状态服务没有影响对有状态服务就是问题了。四层层面的会话保持方案有两种一是使用SH算法根据源IP固定RS二是在虚拟服务器上定义持久性时间比如ipvsadm -p 600表示600秒内同一源IP的请求都发给同一台RS。这两种方式实现简单但如果客户端通过代理池访问大量真实用户会共享同一个源IP造成严重的负载倾斜。七层层面的会话保持通常由应用层解决比如把Session放入Redis等共享缓存让请求无论打到哪台RS都能读到同一份会话数据。这是分布式架构更推荐的解法LVS只负责高效的流量分发有状态数据交给后端统一的存储层。5. 真实场景中的实践思考与踩坑记录5.1 四层与七层如何搭配实际部署中很少只用一层负载均衡。我搭建过的典型架构是LVSDR模式 Nginx集群 业务应用集群。LVS把来自公网的流量分发到Nginx节点Nginx再根据访问路径、域名、Header做七层路由转发给对应的业务RS。这个结构的好处是职责清晰LVS负责入口流量分发凭借内核转发获得极高吞吐Nginx层负责应用层路由、缓存和基础安全过滤能力边界很明确。弊端是多一层就多一份延迟和故障可能所以Nginx节点通常也要做高可用要么由LVS的健康检查自动摘除故障节点要么在Nginx层再做一层VIP。在流量规模没有达到一定量级时直接用Nginx或HAProxy做入口负载均衡可能更省事不必为了用LVS而引入额外的运维复杂度。只有当单机处理能力成为瓶颈或者你对入口吞吐有极端要求才需要把LVS放到架构最前端。5.2 内核参数与性能调优的几个要点LVS虽然高效但性能上限同样受内核参数约束。最容易出问题的是TCP连接跟踪表nf_conntrack_max一旦超过默认值新连接会被丢弃表现就是流量稍大时出现间歇性超时。建议在大流量节点上根据内存大小调大该参数并开启nf_conntrack_tcp_timeout_established的合理回收时间。另一个经典坑是tcp_tw_recycle。这个参数在老内核版本里用于快速回收TIME_WAIT连接但开启后会导致NAT环境下的TCP时间戳校验异常大量客户端连接被重置。现在的Kernel版本已经移除了该参数但在老版本系统上做LVS时一定不要迷信网上教程盲目开启它。此外不要把tcp_tw_reuse与tcp_tw_recycle混淆前者在客户端场景可用后者在LVS入口场景基本是毒药。高并发场景还需要关注网卡队列、中断绑定和CPU亲和性。多队列网卡配合RPSReceive Packet Steering或SMP IRQ affinity可以把网络中断分散到多核CPU避免单核处理瓶颈。对于极致性能的配置我建议预留足够的CPU给软中断处理不要让业务进程和网络中断在同样的核心上抢资源。5.3 经典故障排查思路总结排障时先画清楚数据链路再逐段排查不要一上来就抓包分析。如果客户端完全无法访问VIP先确认Director上的VRRP是否正常VIP是否真的在当前节点上用ip addr查看。如果VIP正常但转发异常确认后端RS的健康检查状态用ipvsadm -L -n查看Real Server的状态是否Active。如果只有部分客户端异常考虑是否出现ARP问题——用arping检查VIP的MAC地址是否正确落在Director网卡上如果在RS的网卡上就应该检查ARP抑制参数。遇到过几次特别隐蔽的问题印象最深的是RS的物理网卡配置了同网段IP导致ARP表混乱、请求被随机分发到错误的RS。排查了很久才发现是配置规范问题。后来我在所有RS部署脚本里强制检查物理网卡所有IP禁止与VIP同网段VIP只能配置在lo接口。这类问题一旦根治集群的稳定性会明显上一个台阶。5.4 理论之外的工程心得最后分享一点个人的工程体会。LVS的理论看起来不复杂但真正把一套LVS集群稳定跑在生产环境靠的往往是细节规范清晰的IP规划、统一的RS初始化脚本、完整的健康检查策略、及时的监控告警以及最重要的——变更前的演练。我见过不少集群故障不是LVS本身不行而是配置漂移、参数被误改、网络规划混乱导致的问题。理论掌握得越扎实遇到问题时越能快速定位方向。比如看懂DR模式下ARP抑制的原理就能在回环地址配置错误时立刻判断出症状理解了调度算法适用场景就能在业务形态变化时主动调整策略而不是等用户反馈故障才被动介入。希望这套理论梳理对你有用能让你在规划自己的LVS负载均衡集群时少走一些弯路。