负载均衡是什么？负载均衡有哪些常见算法

在互联网高并发架构中,负载均衡（Load Balancing, LB）是确保系统高可用性、高扩展性和高性能的核心组件，它通过将 incoming 流量分发到多个后端服务器，避免了单点故障，并最大化了资源利用率，以下是对负载均衡技术的深度解析。

负载均衡的核心价值

负载均衡不仅仅是流量的“分发器”，更是现代分布式系统的“交通指挥官”，其主要价值体现在以下三个方面：

1. 高可用性（High Availability）：当某台后端服务器宕机或响应超时，负载均衡器会自动将其从服务池中剔除，将流量转发至健康节点，从而保证业务不中断。
2. 横向扩展能力（Scalability）：随着业务流量增长，只需在负载均衡器后端增加新的服务器节点，即可线性提升系统处理能力，无需重构应用逻辑。
3. 性能优化：通过合理的调度算法，避免单台服务器过载，降低响应延迟，提升用户体验。

负载均衡的分层架构

负载均衡并非单一技术,而是根据工作层级不同，分为多个层次，每一层解决不同的问题。

核心调度算法详解

负载均衡器的灵魂在于其调度算法,不同的算法决定了流量如何被分配给后端服务器。

静态算法（不依赖后端状态）

• 轮询（Round Robin）：
  • 机制：将请求依次分配给后端服务器，循环往复。
  • 优点：实现简单，公平。
  • 缺点：假设所有服务器性能一致，若后端服务器性能差异大，可能导致性能瓶颈。

• 加权轮询（Weighted Round Robin）：
  • 机制：为每台服务器设置权重（Weight），权重越高，接收到的请求比例越大。
  • 优点：解决了服务器性能不均的问题，高性能机器承担更多流量。

• 随机（Random）：
  • 机制：随机选择一台后端服务器。
  • 优点：实现简单。
  • 缺点：在请求量较少时，负载分布可能不均匀。

动态算法（依赖后端实时状态）

• 最少连接数（Least Connections）：
  • 机制：将新请求分配给当前活跃连接数最少的服务器。
  • 优点：非常适合长连接场景（如 WebSocket、数据库连接），能更好地平衡负载。

• 响应时间（Least Response Time）：
  • 机制：选择平均响应时间最短且当前连接数最少的服务器。
  • 优点：追求极致的用户体验，优先选择“最快”的机器。

• 一致性哈希（Consistent Hashing）：
  • 机制：根据客户端 IP 或 Session ID 计算哈希值，映射到特定的服务器。
  • 优点：保证同一客户端的请求总是落到同一台服务器上，天然支持 Session 保持（Session Affinity）。
  • 缺点：当服务器节点增减时，哈希环变动会导致大量缓存失效或会话丢失（需引入虚拟节点解决）。

关键概念：会话保持（Session Affinity）

在 Web 应用中，用户登录后状态通常存储在服务器内存或本地文件中，如果负载均衡器将同一用户的后续请求分发到不同服务器，会导致用户被迫重新登录。

解决会话保持主要有两种方案：

1. Cookie 插入（Source IP / Cookie Insert）：
   • 负载均衡器在响应中插入一个包含服务器 ID 的 Cookie，后续请求携带该 Cookie，LB 据此将请求转发给指定服务器。
   • 缺点：依赖 Cookie，若用户禁用 Cookie 则失效；且服务器宕机后，该服务器上的 Session 数据丢失。
2. 外部集中式存储（推荐）：
   • 将 Session 数据存储在 Redis、Memcached 等共享存储中。
   • 优点：服务器无状态，任意节点均可处理请求，高可用性最强。

健康检查机制

健康检查是负载均衡器判断后端服务器是否“存活”的手段。

• 检查方式：
  • TCP 检查：尝试建立 TCP 连接，成功即认为健康，速度快，开销小。
  • HTTP 检查：发送 HTTP GET 请求到特定路径（如 /health），检查返回状态码是否为 200，能检测应用层故障（如数据库连接池满导致应用假死）。
  • UDP 检查：适用于 DNS、VoIP 等 UDP 协议服务。

• 检查频率与阈值：

  需平衡“故障发现速度”与“系统开销”，通常设置为每隔 3-5 秒检查一次，连续失败 2-3 次则标记为下线，连续成功 2-3 次则标记为上线。

现代云原生环境下的负载均衡

在 Kubernetes 和微服务架构中，负载均衡的概念进一步下沉和细化：

1. Ingress Controller：作为集群的入口，负责七层路由，将外部流量分发到集群内的 Service。
2. Service (ClusterIP/NodePort)：Kubernetes 内部的负载均衡器，通过 kube-proxy 实现 iptables 或 IPVS 规则，将流量分发到 Pod。
3. Sidecar 模式（Service Mesh）：如 Istio，在应用旁部署 Envoy 代理，实现更细粒度的流量控制（如灰度发布、熔断、限流），此时负载均衡逻辑由 Service Mesh 接管，而非传统 LB 设备。

相关问题与解答

问题 1：在微服务架构中，为什么通常建议将 Session 存储在 Redis 等外部存储中，而不是依赖负载均衡器的会话保持功能？

解答：

依赖负载均衡器的会话保持（如基于 Cookie 或 IP 哈希）存在显著缺陷，如果承载用户 Session 的后端服务器发生宕机，该用户的所有会话数据将立即丢失，导致用户体验中断，需要重新登录，随着服务器节点的动态伸缩（Scale-out/in），基于 IP 或 Cookie 的绑定关系可能失效，导致请求被分发到没有该用户 Session 的新节点上。

相比之下，将 Session 存储在 Redis 等共享存储中，实现了后端服务器的“无状态化”，任何健康的服务器节点都可以处理该用户的请求，极大地提高了系统的容错能力和扩展性，符合云原生架构的最佳实践。

问题 2：L4 负载均衡和 L7 负载均衡的主要区别是什么？在什么场景下应该优先选择 L4 负载均衡？

解答：

主要区别在于处理数据的层级和性能开销，L4 负载均衡工作在传输层，仅根据 IP 地址和端口号进行数据包转发，不解析应用层内容，因此处理速度极快，CPU 开销极低，吞吐量巨大，L7 负载均衡工作在应用层，需要解析 HTTP/TCP 等协议内容，支持基于 URL、Header 等复杂规则的路由，但解析过程带来了额外的 CPU 和内存开销，性能低于 L4。

优先选择 L4 的场景包括：

1. 超高并发流量：如视频流媒体、大型游戏服务器、分布 防护入口，需要处理每秒数十万甚至百万级的连接。
2. 非 HTTP 协议：如 TCP/UDP 数据库连接、Redis 集群、MQTT 物联网协议等，这些协议无法进行 L7 的内容解析。
3. 对延迟极度敏感：L4 转发几乎无延迟，适合高频交易或实时通信场景。