1. LVS持久连接的核心价值与场景定位在分布式系统架构中会话保持Session Sticky是个经典难题。想象这样一个场景用户登录电商平台后购物车数据被存储在某个后端服务器上如果下次请求被负载均衡器分配到其他节点就会出现购物车清空的异常。LVS的持久连接Persistent Connection正是为解决此类问题而生。我最早接触这个功能是在2015年一个金融支付系统中。当时用户投诉支付过程中频繁要求重复登录排查发现LVS的RR轮询算法导致TCP长连接被分配到不同Real Server。启用persistent参数后同一客户端的连续请求被固定分配到最初选择的服务器问题迎刃而解。持久连接的实现原理本质上是会话跟踪。LVS会在内存中维护一个客户端IP/端口→Real Server的映射表通过ip_vs_conn结构体记录连接状态。这个设计的精妙之处在于工作在内核层性能损耗极小实测吞吐量降低3%支持超时时间动态调整默认300秒可基于客户端IP、Cookie等多种维度保持粘滞2. 持久连接的实现机制深度解析2.1 内核级连接跟踪表LVS通过ip_vs_conn_tab哈希表维护所有活动连接。当首个SYN包到达时会创建如下结构体struct ip_vs_conn { struct list_head c_list; // 哈希链表 __be32 caddr; // 客户端IP __be16 cport; // 客户端端口 __be32 vaddr; // VIP __be16 vport; // VIP端口 __be32 daddr; // Real Server IP __be16 dport; // Real Server端口 unsigned long timeout; // 超时时间 struct ip_vs_conn *control; // 控制连接FTP等 };关键参数通过ip_vs_conn_hashkey()计算哈希值快速定位到对应Real Server。这个设计使得连接查找时间复杂度为O(1)实测在100万并发连接时查询延迟仍小于0.1ms。2.2 持久化服务配置详解在ipvsadm中启用持久化服务需要添加-p参数ipvsadm -A -t 192.168.1.100:80 -s rr -p 600这表示-t指定VIP和端口-s rr使用轮询调度算法-p 600设置持久化超时为600秒重要细节超时时间需要根据业务特点设置电商类建议300-600秒金融支付类建议1800秒以上设置过长会导致连接表膨胀持久化权重高于调度算法。即使配置了rr轮询同一客户端的请求仍会固定转发。2.3 多维度会话保持方案除了默认的IPPort识别LVS还支持更灵活的会话保持方式类型配置参数适用场景优缺点对比标准IP持久化-p简单HTTP业务实现简单但移动端IP会变防火墙标记持久化-M --pe-fwm需要跨端口会话保持需配合iptables打标记Cookie持久化--pe-cookie SESSIONID需要应用层识别的场景需应用配合设置Cookie案例某视频网站使用Cookie持久化配置ipvsadm -A -t 192.168.1.100:80 -s rr --pe-cookie SESSIONID这样即使客户端IP变化只要Cookie中的SESSIONID相同就会被分配到同一台Real Server。3. 生产环境配置实战3.1 基础拓扑搭建典型LVS-DR模式部署架构Client - LVS Director - Real Server (VIP配置在lo:0)关键配置步骤Real Server上配置VIP避免ARP问题echo 1 /proc/sys/net/ipv4/conf/lo/arp_ignore echo 2 /proc/sys/net/ipv4/conf/lo/arp_announce ifconfig lo:0 192.168.1.100 netmask 255.255.255.255 upDirector上配置IPVS规则ipvsadm -A -t 192.168.1.100:80 -s rr -p 600 ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.101 -g ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.102 -g重要提示DR模式要求Real Server的VIP必须配置在lo接口且关闭ARP响应否则会导致网络环路。3.2 高级参数调优通过/proc/sys/net/ipv4/vs/可以调整内核参数# 查看当前连接数 cat /proc/net/ip_vs_conn # 调整持久连接哈希表大小默认4096 echo 16384 /proc/sys/net/ipv4/vs/conn_tab_size # 修改连接超时需同时调整以下三个参数 echo 900 /proc/sys/net/ipv4/vs/expire_nodest_conn echo 600 /proc/sys/net/ipv4/vs/expire_quiescent_template echo 60 /proc/sys/net/ipv4/vs/expire_sync_period经验值参考每1GB内存可维持约10万条连接记录conn_tab_size应设置为预估最大连接数的1.5倍超时时间不宜超过TCP会话超时通常1200秒3.3 健康检查与故障转移持久连接需要特别注意Real Server故障时的处理# 启用LVS自带健康检查 ipvsadm --set-tcp tcp --tcp-timeout 10 --tcp-retries 2 # 或者使用keepalived实现高级检测 vrrp_instance VI_1 { notify_master /etc/keepalived/check_servers.sh }当Real Server宕机时新连接会被调度到存活节点已持久化的连接会收到TCP RST客户端需要具备重连机制4. 常见问题排查实录4.1 连接不持久问题排查现象客户端请求仍然被轮询分配到不同服务器排查步骤确认ipvsadm -Ln输出包含PersistentConn标志TCP 192.168.1.100:80 rr persistent 600检查内核模块是否加载lsmod | grep ip_vs监控连接表变化watch -n 1 cat /proc/net/ip_vs_conn | grep 192.168.1.100常见原因防火墙清除了连接跟踪标记客户端IP在请求间发生变化如移动网络持久化时间设置过短4.2 内存消耗过高问题现象ip_vs_conn占用内存持续增长优化方案合理设置超时时间ipvsadm -E -t 192.168.1.100:80 -s rr -p 300定期清理空闲连接echo 1 /proc/sys/net/ipv4/vs/expire_quiescent_template对于短连接业务考虑使用-p 0禁用持久化4.3 性能数据参考测试环境8核CPU/16GB内存万兆网卡场景请求速率(QPS)平均延迟CPU占用无持久化125,0001.2ms68%IP持久化(p300)121,0001.3ms72%Cookie持久化98,0001.8ms85%结论IP持久化性能损耗约3-5%Cookie持久化损耗约20%需根据业务特点权衡选择。5. 进阶应用场景5.1 混合调度策略实现对于需要兼顾会话保持和负载均衡的场景可以ipvsadm -A -t 192.168.1.100:80 -s wlc -p 600 ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.101 -g -w 3 ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.102 -g -w 1这样配置表示新连接按权重(3:1)分配已有持久化连接保持原路径适合服务器配置不均等的场景5.2 与Keepalived的集成典型的高可用配置示例virtual_server 192.168.1.100 80 { delay_loop 6 lb_algo wlc lb_kind DR persistence_timeout 600 protocol TCP real_server 192.168.1.101 80 { weight 3 TCP_CHECK { connect_timeout 5 } } }这种方案的优势在于自动健康检查故障时VIP漂移配置集中管理5.3 云环境下的特殊处理在AWS/Aliyun等云环境中需要注意禁用云平台的负载均衡器如ELB处理VPC的源地址转换SNATecho 1 /proc/sys/net/ipv4/vs/snat_reroute可能需要在Real Server上配置TOA模块获取真实IP某跨境电商的解决方案是使用IP隧道模式LVS-TUN通过--pe-fwm匹配防火墙标记配合Consul实现服务自动注册