负载均衡策略 本质上是流量分发的规则集，其核心上文归纳在于： 主要分为静态策略（基于预设规则分发）和动态策略（基于实时服务器状态分发），以及针对特定场景的算法策略。 在构建高可用、高并发的分布式系统架构时，选择正确的负载均衡策略直接决定了系统的吞吐量、响应延迟、资源利用率以及整体容灾能力，架构师需要根据业务场景的读写特性、服务器硬件配置差异以及会话保持需求，灵活配置或组合这些策略,以实现性能最优解。
静态负载均衡策略
静态策略不考量后端服务器的实时负载状态，而是根据管理员预设的算法进行流量分发，这类策略配置简单，计算开销小,适用于服务器性能相近且请求处理时间差异不大的场景。
轮询 这是最基础且最常用的策略，负载均衡器将 incoming 的网络请求按顺序逐一分配给后端服务器，如果第一台服务器分配完毕,则循环分配给下一台。
加权轮询 为了解决服务器性能不一致的问题，引入了“权重”概念，管理员根据硬件配置（CPU、内存）为每台服务器设置权重值，权重越高,被分配到的请求概率越大。
随机 通过随机算法选择一台服务器进行分发，在并发量极大的情况下,随机算法在统计学上能接近轮询的效果。
源地址哈希 根据客户端的 IP 地址（或 URL 等信息）计算哈希值，再对服务器总数取模,将请求映射到特定的服务器。
动态负载均衡策略
动态策略更加智能，负载均衡器会通过监控机制实时采集后端服务器的负载指标（如连接数、响应时间、CPU 使用率），并据此动态调整流量分发,这是构建现代化弹性架构的关键。
最少连接 优先将请求分配给当前连接数最少的服务器，负载均衡器维护一个活跃连接计数器,每次分配前进行比对。
加权最少连接
在“最少连接”的基础上，结合服务器权重进行计算，通常算法为
(当前连接数 / 权重)
最小者胜出。
最短响应时间 优先将请求分配给响应速度最快的服务器,这需要负载均衡器主动探测或统计每个请求的响应延迟。
全局与基于内容的策略
随着微服务和云原生的发展，更高级别的策略被广泛应用，它们通常工作在七层（应用层）。
基于地理位置 根据用户的地理位置（GeoIP）,将请求路由到距离最近的数据中心。
根据 HTTP 请求的具体内容（如 URL 路径、Cookie、Header 信息）进行路由。
专业见解与架构建议
在实际的架构设计中， 单一策略往往无法满足复杂需求，推荐采用“分层组合”与“自适应调整”的方案。
健康检查是所有策略生效的前提。 无论选择何种算法，必须配置严格的主动健康检查（如 TCP/HTTP 探测），一旦后端节点异常，负载均衡器必须立即将其剔除流量池，待恢复后再自动加入,这是保证系统高可用的基石。
解决“有状态”服务的最佳实践是引入外部缓存。 虽然源地址哈希能解决 Session 问题，但它牺牲了负载均衡的灵活性，更专业的架构是将 Session 存储在 Redis 或 memcached 等分布式缓存中，这样后端服务器可以完全无状态化，从而自由使用“加权最少连接”等更高效的动态策略,实现弹性伸缩。
关注长尾效应。 在动态策略中，为了防止某台服务器因为处理极慢的请求而被判定为“快”的（因为连接数新释放），建议算法中综合考虑“连接数”和“移动平均响应时间”,避免算法被误导。
相关问答
Q1：在微服务架构中，应该选择四层负载均衡还是七层负载均衡？ 建议组合使用。 四层负载均衡（L4，如 LVS） 工作在传输层，仅解析 IP 和端口，性能极高，适合处理海量并发流量的入口转发； 七层负载均衡（L7，如 Nginx、HAProxy） 工作在应用层，可以解析 HTTP 头部、URL 和 Cookie，适合做路由分发、内容重写和细粒度的流量控制，通常的架构模式是 L4 负责抗住入口流量并转发给 L4 集群，L7 集群再根据业务规则将请求分发给具体的微服务实例。
Q2：为什么有时候使用了加权轮询，服务器负载依然不均？ 这通常是因为忽略了请求的“异构性”，加权轮询假设所有请求消耗的资源是相同的，但如果业务中既有简单的“读请求”，又有复杂的“写请求”，且这两种请求随机分布，那么处理复杂请求的服务器即使权重较低，实际负载也会很高。 解决方案是改用“最少连接”或自定义基于请求类型的加权策略 ，或者将读写流量拆分到不同的集群,分别进行负载均衡。
互动环节： 您的业务系统目前采用的是哪种负载均衡策略？在应对突发流量时，是否遇到过负载不均导致的性能瓶颈？欢迎在评论区分享您的实战经验与解决方案,我们一起探讨高可用架构的优化之道。
发表评论