从单机Nginx到集群LVS：我的网站流量增长后，负载均衡架构升级踩坑实录
从单机Nginx到集群LVS：我的网站流量增长后，负载均衡架构升级踩坑实录
去年这个时候，我们的电商平台日均PV还不到10万，单台Nginx服务器轻松应对。直到那个黑色星期五——促销活动开始后，监控面板上的连接数曲线像坐了火箭，服务器响应时间从200ms飙升到5秒以上。那一刻我意识到：是时候告别单机负载均衡的时代了。
1. 为什么选择LVS而不是继续升级Nginx？
当流量开始突破单机Nginx的处理极限时，我们首先尝试了最直观的解决方案：垂直扩展。给服务器加了CPU和内存，Nginx worker_processes调到了auto模式，甚至启用了最新的HTTP/2协议。这些措施确实带来了一些改善，但很快就遇到了新的瓶颈：
Nginx在七层负载均衡的局限性：
- 每个请求都要完整解析到应用层，CPU消耗随QPS线性增长
- 长连接保持需要消耗大量文件描述符
- 单点故障风险无法通过Nginx自身解决
相比之下，LVS作为四层负载均衡器的优势就凸显出来了：
| 特性 | Nginx | LVS |
|---|---|---|
| 处理层级 | 应用层(7层) | 传输层(4层) |
| 最大并发连接数 | 约5万 | 可达百万级 |
| 协议支持 | HTTP/HTTPS等 | 所有TCP/UDP协议 |
| 资源消耗 | 较高 | 极低 |
| 故障转移速度 | 秒级 | 毫秒级 |
# 测试Nginx最大连接数的简单方法（需先安装ApacheBench） ab -c 5000 -n 100000 http://yourdomain.com/实际测试中发现，当并发超过8000时，Nginx的响应延迟开始显著上升，而LVS在10万并发下仍能保持稳定的转发性能。
2. DR模式部署中的那些"坑"与解决方案
选择DR(Direct Routing)模式主要考虑其高性能特性——响应数据可以直接由Real Server返回客户端，不必经过Director。但实际部署时却遇到了几个意想不到的问题。
2.1 ARP广播风暴问题
第一天上线就遭遇网络瘫痪。通过tcpdump抓包发现，VIP的ARP请求被所有Real Server响应，导致交换机MAC表不断刷新：
# 抓包看到的异常ARP响应 18:30:45.123456 ARP, Reply 192.168.1.100 is-at 00:0c:29:xx:xx:xx (Real Server 1) 18:30:45.123457 ARP, Reply 192.168.1.100 is-at 00:0c:29:yy:yy:yy (Real Server 2)解决方案：
- 在Real Server上设置arp_ignore和arp_announce参数：
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce- 在每台Real Server的lo接口配置VIP：
ifconfig lo:0 192.168.1.100 netmask 255.255.255.255 up2.2 防火墙标签导致的调度异常
当同时提供HTTP和HTTPS服务时，发现用户的HTTPS请求可能被调度到与HTTP不同的Real Server上，导致会话丢失。这是因为LVS默认将不同端口视为独立服务。
通过iptables打标记解决：
iptables -t mangle -A PREROUTING -p tcp -d 192.168.1.100 --dport 80 -j MARK --set-mark 1 iptables -t mangle -A PREROUTING -p tcp -d 192.168.1.100 --dport 443 -j MARK --set-mark 1然后在ipvsadm中使用-f参数基于标记创建规则：
ipvsadm -A -f 1 -s wlc ipvsadm -a -f 1 -r 192.168.1.101 -g -w 3 ipvsadm -a -f 1 -r 192.168.1.102 -g -w 23. 生产环境中的关键配置与调优
经过三个月的运行迭代，我们总结出以下关键配置点：
3.1 内核参数优化
# 防止IP冲突 net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2 # 提高LVS性能 net.ipv4.vs.conntrack = 1 net.ipv4.vs.expire_nodest_conn = 13.2 健康检查配置
使用keepalived实现高可用和健康检查：
virtual_server 192.168.1.100 80 { delay_loop 6 lb_algo wlc lb_kind DR persistence_timeout 3600 real_server 192.168.1.101 80 { weight 3 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } }3.3 监控指标重点关注项
通过ipvsadm -Ln --stats监控的关键指标：
| 指标 | 健康阈值 | 说明 |
|---|---|---|
| ActiveConn | < 80%最大容量 | 当前活跃连接数 |
| InActConn | 持续增长需警惕 | 非活跃连接数 |
| CPS | < 5000/s | 每秒新建连接数 |
| InPkts/OutPkts 比值 | 接近1:1 | 进出包比例异常可能丢包 |
4. 与Nginx的协同工作模式
完全替换Nginx不是明智之举，我们最终采用的混合架构：
客户端 → LVS集群(DR模式) → Nginx集群 → 应用服务器分工协作：
- LVS：负责四层流量分发和高并发连接处理
- Nginx：处理七层协议、SSL卸载、缓存等高级功能
- 应用服务器：专注业务逻辑处理
这种架构在"双十一"期间成功支撑了峰值超过50万QPS的流量，平均延迟控制在150ms以内。最重要的是，当某台Nginx服务器出现故障时，LVS能在毫秒级完成流量切换，用户完全无感知。
从单机Nginx到LVS集群的升级过程中，最大的收获不是技术方案本身，而是理解了不同层级负载均衡的适用场景。有时候最先进的方案不一定最适合，关键是要根据业务特点和增长预期做出平衡选择。