一、负载均衡概述

应用场景

负载均衡（Load Balancing）是一种将网络流量或计算任务分配到多个服务器上的技术，旨在优化资源使用、最大化吞吐量、最小化响应时间，并避免任何单一资源的过载。提高并发量

主要作用：

1. 提高系统可用性和可靠性
2. 提升系统处理能力
3. 实现系统横向扩展
4. 提供故障转移能力

二、负载均衡类型

1. 基于网络层次划分

• 四层负载均衡（传输层，如LVS）：基于IP+端口进行转发
• 七层负载均衡（应用层，如Nginx）：可以解析应用层协议内容（如HTTP头、URL等）

2. 基于实现方式划分

• 硬件负载均衡：F5、A10、Radware等专用设备
• 软件负载均衡：Nginx、HAProxy、LVS等
• 云服务负载均衡：AWS ALB/ELB、阿里云SLB、腾讯云CLB等

三、常见负载均衡软件配置

1. Nginx负载均衡配置

2个模块:upstream与proxy

upstrream指令

proxy_pass指令

• proxy_pass指令把请求往后抛（可以是单个ip，也可以是一个分组）
• * proxy_pass 192.168.1.100:8080
• proxy_pass http://分组名字(upsream)

proxy_set_header指令.

• 现象：web节点上有多个虚拟主机,负载均衡在转发数据的时候会有访问异常.访问多个虚拟主机的默认的或第1个
• 原因：负载均衡向后端节点发出请求的时候,请求头Host变成了upstream名字,相当于使用ip访问.
• 解决：通过proxy_set_header指令修改负载到web节点的请求头. proxy_set_header Host \$http_host
• proxy_set_header Host \$http_host,和proxy_set_header Host \$host

变量	是否包含端口	默认值（无Host 头时）	来源
$host	不包含	server_name 的值	请求行或Host 头
$http_host	包含	空值	直接取自Host 头

http {
    upstream backend {
        # 定义服务器组
        server 192.168.1.100:8080 weight=5 max_fails=3 fail_timeout=10s;  # 权重5，健康检查3，再次检查时间
        server 192.168.1.101:8080;
        server 192.168.1.102:8080 backup;    # 备胎，所有服务器都挂了后是启动这台
    }

    server {
        listen 80;

        location / {
            proxy_pass http://backend;
            # 其他代理设置
            proxy_set_header Host $host;  ##
            proxy_set_header X-Real-IP $remote_addr;
        }
    }
}

1.1经过负载均衡后web节点如何记录客户端真实ip地址

• 现象：web服务器上记录的是代理服务器的ip，看不到客户端真实ip，如果需要统计无法确认
• 解决: 增加XFF请求头,X-Forwarded-For,记录用户真实的ip地址.
• 在负载均衡上设置
• proxy_set_header X Forwarded For \$proxy_add_x_forwarded_for ;这个记录更详细
• proxy_set_header X Real Ip \$remote_addr ;这个记录最后一个，如果有多层代理

2.HAProxy配置示例

frontend http-in
    bind *:80
    default_backend servers

backend servers
    balance roundrobin
    server server1 192.168.1.100:80 check
    server server2 192.168.1.101:80 check
    server server3 192.168.1.102:80 check backup

listen stats
    bind *:1936
    stats enable
    stats uri /
    stats hide-version
    stats auth admin:password

3. LVS配置示例

# 添加虚拟服务
ipvsadm -A -t 192.168.1.200:80 -s rr

# 添加真实服务器
ipvsadm -a -t 192.168.1.200:80 -r 192.168.1.100:80 -g
ipvsadm -a -t 192.168.1.200:80 -r 192.168.1.101:80 -g
ipvsadm -a -t 192.168.1.200:80 -r 192.168.1.102:80 -g

四、负载均衡访问流程

1. 四层负载均衡流程（以LVS为例）

1. 客户端发送请求到负载均衡器的VIP
2. 负载均衡器根据调度算法选择一台后端服务器
3. 负载均衡器将数据包的目标MAC地址修改为选定服务器的MAC地址
4. 后端服务器处理请求并直接响应客户端（DR模式）

2. 七层负载均衡流程（以Nginx为例）

1. 客户端发送HTTP请求到负载均衡器
2. 负载均衡器解析HTTP请求（URL、Header等）
3. 根据配置规则选择后端服务器
4. 负载均衡器作为代理与后端服务器建立新连接
5. 后端服务器响应负载均衡器
6. 负载均衡器将响应返回给客户端

五、负载均衡常见故障及排查

1. 常见故障类型

配置错误

• 后端服务器地址或端口配置错误
• 调度算法配置不当
• 健康检查配置错误

网络问题

• 负载均衡器与后端服务器网络不通
• 防火墙阻止了健康检查或业务流量
• 网络带宽不足

性能问题

• 负载均衡器性能瓶颈（连接数、吞吐量）
• 后端服务器资源不足（CPU、内存、IO）
• 会话保持导致负载不均

健康检查问题

• 检查间隔设置不合理
• 检查URL或端口配置错误
• 检查成功条件设置不当

2. 故障排查流程

1. 检查负载均衡器状态

• 查看当前连接数、吞吐量等指标
• 检查负载均衡器日志
• 确认配置是否正确

1. 检查后端服务器

• 确认服务是否正常运行
• 检查服务器资源使用情况
• 验证直接访问后端服务器是否正常

1. 检查网络连接

• 测试负载均衡器到后端服务器的连通性
• 检查防火墙规则
• 检查路由设置

1. 检查健康检查

• 确认健康检查是否通过
• 检查健康检查日志
• 调整健康检查参数

3. 常见故障案例

案例1：部分后端服务器接收不到流量

现象：新扩容的服务器没有接收到任何请求
排查：

1. 检查负载均衡配置，确认新服务器已添加
2. 检查健康检查，发现新服务器健康检查失败
3. 发现健康检查URL在新服务器上不存在
   解决：修正健康检查URL或在新服务器上添加相应检查端点

案例2：负载均衡器CPU使用率高

现象：负载均衡器CPU使用率持续90%以上
排查：

1. 查看连接数，发现异常高
2. 检查发现大量短连接，且客户端未启用keepalive
3. 负载均衡器频繁建立和关闭连接消耗大量CPU
   解决：
4. 客户端启用HTTP keepalive
5. 调整负载均衡器TCP参数优化连接处理
6. 考虑升级硬件或增加负载均衡器实例

案例3：会话保持失效

现象：用户登录状态频繁丢失
排查：

1. 检查负载均衡会话保持配置，确认已启用
2. 发现使用了IP哈希但用户通过NAT访问，多个用户共享出口IP
3. 导致所有请求被路由到同一台服务器，该服务器过载后丢弃部分会话
   解决：
4. 改用基于cookie的会话保持
5. 增加后端服务器处理能力
6. 优化会话存储，使用分布式缓存

案例4：健康检查导致服务抖动

现象：服务每隔几分钟出现短暂不可用
排查：

1. 发现后端服务器日志中有定期503错误
2. 检查负载均衡器健康检查配置，间隔为5分钟
3. 服务器在健康检查时进行GC暂停，导致检查失败
   解决：
4. 调整健康检查间隔和超时时间
5. 优化后端服务器GC配置
6. 添加健康检查端点专用处理逻辑，避免受GC影响

六、云服务负载均衡注意事项

1. 了解服务限制：如AWS ALB有固定连接数限制
2. 成本优化：合理选择计费方式，删除闲置资源
3. 跨可用区部署：提高可用性
4. 与自动扩展集成：根据负载自动调整后端容量
5. 安全组配置：确保安全组规则允许必要流量
6. 证书管理：及时更新SSL/TLS证书
7. 访问控制：使用WAF等增强安全防护