负载均衡LVS与HAProxy高可用实战教程

负载均衡是高可用架构的核心组件，通过将流量分发到多台后端服务器，实现横向扩展、提高并发处理能力、消除单点故障。LVS（Linux Virtual Server）是Linux内核级四层负载均衡，性能极高，适合大流量入口；HAProxy是高性能的四层/七层负载均衡，功能丰富，支持HTTP/TCP负载均衡、健康检查、会话保持、SSL终止等，是目前最流行的开源负载均衡软件。无论是VPS、云服务器还是独立服务器集群，通过LVS+Keepalived或HAProxy+Keepalived的高可用架构，可以构建稳定、高性能、无单点故障的负载均衡系统。本文将详细介绍负载均衡原理、LVS配置与DR模式、HAProxy配置与七层负载、Keepalived高可用、健康检查与会话保持、性能优化与最佳实践。

一、负载均衡原理与架构选型

负载均衡（Load Balancer，LB）是将网络流量分发到多台后端服务器（Real Server，RS）的设备或软件，核心目标：1. 横向扩展：通过增加后端服务器提升整体处理能力，突破单服务器性能瓶颈；2. 高可用：后端服务器故障时自动摘除，流量分发到健康服务器，消除单点故障，服务不中断；3. 性能优化：根据后端负载智能分发，避免某台服务器过载，提升整体响应速度；4. 安全防护：负载均衡器作为入口，可做DDoS防护、WAF、限流、访问控制，保护后端服务器。负载均衡分类：1. 按OSI层级分：四层负载均衡（传输层，基于IP+端口，LVS、F5、HAProxy TCP模式），性能高，处理快，不解析应用层内容；七层负载均衡（应用层，基于URL、域名、Cookie、HTTP头，HAProxy HTTP模式、Nginx、阿里云SLB七层），功能丰富，可做内容路由、会话保持、SSL终止、URL重写，但性能略低于四层；2. 按软硬件分：硬件负载均衡（F5 BIG-IP、A10、深信服AD，性能极高、功能完善、价格昂贵，适合大型企业）、软件负载均衡（LVS、HAProxy、Nginx、Envoy，开源免费、灵活可定制、性能足够，适合大多数场景）；3. 按部署位置分：入口负载均衡（公网入口，分发到多台Web服务器）、内部负载均衡（微服务间调用，服务发现+负载均衡，如K8s Service、Nacos）。常见负载均衡软件对比：1. LVS：Linux内核级四层负载均衡，工作在Netfilter框架，性能极高（单机可抗百万级并发、千万级PPS），支持NAT/DR/TUN三种模式，只做四层转发，不支持七层功能（URL路由、Cookie会话保持），配置较复杂，适合大流量入口、CDN节点、游戏服等高性能场景；2. HAProxy：高性能四层/七层负载均衡，支持TCP和HTTP模式，功能丰富（健康检查、会话保持、SSL终止、ACL路由、限流、统计面板），性能优秀（单机数十万并发），配置灵活，文档完善，是目前最流行的通用负载均衡软件，适合Web服务、API网关、数据库读写分离、微服务等场景；3. Nginx：Web服务器兼七层负载均衡，HTTP负载均衡功能强（反向代理、缓存、SSL、gzip），支持TCP/UDP负载均衡（1.9+），但健康检查和会话保持功能较弱（需付费版Nginx Plus或第三方模块），适合Web入口、静态资源、反向代理场景，常与HAProxy配合（HAProxy做四层+健康检查，Nginx做七层Web服务）；4. Envoy：云原生代理，专为微服务设计，支持xDS动态配置、可观测性、多协议，是Istio服务网格的数据平面，适合Kubernetes和微服务架构，配置较复杂；5. Keepalived：不是负载均衡软件，而是高可用组件，通过VRRP协议实现IP漂移，与LVS/HAProxy配合实现负载均衡器的高可用（主备模式，主节点故障时VIP漂移到备节点）。架构选型建议：1. 中小规模Web/API：HAProxy（四层+七层）+ Keepalived（高可用），功能全、性能够、配置简单，一台HAProxy可支撑数万到数十万并发；2. 大流量入口（百万级并发）：LVS（DR模式，四层）+ Keepalived，性能最高，LVS后面再接HAProxy/Nginx做七层分发；3. Web服务+静态资源：Nginx（七层反向代理+负载均衡+静态资源）+ Keepalived，Nginx擅长Web场景；4. 微服务/K8s：Envoy/Istio（服务网格）或K8s Service（kube-proxy LVS/iptables模式），云原生方案；5. 数据库读写分离：HAProxy（TCP模式，健康检查MySQL端口，读写分离路由）或ProxySQL（MySQL专用代理）；6. 混合架构：LVS（四层入口）→ HAProxy（七层路由）→ Nginx（Web服务）→ 应用服务器，分层扩展，各层各司其职。高可用架构：负载均衡器本身不能是单点，需要高可用方案：1. 主备模式（Active-Standby）：两台负载均衡器，主节点工作，备节点待命，通过Keepalived VRRP协议检测主节点状态，主节点故障时VIP（虚拟IP）漂移到备节点，备节点接管流量，切换时间秒级，简单可靠，资源利用率50%（备节点平时不工作），适合大多数场景；2. 主主模式（Active-Active）：两台负载均衡器同时工作，各处理一部分流量（通过DNS轮询或不同VIP），一台故障时另一台接管全部流量，资源利用率100%，但配置较复杂，会话保持和流量分配需仔细设计；3. 多活模式：多数据中心多活，通过GSLB（全局负载均衡，DNS智能解析）将用户流量分发到最近的数据中心，单数据中心故障时自动切换，适合大规模高可用业务；4. 云负载均衡：阿里云SLB/ALB/NLB、腾讯云CLB、AWS ELB/ALB/NLB，云厂商托管的负载均衡，自带高可用（多可用区部署），无需自己维护Keepalived，弹性伸缩，按量付费，适合云上业务。

二、LVS配置与DR模式实战

LVS（Linux Virtual Server）是章文嵩博士开发的Linux内核级负载均衡，已并入Linux内核主线（ip_vs模块），工作在Netfilter的INPUT链，性能极高。LVS三种工作模式：1. NAT模式（Network Address Translation）：负载均衡器（Director）修改请求报文的目标IP为后端RS的IP，响应报文再经过Director修改源IP为VIP返回客户端，RS的默认网关指向Director，所有进出流量都经过Director，Director容易成为带宽瓶颈，RS可在任意私网，支持不同操作系统，配置简单，适合小规模场景；2. DR模式（Direct Routing，直接路由）：Director修改请求报文的目标MAC地址为RS的MAC，IP不变（仍是VIP），RS收到请求后直接响应客户端（不经过Director），响应流量不经过Director，Director只处理入站请求，带宽瓶颈大大缓解，性能最高，要求Director和RS在同一二层网络（同一VLAN/交换机），RS需配置VIP在lo接口并抑制ARP，适合大多数高并发场景，推荐使用；3. TUN模式（IP Tunnel，IP隧道）：Director将请求报文封装在新的IP隧道中发给RS，RS解封装后直接响应客户端，响应不经过Director，RS可在不同网络（跨网段、跨地域），但RS需支持IP隧道协议（ipip模块），配置复杂，适合跨数据中心或RS不在同一网段的场景。LVS调度算法：1. 静态调度：轮询（Round Robin，rr，依次分发）、加权轮询（Weighted Round Robin，wrr，按权重分发，性能好的RS权重高）、源地址哈希（Source Hash，sh，同一客户端IP分发到同一RS，实现简单会话保持）、目标地址哈希（Destination Hash，dh，同一目标IP分发到同一RS，适合缓存服务器）；2. 动态调度：最少连接（Least Connections，lc，分发到当前连接数最少的RS）、加权最少连接（Weighted Least Connections，wlc，按权重和连接数综合，默认算法，推荐）、最短预期延迟（SED）、最少队列（NQ）、基于局部性的最少连接（LBLC）、带复制的基于局部性最少连接（LBLCR）。生产环境推荐加权最少连接（wlc）或加权轮询（wrr），配合健康检查。LVS DR模式部署实战（Ubuntu 22.04）：环境规划：Director（负载均衡器）两台（主备，Keepalived），VIP 192.168.1.100，Director1 eth0 192.168.1.10，Director2 eth0 192.168.1.11；RS（后端Web服务器）两台，RS1 192.168.1.20，RS2 192.168.1.21，都运行Nginx（80端口）。步骤一：Director配置（两台都执行）：1. 加载ip_vs模块：modprobe ip_vs，echo “ip_vs” >> /etc/modules-load.d/ip_vs.conf；2. 安装ipvsadm（LVS管理工具）：apt install ipvsadm -y；3. 开启IP转发：echo “net.ipv4.ip_forward=1” >> /etc/sysctl.conf，sysctl -p；4. 配置VIP（由Keepalived管理，此处不手动配置，DR模式VIP配置在Keepalived）。步骤二：RS配置（每台RS都执行）：1. 配置VIP在lo回环接口：ifconfig lo:0 192.168.1.100 netmask 255.255.255.255 up，或ip addr add 192.168.1.100/32 dev lo；2. 抑制ARP响应（关键，防止RS响应VIP的ARP请求导致IP冲突）：echo “net.ipv4.conf.all.arp_ignore=1” >> /etc/sysctl.conf，echo “net.ipv4.conf.all.arp_announce=2” >> /etc/sysctl.conf，echo “net.ipv4.conf.lo.arp_ignore=1” >> /etc/sysctl.conf，echo “net.ipv4.conf.lo.arp_announce=2” >> /etc/sysctl.conf，sysctl -p；3. 启动Web服务（Nginx），确保80端口监听，测试curl http://192.168.1.20正常；4. 持久化lo:0配置（重启后生效）：在/etc/network/interfaces或netplan配置，或写rc.local。步骤三：Keepalived配置（Director主节点）：安装Keepalived：apt install keepalived -y。配置/etc/keepalived/keepalived.conf：global_defs { router_id LVS_MASTER script_user root enable_script_security } vrrp_script check_lvs { script “/etc/keepalived/check_lvs.sh” interval 2 weight -20 } 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/24 dev eth0 } track_script { check_lvs } virtual_server 192.168.1.100 80 { delay_loop 6 lb_algo wlc lb_kind DR persistence_timeout 50 protocol TCP real_server 192.168.1.20 80 { weight 100 TCP_CHECK { connect_port 80 connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } real_server 192.168.1.21 80 { weight 100 TCP_CHECK { connect_port 80 connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } } }。说明：state MASTER（主节点），priority 100（主节点优先级高于备节点），virtual_router_id 51（主备必须相同），virtual_ipaddress配置VIP，virtual_server配置LVS虚拟服务（VIP+端口），lb_algo wlc（加权最少连接算法），lb_kind DR（DR模式），real_server配置后端RS，weight权重，TCP_CHECK健康检查（检测80端口，3秒超时，重试3次）。健康检查脚本check_lvs.sh：#!/bin/bash ipvsadm -Ln | grep -q 192.168.1.100:80 || exit 1，检查LVS虚拟服务是否存在，不存在则优先级降低触发切换。步骤四：Keepalived备节点配置：与主节点类似，state BACKUP，priority 90（低于主节点），router_id不同，其他相同（virtual_router_id、VIP、virtual_server配置一致）。步骤五：启动验证：1. 主备节点都启动Keepalived：systemctl enable –now keepalived；2. 主节点查看VIP：ip addr show eth0，应看到192.168.1.100；3. 查看LVS规则：ipvsadm -Ln，应看到虚拟服务和RS列表；4. 客户端测试：curl http://192.168.1.100，多次访问应分发到不同RS（可在RS上配置不同标识页面验证）；5. 故障测试：停止主节点Keepalived（systemctl stop keepalived），VIP应漂移到备节点，服务不中断；停止一台RS的Nginx，LVS应自动摘除故障RS，流量只到健康RS；恢复后自动加回。LVS注意事项：1. DR模式要求Director和RS在同一二层网络，RS的lo配置VIP并抑制ARP，这是最容易出错的地方；2. RS的默认网关不需要指向Director（DR模式响应直接回客户端），但RS必须能访问外网（响应客户端）；3. LVS本身不做健康检查，需用Keepalived的TCP_CHECK/HTTP_GET或ldirectord；4. LVS不支持七层功能（URL路由、Cookie会话保持），需要七层功能时用HAProxy/Nginx；5. 性能调优：Director网卡多队列、RSS、RPS，网卡带宽足够（DR模式入站流量经过Director，大带宽场景需万兆网卡），ip_vs连接表调大（net.ipv4.ip_vs_conn_tab_size）；6. 持久连接（persistence_timeout）：同一客户端在指定时间内分发到同一RS，实现简单会话保持，适合有状态应用，但会降低负载均衡效果。

三、HAProxy配置与七层负载均衡

HAProxy是高性能的TCP/HTTP负载均衡器，支持四层和七层，功能丰富，是目前最流行的开源负载均衡软件。HAProxy核心概念：1. frontend：前端，监听客户端请求的入口，定义监听地址、端口、协议（TCP/HTTP）、ACL规则，将请求路由到backend；2. backend：后端，定义后端服务器池、负载均衡算法、健康检查、会话保持、服务器权重；3. listen：frontend+backend的组合，简单场景可用listen同时定义前端和后端；4. defaults：默认配置，被所有frontend/backend/listen继承，减少重复配置；5. ACL（Access Control List）：访问控制列表，根据请求特征（域名、URL、IP、HTTP头、Cookie）匹配，实现七层路由（如不同域名到不同backend、API路径到不同服务、移动端到专用backend）；6. 健康检查：定期检测后端服务器状态，故障自动摘除，恢复自动加回，支持TCP检查、HTTP检查（指定URL和期望状态码）；7. 会话保持：同一客户端的请求分发到同一后端服务器，支持源地址哈希、Cookie插入、Cookie前缀、Stick Table等方式；8. stats统计面板：HAProxy内置Web统计面板，实时查看前端/后端状态、连接数、请求率、服务器状态、健康检查结果，便于监控和排障。HAProxy安装（Ubuntu 22.04）：apt install haproxy -y，配置文件/etc/haproxy/haproxy.cfg，启动systemctl enable –now haproxy，验证haproxy -c -f /etc/haproxy/haproxy.cfg（检查配置语法）。HAProxy基础配置（HTTP七层负载均衡）：global { log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin stats timeout 30s user haproxy group haproxy daemon # SSL配置（如需要） ssl-default-bind-ciphers HIGH:!aNULL:!MD5 ssl-default-bind-options no-sslv3 } defaults { log global mode http option httplog option dontlognull option forwardfor # 传递真实客户端IP option http-server-close timeout connect 5000 timeout client 50000 timeout server 50000 errorfile 400 /etc/haproxy/errors/400.http # 其他错误页 } # 统计面板 listen stats { bind *:8404 stats enable stats uri /stats stats refresh 10s stats admin if LOCALHOST } # HTTP前端 frontend http_front { bind *:80 # 绑定80端口 # ACL示例 acl is_api path_beg /api acl is_static path_end .jpg .png .css .js # 路由 use_backend api_back if is_api use_backend static_back if is_static default_backend web_back } # Web后端 backend web_back { balance roundrobin # 负载均衡算法：轮询 option httpchk GET / # HTTP健康检查，访问/路径 http-check expect status 200 # 期望200状态码 cookie SERVERID insert indirect nocache # Cookie会话保持 server web1 192.168.1.20:80 check cookie web1 weight 100 server web2 192.168.1.21:80 check cookie web2 weight 100 } # API后端 backend api_back { balance leastconn # 最少连接 server api1 192.168.1.30:8080 check server api2 192.168.1.31:8080 check } # 静态资源后端 backend static_back { balance roundrobin server static1 192.168.1.40:80 check }。关键配置说明：1. global：全局配置，日志、用户、SSL默认参数、daemon模式；2. defaults：默认参数，mode http（七层模式），option forwardfor（添加X-Forwarded-For头传递真实客户端IP），超时设置（connect/client/server）；3. listen stats：统计面板，绑定8404端口，访问http://IP:8404/stats查看；4. frontend http_front：前端，绑定80端口，定义ACL和路由规则，default_backend默认后端；5. backend web_back：后端，balance roundrobin（轮询算法），option httpchk（HTTP健康检查），cookie SERVERID insert（Cookie会话保持，HAProxy插入Cookie标识后端服务器），server定义后端服务器（IP:端口，check启用健康检查，cookie标识，weight权重）。HAProxy四层TCP负载均衡（如MySQL、Redis、SSH）：listen mysql_front { bind *:3306 mode tcp balance leastconn option tcp-check tcp-check expect string “mysql” # 检查MySQL握手包 server mysql1 192.168.1.50:3306 check server mysql2 192.168.1.51:3306 check backup }，mode tcp（四层模式），option tcp-check（TCP健康检查），backup标记为备份服务器（主服务器都故障时才启用）。负载均衡算法（balance）：1. roundrobin：轮询，按权重依次分发，动态调整权重，默认算法，适合无状态服务；2. static-rr：静态轮询，权重不支持动态调整，性能略高；3. leastconn：最少连接，分发到当前连接数最少的服务器，适合长连接（数据库、SSH、WebSocket）；4. source：源地址哈希，同一客户端IP分发到同一服务器，实现简单会话保持，适合不支持Cookie的TCP服务；5. uri：URL哈希，同一URL分发到同一服务器，适合缓存服务器；6. url_param：URL参数哈希，根据指定参数（如user_id）哈希，适合按用户会话保持；7. hdr(name)：HTTP头哈希，根据指定头（如Host）哈希；8. random：随机分发，配合一致性哈希（一致性哈希算法在服务器增减时影响最小，适合缓存）。健康检查配置：1. TCP检查（option tcp-check）：默认检查端口是否可连接，最简单；2. HTTP检查（option httpchk GET /path）：发送HTTP请求，检查响应状态码（http-check expect status 200）或响应内容（http-check expect string “OK”），更准确，能检测应用是否正常（端口通但应用挂了也能检测到）；3. 检查参数：inter（检查间隔，默认2000ms）、fall（连续失败多少次标记为故障，默认3）、rise（连续成功多少次标记为恢复，默认2）、timeout（检查超时）；4. 健康检查是高可用的关键，生产环境必须配置，建议用HTTP检查而非TCP检查。会话保持配置：1. Cookie插入（cookie SERVERID insert indirect nocache）：HAProxy在响应中插入Cookie标识后端服务器，后续请求带此Cookie则分发到同一服务器，最常用，适合Web应用，indirect（不将Cookie转发给后端，后端看不到），nocache（不缓存带Cookie的响应）；2. Cookie前缀（cookie SERVERID prefix）：在后端设置的Cookie前添加服务器标识，适合后端自己设置Cookie的场景；3. 源地址哈希（balance source）：同一IP分发到同一服务器，简单但IP变化（移动网络、NAT）会失效，且负载不均；4. Stick Table：HAProxy的粘性表，可基于IP、Cookie、SSL Session ID等保持会话，功能强大，支持过期、学习、存储统计数据；5. 注意：会话保持会降低负载均衡效果，无状态服务尽量不用会话保持，有状态服务（登录会话）建议将会话存储在Redis等共享存储，实现无状态化，不需要会话保持。HTTPS/SSL配置：HAProxy支持SSL终止（HTTPS请求在HAProxy解密，转发HTTP给后端）和SSL透传（HTTPS直接转发给后端，HAProxy不解析内容，四层模式）。SSL终止配置：frontend https_front { bind *:443 ssl crt /etc/haproxy/certs/example.com.pem # 证书文件（包含证书+私钥） mode http option forwardfor http-request set-header X-Forwarded-Proto https # 告知后端是HTTPS default_backend web_back }，证书文件需将证书和私钥合并（cat example.com.crt example.com.key > example.com.pem），权限600。HTTP跳转HTTPS：frontend http_front { bind *:80 http-request redirect scheme https unless { ssl_fc } }。HAProxy性能优化：1. 调大最大连接数：global中maxconn 100000，ulimit -n调大（文件描述符）；2. 多进程/多线程：nbproc（多进程，已废弃）、nbthread（多线程，推荐，HAProxy 1.8+支持，设置为CPU核心数），cpu-map绑定CPU；3. 网卡优化：多队列、RSS、RPS、XPS，万兆网卡；4. 内核参数：net.core.somaxconn、net.ipv4.tcp_max_syn_backlog、net.ipv4.tcp_tw_reuse、fs.file-max；5. 关闭不必要的日志（option dontlognull），日志异步写入；6. 压缩（compression algo gzip）减少传输量；7. 缓存（http-request cache-use）缓存静态响应；8. 连接复用（option http-keep-alive）减少后端连接创建。

四、Keepalived高可用与故障切换

Keepalived是基于VRRP（Virtual Router Redundancy Protocol，虚拟路由冗余协议）的高可用组件，实现IP漂移和故障切换，与LVS/HAProxy配合实现负载均衡器的高可用。VRRP原理：1. 多台路由器（负载均衡器）组成一个虚拟路由器，共享一个虚拟IP（VIP）和虚拟MAC；2. 主节点（Master）持有VIP，处理流量，定期发送VRRP通告（Advertisement）给备节点；3. 备节点（Backup）监听主节点的通告，超过一定时间（3个通告间隔+偏移）没收到通告，认为主节点故障，升级为Master，接管VIP（发送ARP广播宣告VIP的MAC已变更，交换机更新MAC地址表）；4. 原主节点恢复后，根据优先级决定是否抢占回Master（默认抢占模式，优先级高的恢复后会抢回Master，可设置nopreempt非抢占模式避免频繁切换）；5. VRRP通过组播（224.0.0.18）通信，主备节点必须在同一二层网络，virtual_router_id（0-255）标识虚拟路由器，主备必须相同，不同虚拟路由器用不同ID。Keepalived安装（Ubuntu 22.04）：apt install keepalived -y，配置文件/etc/keepalived/keepalived.conf，启动systemctl enable –now keepalived。HAProxy+Keepalived高可用配置：环境规划：HAProxy1（主）192.168.1.10，HAProxy2（备）192.168.1.11，VIP 192.168.1.100，后端RS 192.168.1.20/21。主节点keepalived.conf：global_defs { router_id HAProxy_MASTER script_user root enable_script_security } # 健康检查脚本：检测HAProxy进程是否存活 vrrp_script check_haproxy { script “/usr/bin/killall -0 haproxy” interval 2 weight -20 fall 2 rise 2 } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 # 通告间隔1秒 authentication { auth_type PASS auth_pass 123456 # 密码，主备必须相同 } virtual_ipaddress { 192.168.1.100/24 dev eth0 } track_script { check_haproxy } # 跟踪健康检查脚本 notify_master “/etc/keepalived/notify.sh master” notify_backup “/etc/keepalived/notify.sh backup” notify_fault “/etc/keepalived/notify.sh fault” }。备节点keepalived.conf：与主节点类似，state BACKUP，priority 90（低于主节点），router_id HAProxy_BACKUP，其他相同（virtual_router_id、VIP、认证密码、track_script）。配置说明：1. vrrp_script check_haproxy：健康检查脚本，killall -0 haproxy检测HAProxy进程是否存在（-0只发信号检测进程是否存在，不真正杀死），interval 2每2秒检查一次，weight -20检查失败时优先级降低20（主节点优先级100-20=80，低于备节点90，触发切换），fall 2连续失败2次标记故障，rise 2连续成功2次标记恢复；2. state MASTER/BACKUP：初始状态，实际Master由优先级决定（优先级高的成为Master）；3. priority：优先级，主节点高于备节点，范围0-254；4. virtual_router_id：虚拟路由器ID，主备必须相同，同一网络不同VRRP实例用不同ID；5. advert_int：VRRP通告间隔，默认1秒，备节点3个间隔没收到通告则切换（约3秒）；6. authentication：认证，auth_type PASS简单密码认证（最多8位），主备必须相同，防止非法节点加入；7. virtual_ipaddress：VIP，可配置多个，支持/dev指定网卡、/label指定别名；8. track_script：跟踪健康检查脚本，脚本失败时降低优先级触发切换；9. notify_master/backup/fault：状态切换时执行的通知脚本，可发送邮件/钉钉/企业微信告警，记录日志。健康检查脚本也可以更复杂，如检测HAProxy的stats端口或HTTP端口：vrrp_script check_haproxy { script “curl -s http://127.0.0.1:8404/stats | grep -q ‘200 OK'” interval 2 weight -20 }，或检测HAProxy监听的80端口：script “nc -z 127.0.0.1 80″。通知脚本notify.sh：#!/bin/bash STATE=$1 echo “$(date) Keepalived state changed to $STATE” >> /var/log/keepalived-notify.log # 发送钉钉/企业微信告警（示例） # curl -X POST ‘https://oapi.dingtalk.com/robot/send?access_token=xxx’ -H ‘Content-Type: application/json’ -d “{\”msgtype\”:\”text\”,\”text\”:{\”content\”:\”Keepalived切换到$STATE状态，VIP已漂移\”}}”，chmod +x /etc/keepalived/notify.sh。验证与故障测试：1. 主备都启动Keepalived，主节点ip addr show eth0应看到VIP 192.168.1.100；2. 客户端curl http://192.168.1.100应正常访问（HAProxy转发到后端）；3. 主节点停止HAProxy：systemctl stop haproxy，健康检查脚本失败，主节点优先级降低，VIP漂移到备节点，服务不中断（可能有1-3秒切换时间，正在处理的连接可能断开）；4. 主节点恢复HAProxy：systemctl start haproxy，健康检查恢复，主节点优先级恢复，抢占回Master（默认抢占模式），VIP漂移回主节点；5. 主节点宕机（断电/断网）：备节点收不到VRRP通告，升级为Master，接管VIP；6. 查看切换日志：journalctl -u keepalived -f，/var/log/keepalived-notify.log。非抢占模式（nopreempt）：默认抢占模式下，主节点恢复后会抢回Master，导致两次切换（VIP来回漂移），影响服务。可设置nopreempt非抢占模式，主节点恢复后不抢回，备节点继续作为Master，直到备节点故障才切换，减少不必要的切换。配置：vrrp_instance VI_1 { state BACKUP # 非抢占模式下两个节点都设为BACKUP priority 100 nopreempt # 非抢占 … }，两个节点state都设为BACKUP，靠优先级选举Master，Master故障后Backup接管，原Master恢复后不抢占。注意：nopreempt只能在state BACKUP时设置，且优先级高的节点初始启动时会成为Master。双主模式（Active-Active）：两台HAProxy同时工作，各处理一部分流量，提高资源利用率。配置两个VRRP实例：VI_1（VIP1 192.168.1.100，HAProxy1主，HAProxy2备），VI_2（VIP2 192.168.1.101，HAProxy2主，HAProxy1备）。DNS轮询将域名解析到两个VIP，用户流量分散到两台HAProxy。一台故障时，另一台接管两个VIP，处理全部流量。双主模式资源利用率100%，但需注意会话保持（同一用户的请求可能到不同VIP/不同HAProxy，需后端共享会话或Cookie会话保持）。Keepalived注意事项：1. 主备节点必须在同一二层网络（同一VLAN/交换机），VRRP组播能互通；2. virtual_router_id和认证密码主备必须相同；3. 优先级主节点高于备节点，健康检查失败时降低的权重需足够大（主优先级-权重 < 备优先级）才能触发切换；4. 抢占模式可能导致频繁切换，建议用nopreempt或调整优先级差；5. 切换时间约1-3秒（VRRP通告间隔3倍），正在处理的长连接可能断开，应用需有重试机制；6. VIP漂移依赖ARP广播，部分交换机/云环境可能限制ARP或不支持免费ARP，云环境建议用云厂商的负载均衡（自带高可用）而非Keepalived；7. 云服务器（阿里云/腾讯云/AWS）的VIP/弹性IP高可用需用云厂商的HAVIP/弹性IP+Keepalived方案，或直接用托管负载均衡；8. Keepalived本身也需要监控，确保Keepalived进程存活（可用systemd自动重启）；9. 脑裂问题：主备网络中断时，备节点收不到通告会升级为Master，出现两个Master（脑裂），都持有VIP，导致IP冲突和流量混乱。预防：用双链路（心跳线+业务线）、仲裁机制（第三节点/磁盘仲裁）、监控告警及时发现，VRRP的认证只能防止非法节点，不能防止脑裂；10. 生产环境建议主备节点部署在不同物理机架/不同可用区，避免同时故障。

五、健康检查、会话保持与监控告警

健康检查是负载均衡高可用的核心，确保流量只分发到健康的后端服务器，故障服务器自动摘除，恢复后自动加回。HAProxy健康检查详解：1. TCP检查（option tcp-check）：默认检查，尝试连接后端服务器的端口，连接成功则认为健康，简单快速，但只能检测端口是否开放，无法检测应用是否正常（端口通但应用挂了、返回500错误检测不到）；2. HTTP检查（option httpchk）：发送HTTP请求到后端，检查响应状态码或内容，能检测应用层健康，更准确。配置：option httpchk GET /health HTTP/1.1\r\nHost:\ example.com，发送GET /health请求，Host头example.com；http-check expect status 200期望200状态码，或http-check expect string “OK”期望响应包含”OK”，或http-check expect ! rstatus ^5（正则匹配，非5xx）；3. 外部检查（external-check）：执行自定义脚本检查，适合复杂检查逻辑（如检查数据库连接、依赖服务状态），需启用option external-check，配置external-check command /path/to/script.sh；4. 检查参数：inter 2000（检查间隔2秒）、fall 3（连续失败3次标记为DOWN，摘除）、rise 2（连续成功2次标记为UP，加回）、timeout 3000（检查超时3秒）、port 8080（检查指定端口，不同于服务端口）；5. 健康检查状态：UP（健康，正常分发流量）、DOWN（故障，摘除，不分发流量）、MAINT（维护模式，手动设置，不分发流量，用于发布/维护）、DRAIN（排水模式，不接受新连接，已有连接继续处理，用于优雅下线）。健康检查最佳实践：1. 用HTTP检查而非TCP检查，检测应用真实健康状态；2. 专门的健康检查端点（/health或/status），返回应用状态（数据库连接、Redis连接、依赖服务），不要用首页（首页可能有缓存、重定向、复杂逻辑，检查不准确且增加负载）；3. 健康检查端点要轻量，快速返回（<100ms），不要做复杂检查（如检查数据库时只做简单SELECT 1，不要做复杂查询）；4. 合理设置检查间隔和失败次数，inter 2-5秒，fall 2-3次，既能快速发现故障（4-15秒），又不会因网络抖动误摘除；5. 健康检查本身要监控，检查失败率高时告警；6. 维护时用MAINT模式手动摘除服务器，发布完成后加回，避免发布过程中分发流量到正在重启的服务器；7. 优雅下线用DRAIN模式，等待已有连接处理完再下线，避免中断用户请求。会话保持详解：会话保持（Session Persistence/Sticky Session）确保同一客户端的多个请求分发到同一后端服务器，适用于有状态应用（会话存在本地内存、本地缓存）。但现代架构推荐应用无状态化（会话存Redis、共享存储），不需要会话保持，负载更均衡。会话保持方式：1. Cookie插入（HAProxy cookie SERVERID insert）：HAProxy在响应中插入Cookie（如SERVERID=web1），客户端后续请求带此Cookie，HAProxy根据Cookie分发到对应服务器。最常用，适合Web应用，客户端支持Cookie即可，不依赖IP。配置：backend web_back { cookie SERVERID insert indirect nocache maxidle 3600 maxlife 86400 server web1 192.168.1.20:80 check cookie web1 server web2 192.168.1.21:80 check cookie web2 }，insert插入Cookie，indirect不将Cookie转发给后端（后端看不到SERVERID），nocache不缓存带Cookie的响应（避免缓存导致会话错乱），maxidle/maxlife Cookie过期时间；2. Cookie前缀（cookie SERVERID prefix）：后端自己设置Cookie（如JSESSIONID=xxx），HAProxy在Cookie值前添加服务器标识（如JSESSIONID=web1~xxx），后续请求根据前缀路由。适合Java应用（Tomcat/JSESSIONID），后端无需修改代码；3. 源地址哈希（balance source）：根据客户端IP哈希，同一IP分发到同一服务器。简单，无需Cookie，适合TCP服务或不支持Cookie的客户端，但NAT/移动网络IP变化会失效，且同一IP（公司出口、CDN）的所有用户到同一服务器导致负载不均；4. Stick Table（stick-table）：HAProxy的粘性表，可基于IP、Cookie、SSL Session ID、URL参数等学习和存储会话映射，支持过期、数据存储（连接数、请求率）、ACL匹配，功能强大。配置：backend web_back { stick-table type ip size 100k expire 30m store conn_cur stick on src server web1 ... server web2 ... }，基于源IP粘性，30分钟过期；5. SSL Session ID（stick on ssl_fc_session_id）：基于SSL会话ID保持，HTTPS透传模式下可用，但SSL会话ID会轮换，效果不稳定；6. 一致性哈希（balance hash consistent）：基于指定键（URL、Header、参数）的一致性哈希，服务器增减时影响最小（只有部分会话重新映射），适合缓存服务器。会话保持注意事项：1. 会话保持会降低负载均衡效果（流量可能集中到某些服务器），无状态服务尽量不用；2. 有状态服务优先将会话存储到Redis/数据库，实现应用无状态，比负载均衡会话保持更可靠（服务器故障时会话不丢失）；3. Cookie会话保持时，Cookie过期时间要合理，太长导致负载长期不均，太短导致会话频繁切换；4. 后端服务器故障时，该服务器的会话会被分发到其他服务器（会话丢失，用户需重新登录），无状态化可避免；5. 多活/双主模式下，会话保持需确保同一用户到同一HAProxy节点（DNS解析稳定或GSLB），否则不同HAProxy节点的会话表不共享（HAProxy Enterprise支持Stick Table同步，开源版需手动配置peers同步）。监控告警：负载均衡是流量入口，必须严密监控，及时发现故障。监控指标：1. 前端：请求率（requests/s）、连接数（并发连接）、会话数、字节数、错误率（4xx/5xx）、拒绝连接数（maxconn限制）、拦截率（WAF/限流）；2. 后端：每台服务器的请求率、连接数、响应时间（平均/P95/P99）、健康检查状态（UP/DOWN）、故障次数、权重、状态（UP/DOWN/MAINT/DRAIN）、队列长度（backend满了排队）；3. HAProxy进程：CPU使用率、内存使用率、文件描述符使用数、连接表使用率、进程存活状态；4. Keepalived：VRRP状态（Master/Backup）、VIP持有状态、健康检查脚本状态、切换次数、通知日志；5. 系统层面：CPU、内存、磁盘IO、网络IO（入站/出站带宽、PPS）、TCP连接数（ESTABLISHED/TIME_WAIT）、文件描述符、内核日志。监控工具：1. HAProxy Stats面板：内置Web面板（http://IP:8404/stats），实时查看所有指标，支持CSV导出，简单易用，生产环境建议启用并限制访问IP；2. Prometheus + HAProxy Exporter + Grafana：HAProxy Exporter（prometheus/haproxy_exporter或HAProxy 2.0+内置prometheus-exporter）将Stats指标导出为Prometheus格式，Grafana可视化，设置告警规则，是生产环境标准方案；3. Keepalived监控：通过SNMP或自定义脚本（解析ip addr、journalctl）导出VRRP状态到Prometheus，Grafana展示；4. 日志监控：HAProxy日志（/var/log/haproxy.log）收集到ELK/Loki，分析请求模式、错误、慢请求、攻击；5. 告警工具：Alertmanager（Prometheus）、Grafana Alerting、云厂商监控告警，通过邮件/钉钉/企业微信/短信/电话通知。关键告警规则：1. HAProxy进程宕机（进程不存在或端口不通）→ P0紧急；2. 后端服务器DOWN（健康检查失败）→ P1严重，单台DOWN告警，多台DOWN升级P0；3. 5xx错误率>1%（持续2分钟）→ P1严重；4. 响应时间P99>2s（持续5分钟）→ P2警告；5. 并发连接数>maxconn的80%→ P2警告，接近上限需扩容；6. 后端队列长度>0（持续1分钟）→ P2警告，后端处理不过来；7. Keepalived状态切换（Master→Backup或反之）→ P1严重，可能发生故障，需排查；8. VIP不在预期节点→ P1严重；9. 健康检查脚本失败→ P2警告；10. CPU>80%、内存>80%、磁盘>80%、网络带宽>80%→ P2警告；11. 证书过期<30天→ P2警告；12. 切换次数频繁（1小时内>3次）→ P1严重，可能网络抖动或配置问题。告警最佳实践：1. 分级告警（P0紧急电话/短信、P1严重钉钉+短信、P2警告钉钉、P3提示邮件），避免告警疲劳；2. 告警聚合（同一故障多个指标告警合并为一条）、抑制（父故障抑制子故障，如HAProxy宕机抑制后端DOWN告警）；3. 告警要有明确的处理指引（Runbook），收到告警知道怎么排查；4. 定期演练告警，确保告警通道正常、值班人员能收到；5. 监控自身也要监控（监控系统宕机告警），避免监控盲区；6. 保留历史数据（至少30天），用于趋势分析、容量规划、故障复盘。

六、性能优化、常见问题与最佳实践

负载均衡性能优化：负载均衡器是流量入口，性能瓶颈会影响整个系统，需要充分优化。HAProxy性能优化：1. 多线程：global中nbthread （HAProxy 1.8+，推荐，多线程充分利用多核，比多进程nbproc好，共享状态），cpu-map 1/all 0-3绑定CPU核心，避免上下文切换；2. 最大连接数：global maxconn 100000（根据服务器内存和带宽调整，每个连接约占几KB内存，10万连接约几百MB），ulimit -n 655350（文件描述符上限，需大于maxconn），systemd配置LimitNOFILE=infinity；3. 内核参数优化：/etc/sysctl.conf：net.core.somaxconn=65535（监听队列长度）、net.ipv4.tcp_max_syn_backlog=65535（SYN队列）、net.ipv4.tcp_tw_reuse=1（TIME_WAIT复用）、net.ipv4.ip_local_port_range=1024 65535（本地端口范围）、net.core.netdev_max_backlog=50000（网卡队列）、fs.file-max=1000000（系统文件描述符）、net.ipv4.tcp_syncookies=1（SYN Flood防护）、net.ipv4.tcp_fin_timeout=15（FIN超时，加快连接回收）；4. 网卡优化：多队列网卡（ethtool -L eth0 combined ）、RSS（接收端缩放）、RPS（接收包 Steering）、XPS（发送包 Steering）、中断绑定（将网卡中断绑定到不同CPU）、开启GRO/LRO（大接收卸载）、TSO（TCP分段卸载）、GSO（通用分段卸载），万兆网卡必备；5. 连接复用：option http-keep-alive（HTTP keep-alive，复用后端连接，减少连接创建开销）、option http-reuse safe（安全复用后端连接）、timeout http-keep-alive 10s（keep-alive超时）；6. 压缩：compression algo gzip、compression type text/html text/plain text/css application/javascript application/json，压缩文本资源减少传输量，但CPU开销增加，CPU够用时开启；7. 缓存：HAProxy 2.0+支持HTTP缓存（http-request cache-use mycache、http-response cache-store mycache），缓存静态响应，减少后端请求；8. 关闭不必要功能：option dontlognull（不记录空连接日志）、不记录健康检查日志（option httpchk disable-on-404）、限制日志级别；9. SSL优化：SSL终止CPU开销大，用AES-NI硬件加速（CPU支持）、ssl-default-bind-ciphers选择高效套件、开启SSL会话缓存（ssl-cache-size 1000000）、TLS 1.3（性能更好）、SSL证书用ECDSA（比RSA快）；10. 单机性能参考：HAProxy在普通服务器（8核16G、万兆网卡）上可支撑5-10万并发连接、10-20万QPS（HTTP短连接）、数万SSL TPS，具体取决于请求大小和复杂度。LVS性能优化：1. LVS工作在内核，性能极高，主要瓶颈是网卡带宽（DR模式入站流量）和PPS（包转发率），用万兆/25G网卡、多队列、DPDK（用户态驱动，更高性能）；2. 连接表大小：net.ipv4.ip_vs_conn_tab_size=262144（默认1024，大并发需调大，2的幂），cat /proc/net/ip_vs_conn查看连接数；3. 网卡多队列、中断绑定、RPS/XPS优化；4. DR模式响应不经过Director，Director带宽只需考虑入站，大流量场景（如下载、视频）DR模式优势明显；5. LVS不做应用层处理，CPU开销极低，主要是网卡和内存。常见问题排查：1. 服务无法访问：检查VIP是否在预期节点（ip addr）、HAProxy/LVS进程是否存活（systemctl status）、端口是否监听（ss -tlnp）、防火墙是否放行（iptables -L、ufw status）、后端服务器是否健康（Stats面板、curl后端IP）、路由是否通（ping/traceroute）；2. 502/503错误：503后端不可用（所有服务器DOWN或达到maxconn），检查健康检查、后端服务、maxconn设置；502后端响应无效，检查后端应用是否正常、响应是否符合HTTP协议、超时设置；3. 会话丢失/频繁切换：检查会话保持配置（Cookie是否正确插入、过期时间）、后端服务器是否频繁DOWN（健康检查太敏感）、双主模式下DNS是否轮询导致到不同节点、应用是否无状态（会话存Redis）；4. 健康检查频繁失败/抖动：检查检查间隔和超时（网络抖动时inter太短、timeout太小导致误判）、健康检查端点是否稳定（不要用复杂页面）、后端服务器负载是否过高（响应慢导致检查超时）、网络是否丢包（mtr检测）；5. Keepalived不切换：检查主备VRRP通信（组播224.0.0.18是否通、防火墙是否放行VRRP协议112）、virtual_router_id和认证密码是否一致、优先级是否正确、健康检查脚本是否执行成功（脚本权限、路径）、nopreempt是否设置；6. VIP漂移后不通：检查ARP广播是否生效（arping -c 3 -I eth0 VIP，交换机是否更新MAC表）、云环境是否支持VIP/ARP（阿里云HAVIP、腾讯云弹性IP）、防火墙是否放行、后端服务器是否配置正确；7. 性能差/响应慢：检查HAProxy CPU/内存/连接数是否到上限、后端服务器负载（CPU/内存/IO）、网络带宽是否打满、是否有慢请求（日志分析）、数据库/缓存是否瓶颈、maxconn是否太小导致排队；8. 日志太多/占满磁盘：配置logrotate切割日志、降低日志级别（option dontlognull、不记录健康检查）、限制访问日志（only logging特定状态码）、集中日志收集后本地不长期存储；9. SSL握手慢/失败：检查证书是否正确（证书链完整、域名匹配、未过期）、SSL协议和套件配置（客户端是否支持）、SSL会话缓存是否开启、CPU是否够（SSL握手CPU密集）、HAProxy版本是否支持TLS 1.3；10. 长连接断开：检查timeout client/server设置（长连接如WebSocket、SSH需调大，如3600s）、中间设备（防火墙、NAT）的连接超时（可能比HAProxy短，导致连接被中间设备断开）、keepalive设置。最佳实践总结：1. 架构选型：中小规模用HAProxy+Keepalived，大流量用LVS+HAProxy，云上用托管负载均衡（SLB/ALB/NLB），微服务用Envoy/Istio；2. 高可用：负载均衡器必须主备/多活，无单点，Keepalived VIP漂移，切换时间秒级，主备部署在不同机架/可用区；3. 健康检查：用HTTP检查（专用/health端点），合理间隔和失败次数，维护用MAINT模式，优雅下线用DRAIN；4. 无状态化：应用尽量无状态，会话存Redis，不依赖负载均衡会话保持，负载更均衡，故障不丢会话；5. 性能优化：多线程、maxconn、内核参数、网卡多队列、连接复用、压缩、缓存、SSL硬件加速，压测验证性能；6. 监控告警：Stats面板+Prometheus+Grafana，监控前端/后端/进程/Keepalived/系统指标，分级告警，关键故障P0/P1及时通知；7. 安全：HAProxy作为入口，配置WAF（ModSecurity）、限流（stick-table rate limiting）、DDoS防护（SYN cookie、连接限制）、访问控制（ACL黑白名单）、HTTPS强制、安全响应头（HSTS、CSP、X-Frame-Options）、隐藏后端信息（删除Server头）、最小权限运行；8. 配置管理：HAProxy配置文件版本控制（Git），变更前haproxy -c检查语法，reload平滑重载（systemctl reload，不中断连接），配置注释清晰，分环境（开发/测试/生产）；9. 容量规划：根据业务增长预估流量，预留30-50%冗余，定期压测，瓶颈时扩容（纵向升级配置或横向加服务器），连接数/带宽/CPU都要考虑；10. 故障演练：定期模拟故障（后端服务器DOWN、主节点宕机、网络中断、流量突增），验证高可用切换、告警、扩容是否正常，记录问题并改进，Runbook完善；11. 文档：记录架构图、IP规划、VIP、配置、部署流程、故障处理（Runbook）、联系人，团队知识共享；12. 灰度发布：后端服务器发布时，先MAINT摘除一台，发布验证后加回，再发布下一台，滚动发布，不中断服务，配合蓝绿/金丝雀发布降低风险。负载均衡是高可用架构的基石，LVS和HAProxy是开源负载均衡的两大利器，LVS以高性能四层转发见长，HAProxy以丰富的四层/七层功能和易用性取胜，两者配合Keepalived可构建企业级高可用负载均衡集群。掌握负载均衡原理、配置、优化和排障，是运维工程师和架构师的核心技能，无论是自建VPS/独立服务器集群，还是云服务器架构，负载均衡都是构建稳定、可扩展、高可用系统的关键组件。

更多负载均衡教程和靠谱VPS、云服务器、独立服务器推荐，欢迎访问主机测评网zhujishang.com，我们持续更新服务器教程、主机商测评和云服务器选购指南，帮你选到最适合的负载均衡集群部署主机方案。