易行男·龙大崇聊到并发，很多人第一反应是“加机器”。机器加完之后呢？流量到了入口，谁来决定哪台机器处理？机器挂了，流量怎么切？这才是我今天想聊的核心——LVS。作为一套基于Linux内核的负载均衡方案，LVS（Linux Virtual Server）在并发解决方案里属于最底层、最硬核的那一环，也一直是集群架构和分布式系统中的关键入口组件。这篇文章不会只停留在“LVS怎么用”这个层面，我会把并发问题的来源、LVS的三种工作模式、调度算法、Keepalived高可用这些实操细节全部串起来，同时把集群和分布式这两个经常被混淆的概念放到一起对比，讲清楚它们在真实架构里各自的职责和边界。
如果你是刚接触服务器集群的开发者，或者正在做架构选型、需要梳理高并发方案的运维工程师，这篇文章应该能帮你在脑子里建立起一张完整的架构地图：从流量入口到后端服务，从一台机器到一个分布式系统，每一层在解决什么问题、LVS又站在哪个位置。
1. 并发瓶颈到底卡在哪：LVS为什么一直没被淘汰
1.1 从单机到集群，流量入口的第一个问题
我见过很多团队做高并发改造，上来就搞微服务、搞分布式事务，结果连最基础的流量入口都没有设计好。实际上，一个系统在面临快速增长的业务量时，最先扛不住的往往是三个地方：数据库连接数、应用服务器线程池、以及公网入口带宽。前两个大家讨论得多，但第三个常常被忽略。
想想看，不管后端你有多少个应用节点，对外永远只有一个公网IP。用户访问的是这个IP，TCP连接落到的也是这个IP。当每秒新建连接数超过几千甚至几万时，单台服务器首先会耗尽文件描述符，接着是协议栈的处理能力逼近极限，然后才是业务代码层面的CPU和内存压力。这个阶段，单纯把应用层扩容到十台机器是没用的，因为流量还没到应用层，入口就已经被堵死了。所以需要一层专门做流量分发的组件，把所有进来的请求按照一定策略均匀地打到后端的每一台服务器上。
这就是LVS存在的意义。它工作在Linux内核态的IP层，处理的是数据包级别的东西，转发速度比任何用户态程序都快。你在用户态用Nginx做七层转发，能扛住几万并发已经不错，而LVS在纯内核态转发，单机承载的并发连接数往往能达到几十万甚至上百万。这也是为什么LVS从1998年出现到现在，二十多年过去，依然活跃在生产环境的入口层。
1.2 LVS在并发解决方案里的定位
LVS整个体系的核心是一个叫IPVS（IP Virtual Server）的内核模块，简单说，它让你有一台Linux服务器可以声明一个虚拟IP（VIP），然后把这个VIP上的流量按规则转发到一组真实服务器（Real Server）上。对客户端来说，它只跟这个VIP打交道，完全感知不到后端有多少台机器。
这套机制决定了LVS的三个核心优势。第一，性能极高，转发逻辑在内核态完成，不经过用户态拷贝和进程调度，这意味着它的瓶颈更多在网卡而不在系统本身。第二，无状态，LVS本身不保存业务数据，所有连接状态要么记录在后端服务器上，要么通过持久连接做最小化的会话保持，这让LVS可以很方便地做一主一备部署。第三，对后端透明，后端服务器只需要配置好IP和路由，不需要安装任何额外的LVS组件。
在整套并发解决方案中，LVS属于“入口流量调度”这一层。它往下承接的是用户的真实请求，往上对接的是后端的业务集群。至于后端是Nginx、Tomcat、Kubernetes的Pod还是一个数据库集群，LVS并不关心，它只负责把包投递到目的IP。这种“只认IP不认业务”的特点，反而让它成为整个架构里最稳定、最不容易被替换的一环。
1.3 选LVS还是选Nginx：横向对比
很多刚开始做架构的人会问：有了Nginx，为什么还要用LVS？这俩不是重复了吗？确实功能上有重叠，但定位完全不同。Nginx工作在七层，它解析HTTP协议，可以做URL路由、限流、缓存、跨域等非常精细的控制。LVS工作在四层，它不看HTTP协议内容，做的是更底层的IP+端口级别的转发。
用一个生活化的类比来说，LVS是高速公路入口的收费闸机，所有车都要经过它，但它不管车里坐的是人还是货，只要按车道规则走就行；Nginx则是物流分拣中心，它会仔细看每个包裹的面单，然后按目的地分到不同的传送带。所以正确的架构通常是：最外层用LVS处理海量连接，中间层用Nginx做7层路由和反向代理，后端才是你的业务应用服务器。
在选型上，如果你的场景是很单纯的四层转发需求，比如把某个TCP端口的流量均匀分发到多台后端，LVS是最佳选择；如果你需要根据URL路径、域名或者请求头来做路由和灰度发布，那就必须上Nginx。两者不是替代关系，而是协同关系，这也是我反复跟团队强调的一点：架构选型不要“二选一”，要“各取所长”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. LVS三种工作模式的底层逻辑与适用场景
2.1 NAT模式：最直观但也有瓶颈
NAT模式的原理最容易理解。客户端请求到达LVS后，LVS把数据包的目标IP从VIP改成选中的后端服务器IP，转发过去；后端响应时，再把包源地址改成VIP返回给客户端。整个过程相当于LVS做了一次地址翻译，所以叫NAT模式。
这个模式最大的优点是实现简单，后端服务器不需要任何特殊设置，只需要把默认网关指向LVS即可。因为请求和响应都得经过LVS中转，后端服务器处于一个内网环境里，相对安全。
但问题恰恰也出在这里：所有进出流量都走LVS，LVS本身就成了瓶颈。如果一个数据包平均大小是1KB，50万并发时LVS需要处理的吞吐量就高达500MB/s，对网络栈的压力非常大。所以NAT模式在真实的超大规模场景中并不常见，更多是用在小型内网环境，或者后端服务器跨网段不好做路由的特殊场合。如果后端服务器数量不多、单机性能足够、规模在一两百台以内，NAT模式其实是一个很省心的选择。
2.2 DR模式：生产环境绝对主力
DR模式（Direct Routing，直接路由）是生产环境中最常用的模式。它的核心思想是：LVS只负责改写数据链路层的目的MAC地址，然后把数据帧直接从同一个局域网内发给后端服务器。后端服务器的网卡上需要配置VIP，让内核能识别这个IP是自己的，但对外不响应这个IP的ARP请求，这样可以避免客户端直接绕开LVS和后端通信。
听上去有点绕，我用大白话拆解一下。客户端发出的请求，目的IP是VIP，到了LVS之后，LVS不会改这个IP，只改MAC地址，让数据帧在局域网内直接传递给后端服务器。后端服务器看到目的IP是自己网卡上配置的VIP，就正常处理请求；响应时，因为源IP本来就是VIP，所以数据包可以直接通过路由器返回给客户端，不需要再绕回LVS。
这样做的优势非常明显：入站流量经过LVS，出站流量完全不用经过它，LVS只承担一半的流量压力，性能比NAT模式高出一大截。这也是为什么DR模式能支撑超大并发场景的原因。代价是后端服务器需要做一些网络参数调整，尤其是关闭VIP的ARP响应，避免整个局域网里出现IP地址冲突。这个配置细节我在后面实操部分会专门讲，它是DR模式能否跑通的关键。
2.3 TUN模式：跨机房的那把钥匙
TUN模式（IP Tunneling，IP隧道）解决的是跨网段转发的问题。它的原理是LVS把原始数据包封装在一个新的IP包里面，通过隧道发送给后端服务器，由后端服务器解封装后处理。因为走的是IP隧道，所以后端服务器可以和LVS不在同一个局域网，甚至可以在不同机房、不同地域。
这种模式在一些需要跨机房容灾的场景里非常有用。比如业务在北京和上海各部署了一套集群，两套集群共同承担流量，LVS在北京接到请求后，按调度算法可以把一部分流量封装成隧道包转发给上海的服务器，实现跨地域的负载均衡。但在实际落地中，TUN模式的复杂度比较高，需要后端服务器支持隧道协议并配置tun网卡，而且一些云厂商的网络环境对隧道协议支持并不友好，所以除非有明确的跨机房需求，否则我不会推荐直接上TUN。大多数时候，DR模式配合多机房DNS调度，比TUN更实用、更好维护。
2.4 模式选型视角
三种模式放在一起对比，可以看得很清楚：NAT适合内网、中小规模；DR适合同机房、大并发；TUN适合跨机房、跨网段。选型的核心依据，其实是“进出流量对称还是不对称”以及“后端和LVS是否在同一二层网络”。
我在实际项目里，绝大多数场景都是直接DR模式。理由很简单：第一，它是性能和复杂度之间的最优解；第二，我们的大多数后端服务都部署在同一个私有网络内，满足DR模式的物理条件；第三，DR模式没有NAT那种“流量绕行”的瓶颈，扩展性最好。如果你的环境是在云上，很多云厂商的SLB本身就是基于类LVS技术做的四层负载均衡，你甚至不需要自己部署LVS，直接用云产品即可。
3. 调度算法与IPVS实操：从安装到跑通一个真实负载均衡
3.1 调度算法一览与适用场景
IPVS提供了十几种调度算法，但生产环境里真正常用的就那么几种。我来把它们分成两个阵营梳理一下。
第一个阵营是“让每个请求尽量均匀”：包括轮询（RR）、加权轮询（WRR）、最少连接（LC）、加权最少连接（WLC）。轮询就是按顺序轮流分发，每个请求轮一圈；加权轮询则是给性能好的机器更高的权重，让它们多承担一些请求。最少连接算法看的是当前后端服务器上的活跃连接数，谁连接少就把请求发给谁，适合请求处理时长差异较大的场景，比如有的接口返回快、有的接口做复杂计算要好几秒，这时候最少连接会比轮询更均衡。加权最少连接则是最少连接算法的加权版，也是最常用的默认算法。
第二个阵营是“让同一个客户端的请求总是落在同一台服务器”：包括源地址哈希（SH）和持久连接（Persistence）。源地址哈希算法根据客户端IP做哈希计算，保证同一个IP的请求总是转发到同一台后端；持久连接则是IPVS在指定时间内记住“这个客户端IP映射到哪台后端”，哪怕算法本身被设置为轮询，在持久时间内也会保持固定映射。
我在选算法时有一个原则：如果所有后端服务器的配置一样、业务处理时长也差不多，直接用WRR就行；如果后端服务器配置参差不齐，或者业务接口响应时间差异大，用WLC更稳；只有明确需要会话保持，而且不想引入Redis这类外部会话存储时，才考虑源地址哈希或持久连接。对于需要用户登录状态保持的系统，我的建议还是把所有会话信息集中存到Redis集群里，而不是依赖负载均衡层的会话粘滞，否则某台后端宕机时，粘在这台机器上的用户会话会直接丢失，体验很差。
3.2 安装和基础配置
下面进入实操环节。我以CentOS环境为例，LVS的安装其实非常简单，因为它不是独立软件，而是Linux内核的一部分。你只需要安装管理工具ipvsadm，它是用来配置IPVS规则的命令行工具。
bash复制# CentOS / RHEL
yum install -y ipvsadm
# Ubuntu / Debian
apt install -y ipvsadm
安装完成后，先验证一下内核是否已经加载了IPVS模块：
bash复制modprobe ip_vs
lsmod | grep ip_vs
如果能输出ip_vs相关的模块信息，说明内核已经支持。如果modprobe报错，确认一下内核版本，一般2.6及以上版本的内核都自带了IPVS模块，只是有的发行版默认没有加载，手动加载一次即可。
接着，启用IP转发功能，这是NAT模式和路由转发的基础：
bash复制echo 1 > /proc/sys/net/ipv4/ip_forward
# 持久化设置
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p
然后用ipvsadm配置一个最简单的虚拟服务。假设VIP是192.168.1.100，后端有两台Web服务器，IP分别是192.168.1.10和192.168.1.11，统一使用80端口：
bash复制# 添加一个虚拟服务，使用加权轮询算法
ipvsadm -A -t 192.168.1.100:80 -s wrr
# 添加两台真实服务器，权重分别设置为1和2
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.10:80 -g -w 1
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.11:80 -g -w 2
# 查看当前配置
ipvsadm -L -n
这里-A表示添加虚拟服务，-t表示TCP协议，-s指定调度算法；-a表示在已有虚拟服务下添加真实服务器，-r指定真实服务器的IP和端口，-g表示使用DR模式（-m是NAT，-i是TUN），-w设置权重。
3.3 DR模式完整配置与ARP抑制
DR模式能不能跑通，关键点在真实服务器（RS）的ARP设置上。前面提到了，RS需要在loopback接口上配置VIP，但必须禁止它在局域网内通告这个IP。如果不做这一步，局域网里的交换机和路由器会发现同一个IP有两个MAC地址在响应ARP请求，轻则网络闪断，重则直接把整个二层网络打瘫。
RS上的配置如下。先设置loopback接口的别名IP为VIP，子网掩码填255.255.255.255，避免它响应所有子网内的广播：
bash复制ifconfig lo:0 192.168.1.100 netmask 255.255.255.255 up
然后在/etc/sysctl.conf里追加ARP抑制参数：
bash复制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
sysctl -p
这两个参数的含义是：arp_ignore = 1表示只有当ARP请求的目标IP是本机某个网卡的IP时才响应；arp_announce = 2表示ARP通告里使用最合适的本地IP地址，不对VIP做无差别广播。配置完成后，用ip addr确认VIP已经挂到了lo接口上。
这个阶段最容易踩的坑是：只配置了all，没有配置lo。在Linux内核的ARP处理逻辑里，all和具体接口的配置是“取最大值”的关系，如果lo接口上没有单独设置，默认值依然是0，ARP抑制就不生效。所以两个位置都要配，这是我在生产环境踩过坑之后才记住的。
3.4 验证负载均衡效果
配置完之后，验证是必不可少的。在客户端直接请求VIP：
bash复制curl http://192.168.1.100/
多执行几次，看看响应内容是否来自不同的后端服务器。如果后端是Nginx，可以在index.html里写入不同的标识，比如“Server A”“Server B”，这样一眼就能看出流量是否被轮询分发。
同时，在LVS机器上通过ipvsadm -L -n --stats可以看到实时的连接数和流量统计：
bash复制ipvsadm -L -n --stats
这个命令输出里，ActiveConn表示当前活跃连接数，InPkts和OutPkts表示进出包数，InBytes和OutBytes表示进出流量。通过这些指标，你可以判断流量是否确实经过LVS，以及两台后端服务器的负载是否按权重分布。
如果发现流量都跑到了一台机器上，先检查两边的权重和算法是否配置正确，再在客户端做个简单的arping检查VIP的MAC地址是否始终对应LVS。
4. 高可用：LVS + Keepalived的标配组合
4.1 为什么单独部署LVS扛不住故障
单独部署一台LVS，性能再强，也躲不开“单点故障”的问题。LVS挂掉，整个集群的入口就消失了，后端不管有多少台机器都收不到流量。所以生产环境里，LVS一定是成对部署的，配合Keepalived实现VIP漂移。
Keepalived的核心就是VRRP协议。它让两台LVS服务器在同一个虚拟组里竞争同一个VIP，正常情况下VIP绑在主节点上，主节点通过周期性通告告诉备节点“我还活着”。一旦主节点宕机，备节点在超时时间内没有收到通告，就立即接管VIP，同时更新本机的IPVS规则。这样对客户端来说，整个切换过程是透明的，它始终访问同一个VIP，只不过背后的物理机变了。
4.2 Keepalived 配置实例
下面给出一份完整的Keepalived配置示例。假设主节点IP是192.168.1.2，备节点IP是192.168.1.3，VIP是192.168.1.100：
nginx复制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 {
192.168.1.100
}
}
virtual_server 192.168.1.100 80 {
delay_loop 6
lb_algo wrr
lb_kind DR
protocol TCP
real_server 192.168.1.10 80 {
weight 1
TCP_CHECK {
connect_timeout 3
retry 3
delay_before_retry 2
}
}
real_server 192.168.1.11 80 {
weight 2
TCP_CHECK {
connect_timeout 3
retry 3
delay_before_retry 2
}
}
}
备节点的配置只需要把state改成BACKUP、priority改成低于主节点的值，比如90。其他配置保持一致。
一个容易忽略的细节是virtual_router_id，两台LVS上必须一致，否则VRRP组不联通。同一网段里不同组的ID也不能重复，这个ID决定了VRRP组播报文的身份，一旦撞了就可能出现VIP互相抢占的异常现象。
4.3 健康检查与故障切换验证
配置里我用了TCP_CHECK做健康检查，它的原理是Keepalived每6秒尝试和后端服务器的80端口建立一次TCP连接，连接成功就认为节点健康，失败则自动把它从调度池里摘除，不再转发流量给它。当它恢复后，Keepalived会自动加回来。这个过程不需要人工干预，是我在生产环境里最推荐的方式。
有些场景需要做更精细的健康检查，比如某个接口专门用来返回服务状态，可以改用HTTP_GET，让Keepalived检查这个接口的返回码。但我的建议是，健康检查越轻量越好：TCP_CHECK已经能覆盖绝大多数场景，HTTP_GET检查的接口一旦写了复杂逻辑，反而可能因为业务代码问题导致误判，让正常节点被摘除。
验证故障切换时，可以在主节点上直接执行systemctl stop keepalived，然后观察VIP是否在几秒内出现在备节点的网卡上。一般advert_int 1配置下，切换时间在3秒以内。再确认一下备节点的ipvsadm -L -n里是否有完整的IPVS规则，因为Keepalived接管VIP后，会将配置里的real_server重新加载到内核里。
5. 集群和分布式：这两个词到底有什么区别
5.1 集群的分类与本质
很多教程把集群和分布式混着讲，导致很多人以为集群就是分布式、分布式就是集群。其实这两个概念有明确的分工。
集群，简单说就是把一组相同功能的服务器组织起来，共同对外提供服务。核心目标是“多副本”和“高可用”。按照解决的不同问题，集群大致可以分成四类：负载均衡集群、高可用集群、高性能计算集群和存储集群。LVS就是负载均衡集群的典型组件；Keepalived那套一主一备机制就是高可用集群的雏形；Hadoop里的HDFS其实是一个存储集群；HPC（高性能计算集群）则常见于科研领域，把很多机器的CPU和内存拼起来做并行计算。
集群的本质是“同质化”。所有节点运行同样的代码、提供同样的服务，任何一个节点挂掉，其他节点都能无缝接管。至于扩展性，是通过增加同样角色的节点来提升整个集群的水平水量。所以集群解决的是“一台机器不够用”的问题。
5.2 分布式：集群之上的一层逻辑拆分
分布式系统的本质是“异质化”。一个业务系统被拆分成不同的模块，比如订单服务、库存服务、支付服务、用户服务，这些模块各自部署在不同的机器上，通过远程调用协作完成业务。这些模块不是同一个服务，但它们组合在一起，构成了一个完整的分布式系统。
举个具体的例子。你要做一个电商平台，如果所有功能都打成一个包部署在一台机器上，这是单体应用。当你把这个单体应用拆成订单模块、库存模块、用户模块，分别部署在三台机器上，那就变成了分布式系统。这种情况下，三个模块的代码不一定一样，数据也不一样，它们各自拥有独立的存储，并且通过网络通信来协同。
所以可以这样理解：集群是“一堆一样的节点干同一件事”，分布式是“一堆不一样的节点干一件大事的不同部分”。集群关注的是冗余和扩展，分布式关注的是分治和协作。
5.3 从LVS看集群与分布式的协同关系
LVS在这种架构里的位置很有意思：它的后端可以是集群，也可以是分布式系统。如果你的后端是一堆Nginx节点，这些节点是相同角色，那这是一个典型的负载均衡集群；如果你的后端是相互独立的订单服务、库存服务、支付服务，LVS可以根据不同端口或URL前缀把流量分发到不同服务的实例上，那它就是分布式系统入口的一部分。
大多数真实系统的架构都是混合的：最外层LVS做四层负载均衡，后面是Nginx集群做七层路由，再往后是按照业务拆分的微服务，每个微服务本身又是一个多副本的集群。我在设计架构时，会先把“流量从客户端到后端服务的路径”画清楚，然后明确每一层节点是同质还是异质：同质的就按集群的思路管理，异质的就按分布式的思路治理。这样整个系统的扩容和故障处理方式才清晰。
6. 分布式系统的经典组合拳：缓存、锁、事务与调度
6.1 分布式缓存与Redis Cluster
LVS解决了流量分发的问题，但业务发展到一定规模之后，光靠加机器是不够的，还得从数据层面减少后端的压力，这就引出了缓存。Redis作为分布式缓存的事实标准，在生产环境里一般以集群模式部署，也就是Redis Cluster。
Redis Cluster采用无中心架构，数据自动被分片到16384个哈希槽中，每个节点负责一部分槽位。客户端请求某个key时，会通过CRC16算法和取模运算，直接定位到负责这个槽位的节点。这种分片方式天然支持横向扩容：当集群容量不够时，增加新节点并迁移部分槽位即可。
在LVS后端，Redis Cluster本身并不需要LVS做入口负载均衡，因为它已经有了一层“智能客户端”或者代理（如Redis Proxy）来做数据路由。但如果你用LVS作为Redis的入口，需要注意一个问题：LVS默认不感知Redis协议的MOVED重定向，如果后端是真正的分片集群，客户端在LVS层会拿到重定向响应，这可能导致额外的访问延迟。所以LVS适合接入到不具备分片能力的Redis主从架构场景，而Redis Cluster则应该让客户端直连或者通过专门的代理连接。
6.2 分布式锁：看似简单实则坑多
在分布式架构里，多个服务实例并发操作同一个资源是常态，比如扣减库存、领取优惠券。这时候需要一把分布式的锁来保证同一时刻只有一个实例能执行临界区代码。Redis分布式锁是这个领域最常见的实现方案。
一个基本的Redis分布式锁，核心操作是SET key value NX EX timeout：以某个key作为锁标识，设置一个随机value，并且带上过期时间。只有第一个设置成功的客户端才能拿到锁；其他客户端设置失败，说明锁已被占用，等待重试。使用完成后，用Lua脚本安全地删除锁，先验证value是否一致再删，避免误删别人的锁。
这里的坑主要集中在三点。第一，过期时间设置多长？太短，业务还在执行锁就过期了，其他线程会同时进来；太长，一旦持有锁的节点宕机，其他节点要等很久才能恢复。一般做法是设置一个经验值，比如10秒，然后开启看门狗机制自动续期，这个在Redisson框架里是内置的。第二，Redis主从切换时锁可能丢失，比如客户端A在主节点上加了锁，主节点还没同步到从节点就挂了，从节点顶上后锁数据丢了，客户端B就能成功加锁，导致互斥失效。要彻底解决这个问题，需要引入RedLock算法，在多个Redis节点上同时加锁，但RedLock也存在争议，业内讨论很多。第三，锁的粒度，不要一把锁锁住所有库存，最好按SKU维度拆锁，比如“sku:1001”一个锁、“sku:1002”一个锁，这样可以极大提升并发度。
6.3 分布式事务：一致性的代价从来都不低
分布式系统里，多个服务各自维护自己的数据库，但一个业务操作往往涉及多个服务的数据变更。比如下单流程里，订单服务要写订单表，库存服务要扣库存，积分服务要加积分。这三件事要么全部成功，要么全部回滚，这就是分布式事务要解决的问题。
经典的方案有几种。2PC（两阶段提交）是最早的方案，通过事务协调者先询问所有参与者能否提交，再统一提交或回滚。这个方案很好理解，但存在着协调者单点、参与者阻塞、同步性能差等问题，在高并发场景下不太实用。TCC（Try-Confirm-Cancel）是一种补偿型方案，每个业务操作需要实现三个接口：Try阶段做资源预留，Confirm阶段执行真正的业务提交，Cancel阶段做回滚。TCC对业务侵入性强，但性能和灵活性比2PC好很多，比较适合资金类、订单类等强一致场景。消息事务和本地消息表则属于最终一致性方案，核心思路是先把本地业务操作和消息发送放进同一个本地事务里，然后通过消息队列异步通知下游服务执行操作，下游失败时通过重试机制保证最终一致。
我在实际选型时有个很实际的建议：别一上来就追求强一致的分布式事务。大部分业务场景里，像“下单后扣库存”这种操作，用本地消息表加MQ重试就能解决，最终一致性的时间窗口用户根本感知不到。只有真金白银的资金操作，才需要考虑TCC甚至更严格的方案。分布式事务没有银弹，成本和复杂度都相当高，能用最终一致性解决的，就不要上强一致。
6.4 分布式调度与服务发现
分布式系统里还有一个很实际的问题：任务调度。你有一批定时任务，比如每天凌晨清理日志、每5分钟同步一次订单状态，这些任务在单机时代只需要Crontab就够了，但在分布式环境里，如果每个节点都执行一遍，就会重复执行。所以需要一套分布式任务调度平台，比如xxl-job或者Elastic-Job，通过数据库锁或者Zookeeper协调，保证同一个任务在同一时刻只被一个节点执行，同时还能做到任务分片，把一个大数据量的任务拆到多个节点上并行跑。
与任务调度紧密相关的，是服务发现。一个微服务有多个实例，调用方怎么知道这些实例的IP和端口？这就是注册中心的职责。常见的方案包括Zookeeper、Consul、Nacos等。服务启动时到注册中心注册自己的地址，调用方通过注册中心获取实例列表，再配合客户端负载均衡（如Spring Cloud LoadBalancer）选一个实例发起调用。这个机制和LVS的IPVS规则有个相似之处：都是维护“可用后端列表”，区别在于LVS是在内核层主动分发流量，服务发现是让客户端自己从列表里挑一个。
7. 架构演进视角：LVS在大型系统中的位置
7.1 一条从单机到云原生的演进路线
我经常跟团队说，架构演进是有路径的，不要一步到位，也不要摸黑硬闯。一个典型的演进路线大致是这样的：最开始是单机应用，应用和数据库都放在一台机器上，跑通业务优先；然后用户量上来了，把数据库和应用分开部署，这是最简单的一步；再往后，应用服务器变成多台，前面挂一台Nginx做反向代理和负载均衡，数据库做读写分离，再引入Redis缓存。
到了一定规模之后，Nginx单机也成了瓶颈，这时候LVS就该出场了。在最外层部署一对LVS（一主一备），用Keepalived做高可用，Nginx退到第二层，只做7层路由和转发。如果后端是微服务架构，服务之间的调用则通过注册中心和RPC框架自行解决，LVS主要管理外部流量进入系统这一层的调度。
在云原生时代，Kubernetes的Service组件本身已经内置了负载均衡能力，kube-proxy支持iptables和IPVS两种模式。实际上，很多K8s集群就是把kube-proxy的mode设置为ipvs，借助LVS的内核能力来加速Service的流量转发。所以你看，LVS并没有因为云原生而退场，它只是从“你需要自己动手部署的软件”变成了“底层基础设施的一部分”，换了一种方式继续发挥价值。
7.2 大流量入口的分层设计
生产环境里，一个真正的高并发入口，通常不是靠单一组件扛下来的，而是分了几层。最外层是DNS，用来做地域级别的流量调度，把不同区域的用户解析到不同的机房IP。紧接着就是LVS这一层，负责把海量连接均匀分发到机房的多个Nginx入口节点。再往内是Nginx层，做域名路由、HTTP缓存、跨域、限流和SSL终结。最后才到应用服务层。
我把这层设计总结成四个字：层层分流。每一层只处理它最擅长的工作，不把压力往后面丢。DNS解决“用户离哪个机房近”，LVS解决“一栋楼里流量怎么分到每个大门口”，Nginx解决“每个大门口的车怎么停到对应的车位”。如果这中间哪一层想包揽所有功能，那它很快会成为整个系统的性能瓶颈。
7.3 实际选型建议
说了这么多，给你一个可以直接参考的选型建议。如果你的系统并发量在几千QPS级别，Nginx一台机器加一个域名轮询基本就够用了，不需要上LVS。当Nginx的并发连接数打到几万、CPU使用率持续高位，或者你确实需要一台机器扛住几十万TCP连接时，LVS就该登场了。至于Kubernetes环境，K8s集群的Node数量比较多时，我也会把kube-proxy切换到IPVS模式，避免iptables规则的线性遍历拖慢数据路径。
一定记住：架构是演进出来的，不是设计出来的。不要一上来就堆满所有组件。每引入一个组件，都会带来额外的运维成本和故障面。LVS虽然成熟稳定，但也需要你理解它的工作原理、配置好高可用、并教会团队怎么排查相关问题，否则它也可能成为整个架构里最神秘的那个“黑盒”。
8. 常见问题与排查实录
8.1 different numbers of ports报错
这个报错我在排查时遇到过好几次，典型场景是在配置IPVS规则的时候，虚拟服务和真实服务器的端口定义不匹配。比如执行ipvsadm -A -t 192.168.1.100:80定义了VIP的80端口，然后添加RS时写成了ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.10:8080 -g。如果是在某些严格校验的输入场景下，或者你同时用了-F防火墙标记（fwmark）的方式定义虚拟服务，IPVS会提示端口数量不一致的错误。
排查思路其实很简单：先把当前规则清掉，确认VS的定义方式。如果是基于IP+端口（-t或-u），RS的端口和VS端口可以不同，但要确保每个RS的端口都明确指定了；如果是基于防火墙标记-F，则虚拟服务本身不含端口，RS配置里的端口就必须省略，否则端口数量对不上。
bash复制# 清理所有IPVS规则，重新开始
ipvsadm -C
# 基于IP+端口定义VS
ipvsadm -A -t 192.168.1.100:80 -s wrr
# 添加RS时，明确指定RS的服务端口
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.10:8080 -g -w 1
# 查看规则是否正常
ipvsadm -L -n
8.2 DR模式RS收不到请求
DR模式配置完成后，客户端访问VIP没响应，但RS上直接访问服务正常，这类问题90%出在RS的ARP配置上。我之前踩过最典型的一次是：只在/etc/sysctl.conf里配置了net.ipv4.conf.all.arp_ignore = 1，没有配置net.ipv4.conf.lo.arp_ignore = 1，结果VIP地址虽然挂在了lo接口上，但RS依然会响应ARP请求，导致局域网内ARP表混乱，部分请求被交换机转发到了错误的MAC地址。
另外还要检查RS上的路由表。在DR模式下，RS处理完请求后，响应包的源IP是VIP，目的IP是客户端IP。如果RS默认路由指向的不是网关，而是一台不知道去往客户端网段的设备，响应就会丢失。确保RS有默认路由default via 网关IP，并且这台RS不对VIP所在的网段做特殊策略路由。
8.3 Keepalived脑裂
两台Keepalived同时持有VIP，就会造成“脑裂”。表现是客户端访问VIP时，一会儿到主节点、一会儿到备节点，后端健康检查也可能出现混乱。脑裂的最常见原因是VRRP组播报文被防火墙拦截，或者两台机器的virtual_router_id不一致。前者会让备节点收不到主节点的通告，误以为主节点挂了，于是主动接管VIP。
排查时先看两台机器上的ip addr，确认VIP是否同时存在；再看系统日志/var/log/messages里有没有VRRP相关的状态切换记录。解决办法是，确保两台机器都属于同一个VRRP组（virtual_router_id一致），并在防火墙放行VRRP协议（协议号112），比如在firewalld里执行firewall-cmd --add-rich-rule='rule protocol value="vrrp" accept' --permanent。
8.4 故障速查表
这里把我这几年遇到过的典型问题整理成一个速查表，方便你直接对照定位问题：
| 故障现象 | 可能原因 | 排查方向 |
|---|---|---|
| 客户端无法访问VIP | LVS服务未启动或内核模块未加载 | ipvsadm -L -n确认规则存在 |
| VIP能ping通但业务不通 | RS端口检查失败或RS服务未启动 | 在RS本机测试服务端口 |
| 部分请求超时、部分正常 | RS上ARP抑制配置缺失 | 检查arp_ignore和arp_announce |
| ipvsadm添加RS报端口报错 | VS与RS端口定义方式不一致 | 确认VS是端口还是fwmark方式定义 |
| 主节点挂了VIP不迁移 | VRRP被防火墙拦截或配置不一致 | 检查防火墙和virtual_router_id |
| 流量全部打到一台RS | 权重配置不合理或算法不适用 | 核对权重和调度算法 |
| 后端服务恢复了但流量不回来 | Keepalived健康检查周期未到 | 等待delay_loop周期后确认 |
最后再分享一个小经验。排查LVS问题时，不要一开始就盯着配置看，先按顺序确认三个问题：VIP能不能通？IPVS规则在不在？后端服务健不健康？这三个问题定位完，绝大多数故障都能找到方向。实际工作中，我见过太多同事在配置文件里反复找原因，最后发现只是Keepalived进程没起来。基础问题排到最后才排查，这是最典型的低级错误。