上一篇
http协议负载均衡
HTTP协议负载均衡通过反向代理分发请求，提升性能与可用性，常用轮
HTTP协议负载均衡核心概念
HTTP协议负载均衡是通过分发HTTP请求到多台后端服务器,提升系统吞吐量、可用性和响应速度的技术，其核心目标是平衡请求压力，避免单点过载，同时确保用户体验。
负载均衡分类（按协议层级）
| 类型 | 工作层级 | 典型设备/软件 | 特点 |
|---|---|---|---|
| 四层负载均衡 | TCP层 | F5 LTM、LVS（Linux） | 基于IP和端口转发，效率高但无法解析应用层数据 |
| 七层负载均衡 | HTTP/HTTPS层 | Nginx、HAProxy、Apache | 解析HTTP头，支持URL、Cookie等高级策略 |
常见负载均衡算法
轮询（Round Robin）
- 顺序循环分配请求,简单公平，但不考虑服务器性能差异。
- 适用场景：服务器性能相近的集群。
加权轮询（Weighted Round Robin）
- 为服务器设置权重,按比例分配请求（如服务器A:3，服务器B:1）。
- 适用场景：服务器性能差异大的环境。
IP哈希（IP Hash）
- 根据客户端IP计算哈希值,固定分配到同一后端服务器。
- 优点：保证会话粘性（Session Persistence）。
- 缺点：单点故障时可能中断服务。
最少连接（Least Connections）
- 优先分配给当前连接数最少的服务器。
- 适用场景：请求处理时间差异大的场景（如动态API）。
负载均衡实现方式
| 实现类型 | 代表技术 | 特点 |
|---|---|---|
| 硬件负载均衡 | F5 BIG-IP、A10 | 高性能但成本高，适合大规模企业 |
| 软件负载均衡 | Nginx、HAProxy、Keepalived | 低成本且灵活，需部署在Linux服务器 |
| 云服务负载均衡 | AWS ELB、阿里云SLB | 一键开通，自动扩缩容，适合云原生架构 |
健康检查机制
负载均衡器需定期检测后端服务器状态,避免将流量发送到故障节点：
- 主动检查：定期发送HTTP请求（如GET /health）或TCP握手。
- 被动检查：根据服务器响应状态码（如500错误）标记异常。
- 自定义脚本：通过Shell、Python等脚本执行复杂检查逻辑。
会话保持（Session Persistence）方案
| 方案 | 原理 | 适用场景 |
|---|---|---|
| Cookie插入 | 负载均衡器生成Cookie并写入响应头 | 浏览器端会话保持 |
| IP地址绑定 | 通过IP哈希固定用户到同一后端服务器 | IP固定的场景（如局域网） |
| 域名后缀分割 | 不同子域名指向不同服务器（如a.example.com→Server1） | CDN加速与静态资源分离 |
优缺点对比
| 优势 | 劣势 |
|---|---|
| 提升系统吞吐量与可用性 | 增加架构复杂度 |
| 隐藏后端拓扑，增强安全性 | 可能成为性能瓶颈（单点故障） |
| 支持动态扩缩容 | 会话保持需额外配置 |
相关问题与解答
问题1：如何选择负载均衡算法？
解答：
- 简单均衡：轮询或加权轮询，适合同构服务器集群。
- 会话敏感：IP哈希或Cookie插入，确保用户请求一致性。
- 动态负载：最少连接，适配请求处理时间差异大的场景。
- 混合策略：结合多种算法（如加权轮询+健康检查）。
问题2：负载均衡器本身故障怎么办？
解答：
- 冗余部署：采用主备模式（如HAProxy双机热备）。
- DNS轮询：通过多个域名解析实现负载均衡器高可用。
- 云服务方案：使用云厂商提供的多可用区负载均衡（如AWS ELB跨AZ部署
