LVS负载均衡与keepalived高可用实战：从DR模式到生产排错

1. 先弄明白一件事：LVS到底解决什么问题

聊LVS之前，先说个我这两年感受特别深的现象。每次和年轻一点的同行聊负载均衡，他们第一反应就是Nginx、HAProxy，再问细一点就是K8s的Ingress、Service Mesh。这没错，这些确实是当下最主流的流量入口方案。但真到了大流量核心链路，你会发现LVS依然默默地趴在最前面，扛着每天几个亿的请求，而且一跑就是好几年不带重启的。

LVS，全称Linux Virtual Server，是章文嵩博士在1998年发起的开源项目。它工作在Linux内核态，通过IP Virtual Server（IPVS）框架实现四层负载均衡。翻译成人话就是：它直接改数据包的目标地址或MAC地址，把进来的请求分发到后端一堆真实服务器上。因为在内核态干活，它不像Nginx那样要经过用户态和内核态的反复切换，单机性能可以做到远超七层代理。在核心生产环境里，LVS通常作为最前端的接入层，后面再挂Nginx做七层路由和业务转发。

所以这篇内容定位很明确：第一，把LVS的工作原理讲透，不是停留在“它是个负载均衡器”这种层面；第二，给出我实际部署中用到的完整方案和配置，可以直接抄作业；第三，讲讲那些官方文档不会告诉你的坑，尤其是ARP问题、VIP漂移这些生产环境的经典故障。适合谁看？后端开发、运维工程师、SRE，以及所有正在纠结“到底该用LVS还是Nginx”的人。

2. 动手之前先把架构想清楚：四层和七层的边界在哪

很多人对LVS的第一反应是“现在还有必要学这个吗”。我的回答是，有必要，前提是你得先理解它和七层负载均衡的分工边界。

2.1 四层转发和七层转发到底差在哪

先说一个最简单的判断标准：Nginx处理的是HTTP协议，它能看到URL、Header、Cookie这些应用层信息，所以可以做非常精细的路由规则，比如“/api开头的请求转发到A组服务”“带特定Cookie的请求走新版本”这种。但代价是，每一个请求都要在用户态做完整的协议解析，CPU的消耗非常高。

LVS看不到这些，它只认IP、端口、协议类型。进来的包，LVS按照预设的调度算法，直接改包的目标地址或者MAC，然后扔给后端。这个动作发生在内核协议栈里，没有用户态的上下文切换，没有协议解析的额外开销。所以同样的硬件配置，LVS能支撑的并发连接数和吞吐量，远远超过Nginx。

我自己的一个线上集群，接入层两台LVS，每台峰值能跑到将近20万QPS，CPU使用率基本稳定在30%以下。同样的流量想让Nginx扛，至少得横向铺一二十台才稳得住。

2.2 生产环境里一套典型的LVS+Nginx架构长什么样

从上面这个对比你应该能看出来，LVS和Nginx不是替代关系，而是配合关系。我目前维护的核心链路是这样的：

code复制用户请求
    ↓
DNS解析到VIP（虚拟IP）
    ↓
LVS主节点（keepalived管理VIP漂移）
    ↓
LVS备节点（主节点挂了自动接管VIP）
    ↓
Nginx集群（七层反向代理，按域名/URI做路由）
    ↓
Tomcat/Spring Boot业务集群
    ↓
MySQL/Redis等数据层

最外层LVS干的是“粗活”：把海量连接快速分发给后面的Nginx集群。Nginx干的是“细活”：根据请求的具体内容做路由、做限流、做缓存。这一层一层剥下来，每一层都只做自己最擅长的事，系统才扛得住。

我之前还见过一种“裸奔”的用法，LVS直接转发到应用服务器，中间不挂Nginx。小规模业务没问题，请求量一旦上来，后端应用服务器直接暴露在四层流量下，没法做精细的路由和防护，扩容也不灵活。除非业务极其简单，不然我不建议这么干。

3. 三种转发模式选型：DR、TUN、NAT各自能干什么不能干什么

LVS有三种工作模式，分别是DR（Direct Routing，直接路由）、TUN（IP Tunneling，IP隧道）、NAT（Network Address Translation，网络地址转换）。这是学习LVS最核心的部分，也是选型最容易出错的部分。我一个个说。

3.1 DR模式：生产环境用最多的方案

DR模式的核心逻辑简单粗暴：LVS只负责改数据链路层的MAC地址，不改IP地址。请求到达LVS后，LVS根据调度算法选一台后端RealServer，把数据帧的目标MAC改成那台RealServer的MAC，然后重新扔回交换机。RealServer收到这个帧，发现目标IP是VIP（因为VIP配在了RealServer的loopback接口上），就接收处理。响应数据包不走LVS，直接由RealServer回给客户端。

这个设计妙在哪？响应流量不经过负载均衡器，LVS只处理入站请求，压力直接减半。所以DR模式是三种模式里吞吐量最高的，也是生产环境最主流的用法。

但DR模式有个硬前提：LVS和所有RealServer必须在同一个物理二层网络里。因为MAC地址交换只在广播域内有效，跨网段就玩不转了。另外有个最关键的细节：RealServer必须在loopback接口上配置VIP，同时抑制ARP响应，否则客户端直接ARP请求VIP时，RealServer会抢答，流量直接绕过LVS打到后端的某台机器上。这个配置我后面部署篇会详细给。

3.2 TUN模式和NAT模式什么时候用

TUN模式是LVS把请求通过IP-IP隧道封装一层，转发给RealServer，RealServer解开隧道后处理，响应直接回客户端。好处是不受二层网络限制，LVS和RealServer可以跨网段部署。缺点是隧道封装有额外开销，而且每台RealServer都要支持隧道协议。我实际工作中用TUN模式的机会非常少，除非网络架构确实无法满足DR模式的同网段要求，否则不推荐优先选它。

NAT模式是LVS做地址转换，改写数据包的目标IP为RealServer的IP。RealServer处理完，响应再回到LVS，LVS把源IP改回VIP，再回给客户端。好处是RealServer只需要配私网IP，隐藏在后端比较安全，而且不要求同网段。坏处是流量来了要经过LVS，走了还要经过LVS，LVS很容易成为瓶颈。我在小规模场景（几台到十几台后端）用过NAT模式，规模上去之后还是老老实实换回了DR。

3.3 模式选型一张表说清楚