负载均衡策略哪几种？常见的负载均衡算法有哪些？

负载均衡策略本质上是流量分发的规则集，其核心上文归纳在于：主要分为静态策略（基于预设规则分发）和动态策略（基于实时服务器状态分发），以及针对特定场景的算法策略。 在构建高可用、高并发的分布式系统架构时，选择正确的负载均衡策略直接决定了系统的吞吐量、响应延迟、资源利用率以及整体容灾能力，架构师需要根据业务场景的读写特性、服务器硬件配置差异以及会话保持需求，灵活配置或组合这些策略,以实现性能最优解。

静态负载均衡策略

静态策略不考量后端服务器的实时负载状态，而是根据管理员预设的算法进行流量分发，这类策略配置简单，计算开销小,适用于服务器性能相近且请求处理时间差异不大的场景。

轮询
这是最基础且最常用的策略，负载均衡器将 incoming 的网络请求按顺序逐一分配给后端服务器，如果第一台服务器分配完毕,则循环分配给下一台。

• 适用场景： 适用于后端所有服务器硬件配置一致、业务处理能力相当的情况。
• 优势： 算法简单，实现容易,能够绝对保证请求在服务器间的平均分配。
• 劣势： 无法感知服务器实际负载，若某台服务器处理较慢,会导致请求堆积。

加权轮询
为了解决服务器性能不一致的问题，引入了“权重”概念，管理员根据硬件配置（CPU、内存）为每台服务器设置权重值，权重越高,被分配到的请求概率越大。

• 适用场景： 集群中存在新旧服务器混用,或部分服务器配置更高的情况。
• 优势： 充分利用高性能服务器的资源,避免低配服务器过载。
• 专业见解： 在平滑升级场景中，可以给新版服务设置较小权重进行灰度发布，逐步调整流量比例,降低发布风险。

随机
通过随机算法选择一台服务器进行分发，在并发量极大的情况下,随机算法在统计学上能接近轮询的效果。

• 适用场景： 并发量巨大的场景。
• 优势： 在极高并发下，相比轮询不需要维护当前的计数器状态，减少了锁竞争,性能略优于轮询。

源地址哈希
根据客户端的 IP 地址（或 URL 等信息）计算哈希值，再对服务器总数取模,将请求映射到特定的服务器。

• 适用场景： 需要会话保持的场景，例如电商购物车、WebSocket 连接。
• 优势： 能够确保来自同一 IP 的请求始终落在同一台服务器上，避免分布式 Session 同步的复杂性。
• 劣势： 容易导致负载不均，即“哈希倾斜”，当某类用户访问量激增时，对应服务器会过载,而其他服务器闲置。

动态负载均衡策略

动态策略更加智能，负载均衡器会通过监控机制实时采集后端服务器的负载指标（如连接数、响应时间、CPU 使用率），并据此动态调整流量分发,这是构建现代化弹性架构的关键。

最少连接
优先将请求分配给当前连接数最少的服务器，负载均衡器维护一个活跃连接计数器,每次分配前进行比对。

• 适用场景： 请求处理时间长短差异巨大的场景，例如长连接业务、下载服务或数据库查询服务。
• 优势： 能够有效避免长请求占用连接导致服务器负载不均,实现了基于真实负载的均衡。

加权最少连接
在“最少连接”的基础上，结合服务器权重进行计算，通常算法为 (当前连接数 / 权重) 最小者胜出。

• 适用场景： 服务器性能不一,且请求处理时间波动较大的复杂场景。
• 优势： 兼顾了硬件性能差异和实时负载压力,是目前企业级应用中性价比极高的策略。

最短响应时间
优先将请求分配给响应速度最快的服务器,这需要负载均衡器主动探测或统计每个请求的响应延迟。

• 适用场景： 对用户体验极其敏感,且后端服务网络状况或处理能力波动的场景。
• 优势： 能够显著降低用户感知的延迟,提升整体系统的吞吐量。
• 专业解决方案： 建议配合“慢启动”机制使用，当一台新服务器加入集群时，不立即把大量流量分给它，而是随着时间推移逐渐增加权重,防止新机瞬间被压垮。

全局与基于内容的策略

随着微服务和云原生的发展，更高级别的策略被广泛应用，它们通常工作在七层（应用层）。

基于地理位置
根据用户的地理位置（GeoIP）,将请求路由到距离最近的数据中心。

• 适用场景： 跨地域、跨国业务的大型互联网应用。
• 优势： 极大降低物理传输延迟，提升访问速度,并符合数据合规性要求。

根据 HTTP 请求的具体内容（如 URL 路径、Cookie、Header 信息）进行路由。

• 适用场景： 微服务架构，将 /api/user 的请求路由到用户服务，/api/order 路由到订单服务。
• 优势： 实现了流量的精细化管理，是 API 网关的核心功能之一。

专业见解与架构建议

在实际的架构设计中，单一策略往往无法满足复杂需求，推荐采用“分层组合”与“自适应调整”的方案。

健康检查是所有策略生效的前提。 无论选择何种算法，必须配置严格的主动健康检查（如 TCP/HTTP 探测），一旦后端节点异常，负载均衡器必须立即将其剔除流量池，待恢复后再自动加入,这是保证系统高可用的基石。

解决“有状态”服务的最佳实践是引入外部缓存。 虽然源地址哈希能解决 Session 问题，但它牺牲了负载均衡的灵活性，更专业的架构是将 Session 存储在 Redis 或 Memcached 等分布式缓存中，这样后端服务器可以完全无状态化，从而自由使用“加权最少连接”等更高效的动态策略,实现弹性伸缩。

关注长尾效应。 在动态策略中，为了防止某台服务器因为处理极慢的请求而被判定为“快”的（因为连接数新释放），建议算法中综合考虑“连接数”和“移动平均响应时间”,避免算法被误导。

相关问答

Q1：在微服务架构中，应该选择四层负载均衡还是七层负载均衡？
A： 建议组合使用。四层负载均衡（L4，如 LVS） 工作在传输层，仅解析 IP 和端口，性能极高，适合处理海量并发流量的入口转发；七层负载均衡（L7，如 Nginx、HAProxy） 工作在应用层，可以解析 HTTP 头部、URL 和 Cookie，适合做路由分发、内容重写和细粒度的流量控制，通常的架构模式是 L4 负责抗住入口流量并转发给 L4 集群，L7 集群再根据业务规则将请求分发给具体的微服务实例。

Q2：为什么有时候使用了加权轮询，服务器负载依然不均？
A： 这通常是因为忽略了请求的“异构性”，加权轮询假设所有请求消耗的资源是相同的，但如果业务中既有简单的“读请求”，又有复杂的“写请求”，且这两种请求随机分布，那么处理复杂请求的服务器即使权重较低，实际负载也会很高。解决方案是改用“最少连接”或自定义基于请求类型的加权策略，或者将读写流量拆分到不同的集群,分别进行负载均衡。

互动环节：
您的业务系统目前采用的是哪种负载均衡策略？在应对突发流量时，是否遇到过负载不均导致的性能瓶颈？欢迎在评论区分享您的实战经验与解决方案,我们一起探讨高可用架构的优化之道。