LVS负载均衡全解析：从内核原理到高可用实战

先直接说结论LVSLinux Virtual Server到今天依然是绝大多数大规模互联网系统里四层负载均衡事实上的首选方案没有之一。我到现在还记得第一次在压测环境里看到单台 Director 扛住几十万 CPS每秒新建连接数时的那种震撼——那还是在普通 x86 服务器上没做任何特别极端的调优。后来越来越多的人一聊到云原生就只提 Kubernetes、Istio反而把这个藏在流量入口底下的老家伙给忽略了。其实不管是云厂商的 SLB、自建机房里的四层网关还是 Kubernetes 里 LoadBalancer 类型的 Service底层十有八九都是 LVS 或者它的同门师兄弟在撑腰。这篇文章我就把 LVS 从原理到实战完整拆一遍。你会搞清楚它为什么能扛住亿级流量、DR 模式到底牛在哪、调度算法该怎么选、和 Nginx 的分工边界在哪里以及我自己在机房和云环境里踩过的那些坑和排查思路。不管你是刚入门想做负载均衡选型还是已经被线上问题逼到要手撕内核参数的 SRE都可以照着这篇来。1. 先搞清楚 LVS 到底是什么1.1 搜索 LVS 时你搜到的可能是另一个人说个题外话很多人在搜索框里输入“LVS”时其实会遇到好几种完全无关的缩写。芯片设计领域有个很常见的LVSLayout vs. Schematic是跑版图与原理图一致性检查的工具还有一部分人搜到的是 Linux 内核模块机制里的LSV / LVM之类的相近概念。但咱们这篇文章要聊的是章文嵩博士在 1998 年发起的Linux Virtual Server也就是 Linux 内核里自带的那个 IPVS 模块。它跟芯片设计里跑 DRC、LVS 的那个工具没有任何关系别搞混了。在云原生时代为什么还要重新聊 LVS因为云原生的底座依然是 LinuxKubernetes 里的kube-proxy在 iptables 模式之外还有一个IPVS 模式那个 IPVS 就是 LVS 的内核实现。你在云上买的负载均衡实例绝大多数也是控制面加数据面分离的设计数据面跑的还是四层转发引擎。所以说理解了 LVS 就相当于理解了整个现代流量入口的地基。1.2 LVS 工作的基本位置负载均衡从层次上分大体两类四层传输层基于 IP 和端口和七层应用层基于 HTTP 协议内容。LVS 是典型的四层负载均衡它工作在 Linux 内核态通过向 Netfilter 框架挂钩子来拦截进出数据包再根据调度算法决定把包转给哪台后端真实服务器Real Server简称 RS。这里有一个关键概念LVS 本身不是一个常驻进程它只是内核里的一个功能模块ip_vs。你所有对它的操作都是通过ipvsadm这个用户态工具去配置内核中的规则表。所以它的性能很高因为数据包的处理根本不经过用户态不需要频繁的上下文切换也没有 socket 缓冲区拷贝这些开销——数据从网卡进内核在内核里完成转发决策直接出网卡。这也是它能打到百万级并发连接的底气所在。一句话理解四层和七层的差异七层像快递站拆包裹、看面单、重新封装四层像高速公路上的立交桥车进来只认入口和出口不做内容检查——所以立交桥的通过能力天然就比快递站高几个数量级。1.3 LVS 三个核心组件LVS 由三部分组成IPVSIP Virtual Server内核模块负责真正的转发逻辑和调度算法这是 LVS 的心脏。ipvsadm用户态命令行工具用于增删改查虚拟服务器Virtual Server和后端 RS 池。Keepalived通常是配套的负责在 Director负载均衡器之间做 VRRP 热备保证单点故障时 VIP 能平滑漂移。注意执行转发任务的机器传统上叫Director或LB在云环境里叫“负载均衡节点”。它本身不处理太多业务逻辑核心工作就是“接包、按规则选后端、转发”所以对 CPU 计算能力要求不苛刻但对网卡能力、中断处理能力和内核网络栈的稳定性要求很高。2. LVS 的三种工作模式以及为什么 DR 模式是亿级流量的答案2.1 NAT 模式最直观但最容易成瓶颈NAT 模式下Director 充当“中间人”。外部客户端访问 VIP 时数据包先到 DirectorDirector 根据调度算法选一台 RS然后把包的目标 IP 和端口改写为 RS 的 IP 和端口同时源 IP 也常常改写成 Director 自己的 IP再转发出去。RS 处理完的响应包必须先回到 DirectorDirector 再改回源地址发给客户端。整个过程像一个客服中转站所有人的电话都经过总机转接客服回电也必须打给总机由总机再联系客户。这个模式的优点是后端 RS 可以是任意操作系统、任意网段不需要特殊配置缺点是响应流量也全部经过 Director导致 Director 很容易成为瓶颈。一旦响应流量大过请求流量比如读多写少的业务、大文件下载Director 的 NAT 表就会被塞满转发能力直线下降。所以 NAT 模式适合规模不大的内部系统亿级流量基本不考虑。2.2 TUN 模式让包飞过 IP 隧道TUN 模式通过 IP 隧道IPIP将请求包封装后发给 RS。Director 把客户端请求封装在一个新的 IP 包里隧道另一端的 RS 解封装后看到原始包目标地址是 VIP于是 RS 直接以自己的路由把响应返回给客户端。这样响应流量不经过 Director从原理上缓解了 NAT 模式的瓶颈。但 TUN 模式有个前提RS 必须支持隧道协议封装/解封装这在现代 Linux 上没问题但在物理网络设备和一些云网络上会因为 MTU 问题、安全组限制变得很难用。我实际部署中很少用 TUN除非有跨机房、跨地域的需求基于物理网络可能还比较麻烦。大家了解一下即可。2.3 DR 模式真正构建亿级流量池的引擎DRDirect Routing直接路由模式是绝大多数互联网公司的首选。它利用了二层网络的特性Director 和 RS 在同一个物理二层网络内或通过 VXLAN 打通大二层转发时 Director 只改写数据帧的目标 MAC 地址不修改 IP 头。数据包到达 Director 后它的目标 IP 是 VIP比如 203.0.113.10Director 查询调度表找到选中的 RS然后把帧头的目标 MAC 改成 RS 网卡的 MAC扔到二层网络里。RS 收到这个帧后发现 IP 层目标地址是自己的 VIPRS 的 lo 接口上绑定着 VIP于是正常接收并处理。响应包直接走 RS 自己的默认网关发出去完全不需要再经过 Director。这个模式最优秀的地方在于请求流量方向只经过 Director响应流量方向完全不经过 Director。对于绝大多数互联网业务请求小、响应大这意味着 Director 的负载被大幅降低它可以支撑更大规模的并发。所以 DR 模式的扩展性最好吞吐量最高非常适合大规模集群。2.4 为什么 DR 模式要处理 ARP 问题DR 模式有个非常著名的坑VIP 的 ARP 冲突。因为所有 RS 都在 lo 接口上绑定了 VIP如果不做限制当外部或交换机对 VIP 发起 ARP 请求时所有绑定了 VIP 的机器都会应答交换机就会把发往 VIP 的流量随机分发给不同的机器整个负载均衡就废了。解决办法是通过内核参数控制 ARP 行为让 RS 对来自外部接口的 ARP 请求保持沉默# RS 上执行禁止 lo 接口响应任何 ARP echo 1 /proc/sys/net/ipv4/conf/all/arp_ignore echo 1 /proc/sys/net/ipv4/conf/lo/arp_ignore echo 2 /proc/sys/net/ipv4/conf/all/arp_announce echo 2 /proc/sys/net/ipv4/conf/lo/arp_announce这里arp_ignore1的意思是“只回应目标 IP 是本接口 IP 的 ARP 请求”lo 上的 VIP 不会被 eth0 接口响应arp_announce2的意思是“总是使用最佳本地地址发送 ARP 回应”避免用 VIP 作为源地址回应。这两参数是 DR 模式能否正常工作的生死线配置完一定用arping验证。经验之谈不止 RS 要配如果 Director 自己也绑了 VIP比如 Keepalived 模式下主备 Director 共享 VIP主备机的 ARP 行为也要保持一致否则故障切换时可能出现 VIP 漂移不过来或者交换机 ARP 表项错乱的情况。2.5 三种模式对比速查对比维度NAT 模式TUN 模式DR 模式请求是否经过 Director是是封装后是仅改 MAC响应是否经过 Director是否否RS 是否需要绑定 VIP否是是后端操作系统要求任意支持 IPIP 隧道支持 VIP 绑定二层网络要求无三层可达同二层或大二层单 Director 可支撑规模低中高典型适用规模中小型跨机房、特殊场景大规模核心入口3. 调度算法别只会用默认的 rr 和 wrr3.1 十种算法一句话盘点LVS 内核支持十种调度算法常用的也就四五个。rr轮询按顺序把新连接分给每台 RS适合后端能力完全一致的场景。wrr加权轮询给 RS 配权重权重高的分到更多连接。适合后端机器规格不一的情况。lc最少连接把新连接分给当前活跃连接数最少的 RS适合长连接业务。wlc加权最少连接在 lc 基础上增加权重是很多场景下的默认推荐。lblc基于局部性的最少连接针对目标 IP 做会话保持同一个目标 IP 的连接尽量发给同一台 RS适合 Cache 集群。lblcr带复制的基于局部性最少连接在 lblc 基础上允许目标 IP 的连接复制到多台 RS容错性强一些。dh目标地址哈希按目标 IP 做哈希同一个目标 IP 始终分到同一台 RS适合防火墙、NAT 场景。sh源地址哈希按源 IP 做哈希天然实现会话保持适合需要无状态会话保持的业务。sed最短预期延迟根据 RS 的当前连接数和权重计算预期延迟偏科生算法。nq永不排队如果有一台 RS 连接数为 0直接分给它否则按 sed 算法。3.2 实战中怎么选看场景不看参数表。如果是HTTP 短连接、后端无状态服务wlc 基本盘就很稳如果后端是WebSocket 这种长连接服务最少连接数算法比轮询靠谱得多——因为轮询会让前几个连接都压在 RS1 上RS1 很快就热了。如果是数据库主从分离的 Proxy 层sh 源地址哈希能保证同一个应用实例的请求始终去同一台 RS减少事务惊扰。我之前在支付网关场景里用的是sh 会话保持原因很直接同一个支付终端 IP 的请求必须始终打到同一台 RS 上否则 RS 本地缓存会反复 miss事务一致性也难保证。而如果是内部服务间的 RPC 调用我反而用 wlc因为调用方 IP 段很固定用 sh 容易把流量打歪。3.3 权重不是拍脑袋定的设置权重之前先看 RS 的硬件规格和当前负载。比如 RS1 是 32 核、RS2 是 16 核可以设 RS1 权重为 200、RS2 权重为 100。但权重只是相对比例不是精确计划任务。上线后要通过监控看每台 RS 的 CPU、内存、连接数用数据反调权重不要一劳永逸。我自己习惯的权重调整节奏是每次只调 10%~20%观察一个业务低峰期再决定要不要继续调整。一次调得太猛可能直接打爆某台 RS。4. 实战Keepalived LVS 双活高可用集群搭建4.1 整体拓扑设计搭建一套完整的高可用 LVS 集群需要用到两台 Director主备和若干台 RS。我下面画一个典型的 DR 模式拓扑VIP203.0.113.10Director 主192.168.1.11Director 备192.168.1.12RS1192.168.1.101业务 NginxRS2192.168.1.102业务 Nginx网关192.168.1.1流量路径是客户端访问 VIPKeepalived 保证主 Director 持有 VIP主 Director 根据调度规则把请求转发给 RSRS 响应直接回给客户端。备 Director 平时只做 VRRP 心跳不处理流量。整体拓扑用文字描述就是这样实际环境里交换机的 ARP 表、路由表要提前确认。下面直接开始动手。4.2 Director 上的基础配置先在两台 Director 上安装 ipvsadm 和 keepalived# CentOS / Rocky 系 yum install -y ipvsadm keepalived然后加载内核模块modprobe ip_vs modprobe ip_vs_rr modprobe ip_vs_wrr modprobe ip_vs_sh为了让模块开机自动加载可以配置/etc/modules-load.d/ipvs.conf把需要加载的模块名写进去。这一步很多教程都会略过但实际重启机器后如果没有自动加载模块LVS 就直接不可用了。4.3 RS 上的基础配置RS 需要绑定 VIP 到 lo 接口并开启 ARP 抑制。# 在 RS1 和 RS2 上都执行 cat /etc/sysconfig/network-scripts/ifcfg-lo:0 EOF DEVICElo:0 IPADDR203.0.113.10 NETMASK255.255.255.255 ONBOOTyes NAMElo:0 EOF 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把 sysctl 配置写入/etc/sysctl.d/99-lvs-arp.conf并执行sysctl -p生效。这里有一个很多人忽略的细节lo 接口上配置 VIP 时子网掩码必须是 255.255.255.255/32不能写成 /24否则 Linux 会因为本地路由的优先级问题产生奇怪的路由冲突。4.4 配置 Keepalived把 VIP 管起来主 Director 的/etc/keepalived/keepalived.conf核心配置如下global_defs { router_id LVS_MASTER } 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 { 203.0.113.10/32 dev eth0 label eth0:0 } } virtual_server 203.0.113.10 80 { delay_loop 6 lb_algo wlc lb_kind DR persistence_timeout 0 protocol TCP real_server 192.168.1.101 80 { weight 100 TCP_CHECK { connect_port 80 connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } real_server 192.168.1.102 80 { weight 100 TCP_CHECK { connect_port 80 connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } }备 Director 的配置几乎一样只需要把state改为BACKUP、priority改为 90router_id改成LVS_BACKUP。注意virtual_router_id在主备之间必须保持一致否则 VRRP 报文无法互相识别。里面对两个参数特别说明一下persistence_timeout是会话保持时间单位秒。设成 0 表示不做会话保持每个连接独立调度。如果业务本身在应用层有 session 管理比如 Redis 存 session建议设 0让流量均摊。TCP_CHECK是健康检查方式Keepalived 会定期尝试连接 RS 的 80 端口。如果 RS 上的服务挂了就自动把它摘掉恢复后重新加进来。4.5 验证集群是否真的可用配置完成后启动 Keepalivedsystemctl enable --now keepalived验证分三层先看 VIP 在哪台机器上ip addr show检查主 Director 的 eth0 上是否有203.0.113.10。再看 ipvs 规则是否生效ipvsadm -L -n应该能看到虚拟服务器和两个 RS 的条目。最后从外部客户端实际访问curl -H Host: your-domain.com http://203.0.113.10/反复访问几次看 RS 日志里是否有按预期分布过来的请求。另外用arping验证 VIP 是否只被主 Director 应答arping -I eth0 -c 3 203.0.113.10如果在交换机侧抓包发现多台机器响应了 VIP 的 ARP 请求说明 RS 上的 ARP 抑制参数没有生效必须回头检查。注意DR 模式有一个常见陷阱如果客户端和服务端不在同一网段RS 的默认路由必须指向一个能通往外网的网关。很多人在测试环境里只配了和 Director 同一网段的地址忽略了默认网关结果 RS 响应包发不出去表现为“VIP 能 ping 通但业务永远打不开”。5. 亿级流量场景下的架构选型与内核调优5.1 LVS 和 Nginx 的边界到底在哪聊云原生绕不开 Nginx。很多初学者的困惑是都有 Nginx 了为啥还要 LVS其实它俩根本不是替代关系而是上下游关系。LVS 的四层转发只解决“连接发到哪台机器”的问题不关心 HTTP 报文里是 GET 还是 POST、路径是 /api 还是 /static。Nginx 则是七层代理能做路由分发、域名匹配、缓存、限流、TLS 卸载。合理的架构是LVS 在最前端做流量入口和主备容灾Nginx 在中间层做七层路由和业务网关后端挂应用服务集群。一句话LVS 负责把人潮引导到商场门口Nginx 负责在商场里把不同人群引导到不同柜台。两者配合才能同时保证入口吞吐量和业务路由灵活性。5.2 云原生环境里 LVS 的角色在 Kubernetes 集群里Pod 的 IP 是漂移的所以需要一个稳定的入口。云上的 LoadBalancer Service 通常由云厂商的负载均衡承担而在私有化部署、混合云环境或裸金属 Kubernetes 里LVS 常常扮演云厂商 SLB 的“平替”。更直接的是 kube-proxy 的 IPVS 模式。当 Service 数量超过几百个时iptables 模式因为规则链太长会出现明显的转发延迟和规则更新延迟而 IPVS 模式使用哈希表存储转发规则规则数量多时性能依然很稳定。这是 CNI 层面对 LVS 最长情的使用方式。在业务架构上我曾经维护过一套“LVS Nginx Ingress Controller 后端应用 Pod”的链路LVS 把流量分给多个 Nginx Ingress PodIngress 再按域名路由到具体的 Service。LVS 只做 VIP 层面的高可用和水平扩容Nginx Ingress 做七层规则处理。这样既保证了四层入口的吞吐量也保留了七层路由的灵活性。5.3 内核网络参数调优清单LVS 在高并发下能不能稳稳接住流量很大程度取决于内核参数是否合适。下面几项是我实测后收益最大的。连接跟踪调优尤其 NAT 场景如果用的是 NAT 模式要调大连接跟踪表sysctl -w net.netfilter.nf_conntrack_max1048576 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established600文件句柄和临时端口sysctl -w fs.file-max1000000 sysctl -w net.ipv4.ip_local_port_range1024 65535TIME_WAIT 积压sysctl -w net.ipv4.tcp_fin_timeout10 sysctl -w net.ipv4.tcp_tw_reuse1网卡队列使用多队列网卡时打开 RSSReceive Side Scaling把不同的队列分配到不同 CPU 核心避免单核软中断被打爆。这一步在物理机上尤其有效。可以通过ethtool -L eth0 combined 8设置队列数再配合irqbalance或手动绑核。一个真实的压测教训最初只调了 TCP 层参数忽略了网卡队列单核软中断达到 100%LVS 转发能力只有理论值的一半。后来把 8 个队列铺到 8 个 CPU 核心上同规格机器吞吐翻了一倍。调优一定要有系统性思维关注网络栈的每一个环节。5.4 容量规划不是“加机器”那么简单LVS 的容量评估不能只盯着 Director 的 CPU还要看每秒新建连接数CPS这是四层负载均衡最关键的指标直接决定握手能力并发连接数CC受内存和连接跟踪表限制吞吐量Throughput受网卡带宽和 PCIe 通道限制。举个实际例子一台 32 核、32GB 内存、双口 25G 网卡的 Director在没有额外防火墙规则的情况下单机支撑 100 万级并发连接是可行的CPS 也能做到 30 万左右取决于包大小。但如果你在上面挂了一堆 iptables 规则、打开 conntrack 又没调优性能掉一个数量级都不奇怪。所以规划容量时重点研究的是“最坏情况下的 CPS”而不是平均流量。我在做容量评估时会先压测出单 Director 的 CPS 上限然后用“业务峰值 CPS × 1.5 系数”计算出需要的 Director 数量再加一台备用这样容错空间才够。5.5 隔离与安全LVS 本身不识别应用层所以它的安全策略只能做粗粒度控制。常见的做法是在 Director 上做IP 白名单/黑名单用iptables ipset实现大流量场景下的高效过滤对后端 RS 做SYN Flood 防护可以开启内核的 SYN Cookiessysctl -w net.ipv4.tcp_syncookies1限制单 IP 连接数防止单点恶意来源打爆 RS。但真要防大流量 DDoSLVS 不是银弹——它要再前置硬件防火墙或云清洗能力。LVS 的定位是把正常流量高效分发出去而不是做深度安全检测。6. 线上高可用经验与常见故障排查6.1 VIP 能 ping 通但业务打不开这个故障在 DR 模式里非常典型。我会按以下顺序排查看 VIP 当前在哪个节点ip addr show如果 VIP 漂到了备节点先看主节点 Keepalived 日志看 RS 是否被 Keepalived 摘除ipvsadm -L -n如果 RS 的条目没了检查 RS 上的 Nginx/服务是否异常以及健康检查的端口是否被防火墙拦截看 RS 的默认路由ip route show确认存在指向网关的默认路由否则响应包根本回不去在 RS 上抓包tcpdump -i eth0 host 203.0.113.10如果能看到请求包但没响应包基本就是回程路由或 ARP 问题。6.2 流量严重不均衡流量不均衡先别急着怪算法。我遇到过最坑的一次是新加的一台 RS 权重配了 100但实际流量就是不过去。排查下来发现这台 RS 的 lo:0 接口没有配置 VIP导致 Director 转给它的包它不认直接丢弃。虽然 TCP_CHECK 是通的因为健康检查走的是 eth0 IP但真正转发 VIP 流量时完全没反应。所以健康检查通过 ≠ 转发一定成功。新增 RS 后一定要先手动验证 RS 能否正常处理 VIP 地址的请求再放流量进来。另一个常见原因是 Keepalived 的persistence_timeout会话保持时间太长。比如设置了 300 秒那么同一个来源 IP 的连接会在 5 分钟内始终打到同一台 RS 上就像水管堵了一半的感觉。6.3 长连接经常断如果你的业务是 WebSocket 或者长轮询LVS 侧的超时时间需要特别关注。内核里的 conntrack 或 IPVS 连接超时默认值不一定适合长连接场景。可以用以下命令查看和调整 IPVS 的超时时间# 查看当前超时 ipvsadm -L --timeout # 调整 TCP 空闲超时为 3600 秒 ipvsadm --set 3600 3600 600ipvsadm --set的参数依次是 TCP 空闲超时、TCP FIN 等待超时、UDP 超时。默认 TCP 空闲超时一般是 900 秒如果业务有超过 15 分钟的空闲长连接就会被 LVS 主动断开。很多“连接莫名奇妙断掉”的问题其实就是这里。还有一点容易被忽略net.ipv4.tcp_keepalive_time默认 7200 秒如果应用自己没有设置 Socket Keepalive连接在 2 小时内没数据就会被内核断开。长连接业务建议把应用层的心跳周期缩短同时在 LVS 把空闲超时调大两头配合。6.4 Keepalived 反复抢主VIP 不断抖动主备 Director 频繁抢占 VIP通常是 VRRP 心跳不稳导致的。排查思路确认主备之间心跳网段防火墙放行 VRRP 协议协议号 112确认virtual_router_id一致且不要和同二层其他 Keepalived 实例冲突看系统日志里有没有 VRRP 报文丢失记录如果是交换机风暴考虑把心跳放在独立的带外网口。一个比较少见但很恶劣的情况是主备两台机器上 BIOS 的省电策略不同导致主节点 CPU 频率波动大偶尔处理 VRRP 报文不及时备节点误判主节点宕机然后抢 VIP。解决方法是统一主机 BIOS 的 C-States 策略必要时把 Keepalived 进程绑核避免调度延迟。6.5 监控你永远需要知道 VIP 背后每台 RS 的真实状态最后聊一下监控。LVS 的监控不能只做“VIP 通断”层面的检查我的建议是至少采集以下指标当前活跃连接数和非活跃连接数ipvsadm -L -n里可以看到也可以从ip_vs_stats读取Director 的 CPS 和 pps每秒包数这决定了容量水位每台 RS 的连接分布和权重能从ipvsadm -L -n的ActiveConn / InActConn / Weight三列看到RS 自身的 CPU、内存、TCP 连接状态结合 node_exporter 采集。在 Prometheus 生态里虽然 ipvs 指标不能像内核模块那样直接全量暴露但可以通过ipvsadm结合文本收集器或脚本抓取。关键是你要建立“入口视角 RS 视角”的双轨监控缺一不可。很多团队只盯 RS 的负载没盯 Director 的 CPS结果 Director 先挂了自己都不知道。7. 写在最后的实践经验说句掏心窝子的话我在云原生的项目里折腾过各种新的网关、新的 Service Mesh 方案但每次线上出大流量故障最后保险的那道防线往往还是 LVS。它不是最酷的技术但它是经过十几年大规模验证的可靠方案。如果你正在规划自己的负载均衡层我的建议是这样的小规模、内部系统可以考虑直接用 Nginx一旦流量进入千万级日请求或需要四层入口和主备高可用直接上 Keepalived LVS DR 模式。这个组合足够简单、足够稳也足够支撑你未来几年的业务增长。最后分享一个小技巧很多人不知道ipvsadm -L -n --stats可以看到每台 RS 的累计转发字节数和包数。在排查流量倾斜时比起看 TCP 连接数我更推荐看这个字节数因为它才反映了实际负载的大小。举例来说RS1 连接数比 RS2 多 10%但字节数可能完全反过来——因为不同用户上传下载的量差异很大。调权重、做容量评估别看热闹的连接数要看门道的数据量。