文章目录一、集群与分布式基础1.1 系统性能扩展方式1.2 集群的三种类型1.3 集群 vs 分布式——面试高频题二、LVS 架构原理2.1 LVS 是什么2.2 核心概念五个 IP2.3 四种工作模式——LVS 的精华NAT 模式DR 模式直接路由TUN 模式隧道FullNAT 模式四种模式总结三、调度算法详解3.1 静态调度算法3.2 动态调度算法3.3 内核 4.15 新增的两个算法四、NAT 模式实战4.1 实验环境4.2 逐步配置4.3 改为加权轮询4.4 规则持久化五、DR 模式实战5.1 实验拓扑5.2 核心难题ARP 抑制5.3 调度器配置5.4 NAT vs DR 实战心得六、防火墙标记FWM——多端口的救星6.1 问题的本质6.2 解决方案七、持久连接——让用户不掉线7.1 问题场景7.2 LVS 的持久连接方案八、LVS Keepalived 高可用概述8.1 问题来了8.2 Keepalived 怎么解决九、ipvsadm 命令速查集群服务管理RS 管理查看 调试关键文件总结学习心得这篇文章是 LVS 负载均衡的完整学习笔记。从为什么需要集群开始到四种工作模式的底层原理再到亲手搭建 NAT 和 DR 模式的全过程以及踩过的坑和总结的经验。希望能帮你建立起对 LVS 的系统认知。一、集群与分布式基础1.1 系统性能扩展方式在学习 LVS 之前先想清楚一个问题当一台服务器扛不住流量了怎么办答案只有两个方向Scale UP向上扩展给服务器加配置——换更强的 CPU、加更多内存、上 SSD。这就像给一个人吃更多蛋白粉让他变得更强壮。简单粗暴但问题是物理上限摆在那里你不可能无限加而且越往上走同样性能提升的成本是指数级增长的。一台 128 核的服务器价格可能是 4 台 32 核的 5 倍以上。Scale Out向外扩展买更多服务器用集群技术把它们组合起来对外提供服务。这就像不指望一个超人干所有活而是雇一群人分工协作。单台配置不用很高但整体能力可以线性增长。这也是互联网公司的主流选择——用廉价机器堆出高可用。LVS 正是 Scale Out 模式下最经典的负载均衡方案。它不是跑在应用层的而是直接跑在 Linux 内核里所以性能极高、几乎不消耗资源。理解了这个大背景后面学起来才有方向感。1.2 集群的三种类型集群Cluster说起来就是把多台机器绑在一起用但其实有三种完全不同的目的类型核心目标一句话理解典型实现LB负载均衡分散流量一个人忙不过来多找几个人一起干Nginx、HAProxy、LVSHA高可用消除单点故障主力挂了备胎立刻顶上Keepalived、PacemakerHPC高性能计算并行计算把一个大任务拆成小任务同时算超算中心小结实际生产环境中LB 和 HA 往往是配合使用的。比如一个典型的架构两台 LVS 调度器通过 Keepalived 做 HA一主一备下面挂着一堆 Nginx 做七层反向代理LB再后面才是真正跑业务的应用服务器。每一层都在用集群解决自己的问题。关于高可用有几个关键指标值得关注MTBFMean Time Between Failure平均多久出一次故障——越长越好MTTRMean Time To Restoration出故障后平均多久能恢复——越短越好可用性 MTBF / (MTBF MTTR)比如一年出一次故障、每次 1 小时恢复可用性 ≈ 99.99%四个九SLAService Level Agreement这是跟客户/老板签的服务协议达不到就挨罚。运维的核心 KPI 就是这个。 一个容易被忽略的点计划内停机比如发版重启也计入 SLA。所以真正的高可用架构必须支持滚动发布不能停服升级。1.3 集群 vs 分布式——面试高频题这两个概念刚开始学很容易搞混整理了一个对比维度集群Cluster分布式Distributed核心逻辑同一个活多个人一起干不同的活每人负责一部分每台机器代码和数据都一样代码和数据不一样合起来才完整提升什么单位时间内能处理更多请求吞吐量单个请求处理更快响应速度挂了怎么办一台挂了其他顶上服务不受影响一个节点挂了它负责的那部分功能就废了打个比方集群像快餐店的 3 个收银员——干的活一模一样一个请假了还有两个顶着。分布式像一条流水线——切菜的、炒菜的、打包的各管各的切菜的走了整条线就停了。大型网站的经典架构前端LVS四层集群→ 中间Nginx 集群七层→ 后端应用服务器集群。每一层都是集群但层与层之间又是分布式的协作关系。二、LVS 架构原理2.1 LVS 是什么LVSLinux Virtual Server是 Linux 内核里自带的负载均衡模块由中国人章文嵩博士在 1998 年开发后来被收入了 Linux 内核标准主线。值得一提——全球无数服务器跑着的四层负载均衡核心代码是中国人写的。阿里云的四层 SLBServer Load Balancer底层就是LVS Keepalived。你如果在阿里云买过 SLB其实就是在用 LVS。几个核心组件的关系ip_vs内核模块真正干活的——截获数据包、查表、改包头、转发。运行在内核态。ipvsadm用户空间的命令行工具用来给内核模块下发规则。类似 iptables 和 netfilter 的关系。/proc/net/ip_vs内核暴露的 proc 文件可以 cat 出来看当前有哪些调度规则。/proc/net/ip_vs_conn当前所有活跃连接的表排查问题时非常有用。小结LVS 本质上就是一个内核级的数据包转发器。它不看 HTTP Header不管 URL 是什么只管 IP 和端口——所以叫四层负载均衡。也是因为它工作在内核态、只做最简单的包头修改所以性能可以达到线速转发比 Nginx 这种跑在用户态的七层代理快一个数量级。2.2 核心概念五个 IP这五个概念贯穿整个 LVS 学习过程必须记牢缩写全称在哪个设备上一句话CIPClient IP客户端发起请求的真实用户 IPVIPVirtual Server IP调度器对外对外暴露的地址客户端访问这个DIPDirector IP调度器对内调度器和后端 RS 通信用的内网 IPRIPReal Server IP真实服务器真正处理请求的后端服务器 IPVSVirtual Server调度器整个调度系统的大脑数据包怎么走的CIP ←→ VIP DIP ←→ RIP客户端只认识 VIPRS 只认识 DIP。调度器在中间做翻译——这里面最核心的就是怎么把发给 VIP 的包变个方式交给 RIP。四种工作模式的区别归根结底就是翻译方式不同。2.3 四种工作模式——LVS 的精华这是 LVS 最难但也最重要的部分。需要花时间才真正理解每种模式的数据流。NAT 模式本质多目标 IP 的 DNAT。调度器把请求包里的目标地址从 VIP 改成 RIP然后把 RS 回包里的源地址从 RIP 改回 VIP。客户端 → VS → RS改目标IP RS → VS → 客户端改源IP小结NAT 模式最好理解——调度器就像一个翻译官请求进来翻译一遍响应出去再翻译一遍。优点是可以做端口映射比如 VIP:80 → RIP:8080缺点是进出都要经过调度器当后端 RS 多了以后调度器自己会成为瓶颈。⚠️ 重要RS 的网关必须指向 DIP否则 RS 回包不经过调度器调度器没法把源 IP 从 RIP 改回 VIP客户端收到一个不认识的回包就直接丢了。DR 模式直接路由本质不碰 IP 层只改 MAC 地址。调度器把请求包的目标 MAC从自己的 MAC 改成某台 RS 的 MAC然后原样扔到交换机上。客户端 → VS改目标MAC为RS的MAC→ RS RS → 客户端直接回不经过VS小结DR 模式是 LVS 的精髓。关键洞察响应流量通常比请求流量大得多用户请求一个几十字节的 URL服务器回一个几 MB 的页面所以让响应直接回客户端、不经过调度器调度器的吞吐能力就释放出来了。但也带来了一个问题RS 必须也有 VIP否则 RS 收到的包目标 IPVIP而 RS 自己的 IPRIP会直接丢弃。既然 RS 也有 VIP那就又有个新问题客户端发 ARP 问谁有 VIP“的时候调度器和所有 RS 都会回答在这”——这就乱套了。所以必须让 RS抑制 ARP 响应后面实战部分会详细讲怎么做。TUN 模式隧道本质在原 IP 包外面再套一层 IP 头。外层DIP→RIP用来在网络上路由内层CIP→VIP原封不动。小结TUN 模式的核心价值是可以跨网络。DR 要求调度器和 RS 在同一个二层网络但 TUN 不需要——只要 IP 能通就行。所以它适合做异地负载均衡。代价是 RS 必须支持 IPIP 隧道协议。FullNAT 模式本质同时改源 IP 和目标 IP。CIP→DIP、VIP→RIP。这个模式是淘宝/阿里内部开发使用的解决了一个问题RS 看到的源 IP 是 DIP 而不是真实客户端 IP。好处是 RS 不需要特殊配置坏处是 RS 日志里全是 DIP排查问题很麻烦。⚠️ FullNAT 需要给内核打补丁主线内核不支持。一般除非你在阿里云上做深度定制否则用不到。四种模式总结特性NATDRTUNFullNATRS 要求无需禁 ARP需支持隧道无跨网段✅❌✅✅端口映射✅❌❌✅回包经调度器是压力大否压力小否是推荐场景小规模/异构环境主力方案异地容灾阿里内部选择建议绝大多数场景直接用 DR。除非 RS 是 Windows不好配 ARP 抑制、或者需要做端口映射才考虑 NAT。TUN 和 FullNAT 属于进阶场景。三、调度算法详解ipvs 的调度算法核心分两类静态不考虑 RS 实时负载纯算法和动态根据 RS 当前连接数等指标来判断。3.1 静态调度算法算法逻辑什么时候用RR轮询1→2→3→1→2→3…依次来RS 配置完全相同时用WRR加权轮询按权重比例分配RS 配置不同时比如一台 8C 一台 4C权重 2:1SH源地址哈希同一客户端 IP → 同一 RS需要会话保持但又不想用持久连接DH目标地址哈希同一目标 URL → 同一 RS正向代理缓存场景比如运营商缓存小结RR 和 WRR 是最基础也最常用的。但要注意RR 在 RS 性能差异大时会出问题——性能差的机器被分配同样多的请求响应变慢拖垮整体体验。所以实际生产中加权几乎是一个必选项哪怕所有 RS 配置相同也设一样的权重至少保留以后调整的灵活性。SH 算法听起来很美好但它有个致命缺点如果某个客户端 IP 后面其实是一个 NAT 网关比如公司的出口 IP那成百上千个不同用户都会被哈希到同一台 RS导致负载严重不均衡。3.2 动态调度算法这是 LVS 真正智能的地方——它不仅看算法还看每台 RS 的实时负载算法核心逻辑适用场景LC最少连接谁连接少调度给谁长连接场景数据库代理、WebSocketWLC加权最少连接LC 权重修正默认算法通用场景最推荐SED最短预期延迟初始阶段高权重优先权重差异大时避免低权重机器饿死NQ永不排队第一轮每人一个之后 SED避免第一波请求全砸到高权重 RSLBLC本地最少连接动态 DH 负载感知正向代理LBLCR带复制的 LBLCLBLC 热点复制解决 LBLC 单点过热小结WLC 作为默认算法是有道理的——它在最少连接的基础上加入了权重修正既考虑了实时负载又考虑了机器性能差异。一般不需要改除非有特殊需求。SED 有个坑如果 RS1 权重1、RS2 权重10前 10 个请求全打到 RS2 上RS1 啥也不干。这就是 NQ 算法存在的意义——它强制第一轮均匀分配。3.3 内核 4.15 新增的两个算法这两个算法比较新但在特定场景非常实用FOFail Over可以手动标记某台 RS 为过载状态调度器会跳过它。这个在做灰度发布时特别有用——先把一台 RS 标记过载等它上面没连接了再下掉平滑无感知。OVFOverflow Connection连接数超过权重值就不再调度。相当于给每台 RS 设了一个最大承载量。四、NAT 模式实战这一节完整记录了搭建 NAT 模式的全过程。建议动手做一遍很多东西光看是看不懂的。4.1 实验环境用 4 台虚拟机模拟了整个环境网络规划公网段172.25.254.0/24客户端和 VS 的外网侧内网段192.168.0.0/24VS 的内网侧和所有 RS各主机角色与 IP 配置主机角色网卡/接口IP 地址网关说明client测试客户端eth0172.25.254.104—从公网发起请求VS调度器eth0外网172.25.254.100—VIP客户端访问这个地址eth1内网192.168.0.100—DIP跟 RS 通信RS1真实服务器eth0192.168.0.101192.168.0.100网关指向 DIPRS2真实服务器eth0192.168.0.102192.168.0.100网关指向 DIP数据流向客户端 → VS(eth0/VIP) → VS 改目标IP → VS(eth1) → RS → 回包经 VS → 客户端 配置要点速记VS 双网卡一个对外挂 VIP一个对内连 RSRS 网关必须指向 DIP——NAT 模式回包要经过 VS 做源地址转换不然后端回包客户端不认识RS 不需要外网纯内网就行4.2 逐步配置① 开启内核路由转发echonet.ipv4.ip_forward1/etc/sysctl.d/ip_forward.confsysctl--system 为什么要开这个NAT 模式下 VS 要充当路由器——从一个网卡收到包改完包头后从另一个网卡发出去。如果 ip_forward0Linux 收到非本机的包会直接丢弃。② 安装 ipvsadmyuminstallipvsadm-y③ 添加调度规则# -A: 添加集群服务 -t: TCP协议 -s: 调度算法ipvsadm-A-t172.25.254.100:80-srr# -a: 添加RS -r: RS地址 -m: NAT模式ipvsadm-a-t172.25.254.100:80-r192.168.0.101:80-mipvsadm-a-t172.25.254.100:80-r192.168.0.102:80-m NAT 模式的关键参数是-mmasquerade伪装。DR 模式用-ggatewayTUN 模式用-iipip。容易搞混记忆诀窍masqueradeNAT 的伪装gatewayDR 的网关ipipTUN 的隧道。④ 查看规则ipvsadm-Ln# IP Virtual Server version 1.2.1 (size4096)# Prot LocalAddress:Port Scheduler Flags# - RemoteAddress:Port Forward Weight ActiveConn InActConn# TCP 172.25.254.100:80 rr# - 192.168.0.101:80 Masq 1 0 0# - 192.168.0.102:80 Masq 1 0 0注意 Forward 列显示Masq说明工作在 NAT 模式。⑤ 测试forNin{1..6};docurl172.25.254.100;done# RS2 server - 192.168.0.102# RS1 server - 192.168.0.101# RS2 server - 192.168.0.102# RS1 server - 192.168.0.101# RS2 server - 192.168.0.102# RS1 server - 192.168.0.101完美轮询 ✓4.3 改为加权轮询现实中后端服务器配置不太可能完全一样加权就很重要# 修改调度算法为 WRRipvsadm-E-t172.25.254.100:80-swrr# RS1 权重 2RS2 权重 1——RS1 会承担约 2/3 的流量ipvsadm-e-t172.25.254.100:80-r192.168.0.101:80-m-w2ipvsadm-e-t172.25.254.100:80-r192.168.0.102:80-m-w1测试结果RS1 RS1 RS2 RS1 RS1 RS2 ← RS1 明显分配更多4.4 规则持久化这是容易被忽略的一步。ipvsadm 配置是存在内存里的重启就没了# 保存当前规则ipvsadm-Sn/etc/sysconfig/ipvsadm-config# 重载规则模拟重启后恢复ipvsadm-C# 先清空ipvsadm-R/etc/sysconfig/ipvsadm-config# 再从文件恢复# 设置开机自启systemd 会读取上述配置文件systemctlenable--nowipvsadm.service⚠️ 踩坑记录第一次配好 LVS 后重启机器发现策略全丢了又得重新打一遍。后来才知道 ipvsadm.service 的启动脚本会从/etc/sysconfig/ipvsadm自动加载规则。五、DR 模式实战DR 模式是 LVS 的精华也是配置最复杂的一种。核心难点不是 ipvsadm 命令而是网络配置和 ARP 问题。5.1 实验拓扑DR 模式比 NAT 多了一层路由器因为 RS 的网关不能指向调度器DR 模式下回包不经过 VS必须走路由器出去。网络规划公网段172.25.254.0/24客户端和路由器外网侧内网段192.168.0.0/24路由器内网侧、VS、所有 RS各主机角色与 IP 配置主机角色网卡/接口IP 地址网关说明client测试客户端eth0172.25.254.10172.25.254.100经过路由器访问内网router路由器eth0外网172.25.254.100—NAT 模式做 SNAT 转发eth1内网192.168.0.10—内网网关VS调度器eth0192.168.0.200192.168.0.10调度器内网 IPlo192.168.0.100/32—VIP/32 掩码只表示单个 IPRS1真实服务器eth0192.168.0.101192.168.0.10网关指向路由器lo192.168.0.100/32—VIPARP 抑制对外装死RS2真实服务器eth0192.168.0.102192.168.0.10网关指向路由器lo192.168.0.100/32—VIPARP 抑制对外装死数据流向请求客户端 → 路由器(SNAT) → VS(改MAC) → RS 响应RS → 直接回客户端不经VS 关键区别RS 的网关指向路由器192.168.0.10不是指向调度器。因为 DR 模式下响应直接回客户端不需要经过 VS。 关键点VS 和所有 RS 都在 lo 接口上配了同一个 VIP192.168.0.100/32但 RS 必须通过 ARP 抑制假装没有这个 IP——只有调度器能响应 VIP 的 ARP 请求。5.2 核心难题ARP 抑制这是 DR 模式里最容易踩的坑也是面试最喜欢问的。问题RS 也有 VIP当客户端发 ARP 广播问谁有 192.168.0.100“的时候调度器和 RS1、RS2 都会回答在这”。如果客户端记录了 RS 的 MAC 地址后续请求就绕过调度器直接打到 RS 上了——负载均衡当场失效。解决方案让 RS 在 VIP 上装死。# 方法修改内核 ARP 参数推荐方案echo1/proc/sys/net/ipv4/conf/all/arp_ignoreecho1/proc/sys/net/ipv4/conf/lo/arp_ignoreecho2/proc/sys/net/ipv4/conf/lo/arp_announceecho2/proc/sys/net/ipv4/conf/all/arp_announce这两个参数到底什么意思用人话翻译一下arp_ignore1别人问谁有这个 IP的时候只有当这个 IP 确实配在收到请求的那张网卡上时才回答。VIP 配在 lo 上而 ARP 请求是从 eth0 进来的所以 RS 不会回答——完美arp_announce2向外通告自己的 IP 时只通告跟自己直连的网络里的 IP。VIP 跟内网不在一个网段那就不说——再次完美 另一种方案是用arptables直接 DROP 掉 VIP 相关的 ARP 包但改内核参数更优雅而且这也是官方文档推荐的方案。5.3 调度器配置# VS 上 VIP 配在 lo 接口/32 掩码——只表示这个 IP不代表一个网段# /etc/NetworkManager/system-connections/lo.nmconnection# address2192.168.0.200/32# 添加 DR 模式规则-g 是重点ipvsadm-A-t192.168.0.100:80-swrr ipvsadm-a-t192.168.0.100:80-r192.168.0.101:80-gipvsadm-a-t192.168.0.100:80-r192.168.0.102:80-gipvsadm-Ln# TCP 192.168.0.100:80 wrr# - 192.168.0.101:80 Route 1 0 0# - 192.168.0.102:80 Route 1 0 0注意 Forward 列显示Route而不是 NAT 模式的Masq。测试验证forNin{1..6};docurl192.168.0.100;done# RS2 - 192.168.0.102# RS1 - 192.168.0.101# 均匀分发 ✓5.4 NAT vs DR 实战心得做完两个实验后的感受NAT 模式适合学习和小规模场景——思路直观配置简单。但请求和响应都走调度器调度器压力大不适合大流量。DR 模式是生产环境的标配——响应直接回客户端调度器几乎不占带宽。但配置复杂特别是 ARP 抑制那一步不理解的很容易配错。不管哪种模式规则持久化一定别忘了做。血的教训六、防火墙标记FWM——多端口的救星6.1 问题的本质这个问题在实验中真实遇到过RS 上同时跑 HTTP(80) 和 HTTPS(443)如果分别建两个 LVS 服务ipvsadm-A-t192.168.0.100:80-srr ipvsadm-A-t192.168.0.100:443-srr那么 80 和 443 是独立轮询的可能出现HTTP 请求 → 轮询到 RS1HTTPS 请求 → 也轮询到 RS1因为 443 有自己的轮询计数器如果这是一个需要登录的网站用户通过 HTTP 登录到 RS1 后HTTPS 请求被调度到 RS2会话直接丢失登录状态没了。6.2 解决方案核心思路把 80 和 443 的数据包打上同一个标记LVS 基于这个标记而不是端口来做调度。# Step 1在 iptables mangle 表打标记# 意思是凡是发给 VIP、TCP 协议、端口为 80 或 443 的包打上标记 6666iptables-tmangle-APREROUTING-d192.168.0.100-ptcp\-mmultiport--dports80,443-jMARK --set-mark6666# Step 2LVS 基于标记 6666而不是端口创建服务ipvsadm-A-f6666-srr ipvsadm-a-f6666-r192.168.0.101-gipvsadm-a-f6666-r192.168.0.102-g验证curlhttp://192.168.0.100;curl-khttps://192.168.0.100# RS2 server - 192.168.0.102# RS1 server - 192.168.0.101 ← 两次请求分发到不同 RS说明是统一调度的 ✓小结FWM 本质上是一种归类机制——不管你在应用层叫什么名字HTTP、HTTPS到了传输层就是同一种流量就应该用同一套调度策略。这个思路在运维中很有普适性。⚠️ 注意FWM 是在 PREROUTING 链上工作的。这跟 LVS 的 hook 点PREROUTING 和 INPUT 之间完美配合。但也意味着如果你在 PREROUTING 上做了其他可能干扰的规则要特别小心。七、持久连接——让用户不掉线7.1 问题场景LVS 默认每来一个请求就重新调度一次除了用 SH 算法。但这在下面这些场景下会出问题用户登录后session 存在 RS1 上下一个请求被调度到 RS2 →登录状态丢失用户填了半天的表单提交时被调度到另一台 RS →表单数据没了购物车加了商品刷新页面后车空了 →用户体验灾难SH 算法源地址哈希能部分解决但太粗暴——同一个出口 IP 后面可能成百上千用户全粘在一台 RS 上负载严重不均衡。7.2 LVS 的持久连接方案LVS 的做法比 SH 聪明得多在内存里建一张持久连接模板表。客户端第一次来 → 正常调度比如轮询到 RS2LVS 记录一条模板IP客户端IP → RSRS2有效期超时时间在超时时间内默认360 秒同一客户端的所有请求都走这条模板不经过调度算法超时后模板失效下次请求重新调度# -p 指定超时时间秒ipvsadm-E-f6666-srr-p3000# 查看持久连接状态ipvsadm-Ln# FWM 6666 rr persistent 3000 ← 看到 persistent 说明启用了# 实时监控连接表非常有用watch-n1ipvsadm-Lnc# pro expire state source virtual destination# TCP 01:56 FIN_WAIT 172.25.254.99:42420 192.168.0.200:80 192.168.0.20:80# IP 00:57 ASSURED 172.25.254.99:0 0.0.26.10:0 192.168.0.20:0 注意连接表里有一条IP协议、端口为 0 的条目状态ASSURED——这就是持久连接模板。它的 expire 倒计时到 0 后同源客户端才会被重新调度。小结持久连接跟 SH 算法的本质区别是SH 是永久绑定同一个 IP 永远去同一台 RS持久连接是临时绑定一段时间内去同一台 RS过期后可以换。持久连接WLC 的组合是实际生产中最常见的配置——既能保证会话连续性又能保持负载均衡。八、LVS Keepalived 高可用概述8.1 问题来了学完前面你会发现一个大问题LVS 调度器自己是一个单点故障SPOF。你费劲心思搭了 DR 模式、配了加权轮询、做了持久连接……结果调度器宕机了整个集群全挂。这就是高可用要解决的问题。8.2 Keepalived 怎么解决Keepalived通过VRRPVirtual Router Redundancy Protocol实现多台调度器之间的主备切换两台或多台LVS 调度器组成一个 VRRP 组主调度器持有 VIP对外提供服务主调度器定时发 VRRP 心跳包给备调度器备调度器收不到心跳 → 判定主挂了 →自己接管 VIP整个过程对客户端透明切换时间通常在 1-3 秒配合VRRP Script还可以做更智能的检测——不只是看调度器有没有宕机而是检查整个链路是否健康比如 RS 全挂了也可以触发切换。阿里云 SLB LVS Keepalived 的工程化实现。你在云控制台上点几下鼠标创建一个 SLB 实例背后就是这套机制在运转。九、ipvsadm 命令速查这一节是常用的命令备忘录按操作类型整理集群服务管理# 添加ipvsadm-A-t172.25.254.100:80-srr# TCP轮询ipvsadm-A-f6666-swrr# 基于防火墙标记# 修改ipvsadm-E-t172.25.254.100:80-swrr-p3000# 改算法持久连接# 删除ipvsadm-D-t172.25.254.100:80# 清空所有规则慎用ipvsadm-CRS 管理# 添加 RS-m: NAT / -g: DR / -i: TUNipvsadm-a-tVIP:PORT-rRIP:PORT-g-w2# 修改权重ipvsadm-e-tVIP:PORT-rRIP:PORT-g-w3# 删除 RSipvsadm-d-tVIP:PORT-rRIP:PORT查看 调试ipvsadm-Ln# 查看规则-n 不做 DNS 反解快很多ipvsadm-Ln--rate# 看速率CPS/InPPS/OutPPS/InBPS/OutBPSipvsadm-Lnc# 看当前连接表排查调度问题神器ipvsadm-Z# 清空计数器ipvsadm-Sn# 保存规则输出格式可直接重定向到配置文件ipvsadm-R/etc/sysconfig/ipvsadm# 从文件重载关键文件文件作用/proc/net/ip_vs当前 LVS 规则十六进制格式/proc/net/ip_vs_conn当前所有连接的状态表/etc/sysconfig/ipvsadm-config规则持久化文件ipvsadm.service 启动时读取总结学习心得学完 LVS最大的感受是好的基础设施软件都是把复杂的底层细节封装成简洁的接口。LVS 的四个模式、十几种调度算法、持久连接、防火墙标记……看起来知识点很多但核心就一条链路客户端 → VIP → [调度算法选择 RS] → [模式决定怎么转发] → RS → 响应回去把这条链路理清楚每个环节该配什么参数就自然知道了。几个最重要的小结DR 模式是首选——生产环境 90% 都用它。掌握 ARP 抑制的原理才能在面试中讲清楚。WLC 算法默认就用它——加权最少连接是最通用的选择没有特殊需求不用换。持久连接-p和 FWM 防火墻标记是两个实际生产中非常常用的特性但入门教程经常忽略。Keepalived 补齐最后一块拼图——LVS 解决负载均衡Keepalived 解决调度器自身的高可用。两者结合才是完整的生产方案。七层和四层是配合关系不是竞争关系——LVS四层快 Nginx/HAProxy七层灵活是经典的组合架构。搞懂了 LVS再去看云厂商的负载均衡产品你会发现它们底层基本都是这套东西的封装。这也是一直强调学好基础的原因——基础扎实了上层的东西都是透明的。