LVS负载均衡配置的核心答案是：在多数生产环境下，采用DR模式配合Keepalived实现高可用，是性能与稳定性最均衡的落地方案。本文不讲虚的，直接拆解从零到一的配置全过程，并解答部署中最容易踩的坑，如果你正在规划集群架构，或者被“调度器单点故障”困扰，这篇内容值得你花几分钟看完。
先搞清楚LVS凭什么能扛住高并发
LVS（Linux Virtual Server）工作在网络的第四层，也就是说它直接处理TCP/UDP数据包，不解析HTTP头部，这一特性决定了它的转发速度极快，业内专家指出，在纯四层转发场景下，LVS的吞吐能力远超常见的七层反向代理工具，这也是它常被用作大型网站入口流量的第一道闸门的原因。
LVS有三种工作模式,很多新手容易搞混，我用最直白的话讲清楚它们的本质区别，这有助于你在配置前做出正确选择。
NAT模式：最安全但最受限
它的原理是修改数据包的目的IP地址,请求进来时，LVS把目标地址从VIP改成后端真实服务器的IP；响应回来时，再把源地址改回VIP，因为进出流量都要经过调度器，调度器容易成为瓶颈，在业务流量不大、后端服务器数量较少（比如5台以内）的内部系统中可以用它。
DR模式：生产环境的主力军
DR模式只修改数据包的目标MAC地址,不修改IP，这意味着响应包直接从后端服务器回给客户端，不再绕道调度器，这样一来，调度器只负责处理入站请求，压力骤减。绝大多数互联网公司的核心链路都用DR模式。
TUN模式：适合跨地域的分布式集群
它把原始数据包封装在一个新的IP包里,可以穿透不同网段，适用于后端服务器不在同一机房、但又要统一调度的情况，配置复杂度相对高，日常场景用得少。
在动手配置前,你需要清楚这一点：如果你在百度搜索“lvs负载均衡配置方法”时到了这一步，那么你的目标大概率是DR模式，后面的命令和配置全部围绕DR模式展开。
LVS负载均衡配置方法与完整实操步骤
假设一个典型的应用场景：你手头有两台Web服务器（IP分别为192.168.1.11和192.168.1.12），需要把它们组成一个对外提供服务的集群，VIP（虚拟IP）设为192.168.1.100，调度器本身有两张网卡，一张连接外网，一张连接内网。
第一步：服务器基础环境准备
在开始敲命令前,确认所有机器的内核支持IPVS模块，用下面的命令验证：
modprobe ip_vs
lsmod | grep ip_vs如果没有任何输出,说明内核模块没加载，执行完上述命令后，再查看一下系统是否安装了管理工具：
yum install -y ipvsadm
这个工具是操作LVS规则的命令行客户端,必须安装，为了让LVS在后端服务器宕机时能自动剔除故障节点，我们还需要安装Keepalived：
yum install -y keepalived第二步：配置LVS调度规则（核心命令）
这一步是最核心的,我们要在调度器上创建VIP，并添加后端真实服务器（Real Server），假设你想使用加权轮询算法（wr），具体命令如下：
ip addr add 192.168.1.100/32 dev eth0
ipvsadm -A -t 192.168.1.100:80 -s wrr
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.11:80 -g -w 1
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.12:80 -g -w 1命令解释：
-A表示添加一个虚拟服务。-t指定TCP协议和VIP端口。-s wrr指定调度算法为加权轮询。-a表示添加真实服务器。-r指定真实服务器的IP和端口。-g表示使用DR模式，这是关键参数。-w设置权重，权重高的机器分到的请求多。
但光有调度规则还不行，因为DR模式要求后端服务器也必须配置VIP，且要抑制对ARP请求的响应，否则，当客户端请求VIP时，后端服务器可能会和调度器抢答，导致整个集群瘫痪。
配置后端真实服务器的ARP抑制
在后端两台Web服务器上分别执行：
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce同时在下发请求时,把VIP配置在回环接口上，并关闭ARP响应：
ifconfig lo:0 192.168.1.100 netmask 255.255.255.255 broadcast 192.168.1.100 up
route add -host 192.168.1.100 dev lo:0这就解决了IP冲突问题,这一步如果不做，后续测试会直接失败，这是很多新手最容易踩的坑。
第三步：用Keepalived实现健康检查和高可用
规则手动配置虽然简单,但机器重启后规则就丢了，而且调度器本身挂了整个集群就瘫了，所以生产环境必须用Keepalived，它的两个核心作用：一是对后端服务器做健康检查，二是实现调度器的故障转移。
修改/etc/keepalived/keepalived.conf配置文件，核心内容如下：
global_defs { router_id LVS_DEVEL } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.1.100 } } virtual_server 192.168.1.100 80 { delay_loop 6 lb_algo wrr lb_kind DR persistence_timeout 50 real_server 192.168.1.11 80 { weight 1 TCP_CHECK { connect_port 80 connect_timeout 3 } } real_server 192.168.1.12 80 { weight 1 TCP_CHECK { connect_port 80 connect_timeout 3 } } }
配置中的lb_kind DR指回我们前面说的DR模式，lb_algo wrr指加权轮询，这里顺带提一下persistence_timeout，它的作用是让来自同一个IP的请求在一定时间内保持发往同一台后端机器，防止会话丢失。
启动服务并设置开机自启：
systemctl enable keepalived
systemctl start keepalived如果只有一台调度器做测试,可以搭建两台做双机热备，在两台调度器上配置相同的虚拟服务器规则，但将state分别设为MASTER和BACKUP，priority分别设为100和90，当主调度器宕机时，备用调度器会自动接管VIP，整个过程对客户端无感知。
第四步：验证配置是否生效
配置写完,用以下命令验证效果，首先查看VIP是否在当前机器上：
ip addr show eth0如果看到192.168.1.100绑在网卡上，说明Keepalived已经开始工作，然后查看LVS的转发规则表：
ipvsadm -L -n输出结果会显示当前生效的虚拟服务和真实服务器,并标注每条规则对应的调度算法，持续观察连接状态：
watch -n 1 ipvsadm -L --rate这个命令每秒刷新一次,可以看到每秒新建连接数和转发字节数，当负载请求打进来时，你能直观地看到流量在两个真实服务器之间是如何分配的。
LVS和Nginx哪个更适合你的集群
很多人会问“lvs和nginx负载均衡哪个好”，这个问题其实不存在绝对的答案，因为两者的定位完全不同，我见过太多团队试图用前端Nginx做所有事，结果在流量翻十倍时被压垮，而LVS作为四层转发，它不关心业务数据，只关心端口和IP。
它们的核心差异在以下几方面：
- 性能消耗：LVS在内核态处理数据包，性能开销极低；Nginx需要解析HTTP请求，CPU密集型的操作，会消耗更多资源。
- 功能边界：LVS只做转发，无法根据URL或Cookie做路由；Nginx可以做SSL终止、HTTP重写、缓存等丰富的七层功能。
- 部署位置：业界通行的做法是LVS在前面扛流量，Nginx在中间做业务路由，也就是常说的“四层接入，七层分流”，这个架构下的配合关系大于竞争关系。
行业共识认为,在吞吐量要求苛刻的场景引入LVS时，把静态资源缓存和请求改写交给Nginx去做，是最稳定的组合，不要试图用其中一个替代另一个。
部署LVS时常见的坑与解决建议
即便你照着上面的步骤配置没报错,生产环境里的网络问题也会让你头疼，我总结几个高频故障点。
lvs配置后无法访问VIP
检查一下防火墙,无论是调度器还是后端服务器，只要开启了iptables或firewalld，对VIP的访问就有可能被拦，建议先临时关闭防火墙测试：
systemctl stop firewalld如果确认是防火墙问题,放行VIP的80端口和Keepalived的VRRP协议（组播地址224.0.0.18），很多情况下问题出在系统设置了rp_filter反向路径过滤，导致后端服务器丢弃来自调度器的数据包，把/proc/sys/net/ipv4/conf/all/rp_filter设为0即可。
集群响应慢且大量连接处于TIME_WAIT状态
这通常不是LVS本身的问题,而是后端Web服务的连接处理参数没调优，检查一下sysctl中的timeout设置，同时注意关闭Keepalived配置中的persistence_timeout或缩小它的值，这个值如果设置得过大，长尾的请求会一直固定在同一台服务器上，导致负载不均。
高并发场景下丢包严重
如果确认网络带宽没跑满但依然出现丢包,多半是调度器内核的socket缓冲区设置太小，通过修改以下参数增大缓冲区：
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216只要内核参数设置合理,LVS在千兆网卡环境下跑满线速是完全没问题的，国内相当一部分一线互联网公司在早期架构中都采用过类似的配置方案。
LVS负载均衡配置常见问题解答
为了让你在使用中少走弯路,这里解答两个出现频率极高的问题。
LVS的VIP可以配置在不同网卡上吗？
可以,但需要注意，VIP所在的网卡必须与真实服务器之间在三层网络可达，并且在配置DR模式时，VIP建议使用32位掩码，如果你配置了多个VIP，且它们分布在不同的物理网卡上，请确保后端服务器的回环接口也绑定了对应的VIP，否则调度会失败。
Keepalived里的健康检查方式有哪些？
Keepalived支持两种常见的健康检查方法,一种是TCP_CHECK，它直接检测后端的端口是否能建立TCP连接，适合大多数场景，另一种是HTTP_GET，它会向后端发送真实的HTTP请求，更适合需要校验业务返回码的场景，如果后端是一个纯内网的高性能数据库，用TCP_CHECK足够，检查间隔建议设置在5到10秒之间，过于频繁会对后端造成无谓的连接压力。
合理利用LVS构建均衡的流量入口,是保障业务稳定性的关键一环，配置完成后，建议先在非业务高峰期做一次全链路的压力测试，观察调度器的CPU和内存占用变化，你会惊喜地发现，它比你想象中要“从容”得多。