负载均衡是分布式系统架构中承上启下的关键环节，它决定了请求如何在多台后端服务器之间分配。不同的负载均衡算法适用场景差异很大：选对了，集群资源利用率高、响应稳定；选错了，就会出现有的服务器忙到宕机、有的却在闲逛的尴尬局面。轮询、加权轮询、最小连接是最常见的三种静态与动态调度算法，理解它们的原理和适用边界，是做好架构选型的基础。
轮询算法：最简单直接的公平分发
轮询算法的思路非常朴素：把所有后端服务器放进一个列表，每来一个请求，就按顺序取下一台服务器处理，取到最后一个再回到开头循环。整个过程不需要记录任何状态，只需要维护一个递增的计数器即可。
用一个简单的Go实现来展示核心逻辑：
type RoundRobin struct {
servers []string
current int
}
func (r *RoundRobin) Next() string {
server := r.servers[r.current%len(r.servers)]
r.current++
return server
}轮询的优点显而易见：实现简单、无状态、计算开销几乎为零，Nginx在不做任何配置时默认就是这种策略。但它的短板同样突出：第一，它默认所有服务器能力完全相同，一旦集群里混入了配置较低或负载较高的机器，请求依旧会被平均分过去，性能短板很快暴露；第二，它假设每个请求的处理耗时大致相当，如果某些请求特别耗时，被分配到的那台服务器连接数会持续堆积，负载实际上并不均衡。
因此轮询适合的场景是：集群机器配置一致、请求处理时间相对均匀的短连接业务，比如纯静态资源服务、健康检查后端的代理转发等。
加权轮询：让强机器多干活
真实生产环境中，服务器配置往往参差不齐，16核机器和4核机器如果平分流量显然不合理。加权轮询的核心改进就是给每台服务器分配一个权重值，权重越高，被选中的概率越大。比如A、B、C三台机器权重分别是5、1、1，那么每7个请求中A要承接5个。
加权轮询有随机和平滑两种实现思路。随机方式按权重概率选取，短时间内分布可能不均；Nginx采用的则是平滑加权轮询，它能让高权重节点的请求在时间维度上分散开来，而不是连续命中。其算法为：每个节点维护两个变量，当前权重current_weight和配置权重weight，每次选择时所有节点的current_weight加上自身weight，选出current_weight最大的节点，再把该节点的current_weight减去总权重。看一段Go实现：
type WeightedServer struct {
Name string
Weight int
Current int
}
func SmoothWeighted(servers []*WeightedServer) *WeightedServer {
total := 0
var best *WeightedServer
for _, s := range servers {
s.Current += s.Weight
total += s.Weight
if best == nil || s.Current > best.Current {
best = s
}
}
if best != nil {
best.Current -= total
}
return best
}以权重5、1、1为例，平滑加权轮询的调度序列大致是A A B A C A A，而不是AAAAA BC这样的突刺分布，这对于连接数敏感的业务很重要。
加权轮询的局限在于权重是静态配置的，无法感知服务器的实时负载。如果某台高权重机器突然因为磁盘IO变慢，请求依然会源源不断打过去，形成局部热点。这时候就需要动态算法登场了。
最小连接算法：动态感知实时负载
最小连接算法放弃了预设的分配比例，转而观察每台服务器当前的活跃连接数，每次都把新请求交给连接数最少的那台。它的前提假设是：连接数越少，说明服务器越空闲。这种方式对请求耗时差异大的场景特别友好，例如有的请求10毫秒返回，有的要执行30秒的复杂查询，轮询算法下两者一视同仁，而最小连接算法能自然地把流量导向更快释放连接的机器。
LVS、HAProxy和Nginx的least_conn指令都支持该策略。HAProxy的配置示例：
backend web_servers
balance leastconn
server app1 192.168.1.10:8080 check
server app2 192.168.1.11:8080 check
server app3 192.168.1.12:8080 check需要注意的是，最小连接算法在长连接场景下要谨慎使用。如果业务采用WebSocket或HTTP长连接，早期建立的连接会长期挂在少数服务器上，新机器加入集群后可能长期拿不到连接，负载反而失衡。此外，连接数少也不完全等于负载低，一台机器连接少可能是因为它处理慢、请求都在排队，单纯按连接数调度可能误判。一些进阶实现会结合响应时间、CPU利用率等指标做综合判断，例如HAProxy就支持结合权重观察连接的变体。
三种算法对比与选型建议
把三种算法放在同一张表里横向对比，差异一目了然：
| 算法 | 状态维护 | 感知服务器差异 | 感知实时负载 | 适用场景 |
|---|---|---|---|---|
| 轮询 | 仅计数器 | 否 | 否 | 同构集群、请求耗时均匀 |
| 加权轮询 | 计数器加权重 | 静态权重 | 否 | 异构集群、短连接业务 |
| 最小连接 | 各节点连接数 | 动态体现 | 是 | 请求耗时差异大、混合负载 |
从选型经验来看：如果集群机器规格统一、请求处理时间稳定，轮询是最省心的选择，运维成本几乎为零；如果机器性能参差不齐但请求模式简单，加权轮询是性价比最高的方案，只需根据机器配置估算权重即可；如果业务里既有轻量API又有重计算任务，或者请求耗时波动明显，最小连接算法明显更合适。
最后还有两点实践建议。一是无论选择哪种算法，都要配合健康检查机制，及时把故障节点摘除，否则再精妙的调度算法也会把请求打进死机器。二是权重和参数不是配完就一劳永逸的，应结合监控数据观察各节点的CPU、内存和响应时间，必要时调整权重或切换策略。负载均衡算法没有绝对的最优解，只有与业务特征匹配程度的差别，理解每种算法背后的假设条件，比记住配置命令更重要。