每一个HTTP请求背后，都有一道看不见的关卡在决定它的去向——负载均衡器。我们拆解了轮转、哈希、最小连接数等核心算法，以及它们如何影响互联网的性能与成本。

流量分配：互联网的"红绿灯"系统，是谁在决定你的请求去哪儿？

2025年双十一，天猫峰值请求量突破4200万/秒。同一时刻，你在北京下单，他在上海抢购，另一位用户在深圳秒杀——所有人的请求都打在同一堆服务器上，却几乎没感受到卡顿。

这不是奇迹，是流量分配算法在实时运转。

每一个你发出的HTTP请求，从发出到到达应用服务器，中间必经一道"关卡"——负载均衡器。它是互联网的基础交通枢纽，每秒钟决定亿万个请求该走哪条路、开哪个灯。然而，你几乎从未听说它的名字。

今天，我们来拆解这个看不见的"调度员"，以及它背后的几种核心算法。

一、轮转算法：最公平的老实人

轮转（Round Robin）是负载均衡里最简单粗暴的策略。

原理很简单：假设你有3台服务器，请求来了，第一条给A，第二条给B，第三条给C，第四条再给A——循环往复，像点名一样均匀。

听起来很公平。但它有一个致命盲点：完全忽略每台服务器的实际负载和性能差异。

A服务器是32核128G的高配，B服务器是4核8G的老古董，C服务器是16核32G的准旗舰——按轮转，三个服务器收到的请求数量相同，但扛的流量却天差地别。老古董可能已经被压到濒临崩溃，而高配可能还在悠闲散步。

轮转的优势是简单，适合服务器配置完全相同的场景。一旦配置有差异，它就成了"吃大锅饭"——干多干少一个样。

轮转解决不了一个问题：会话保持。

你登录了某网站，第一步请求被分配到了服务器A，第二步支付请求却打到了服务器B——服务器B上没有你的登录态，你被迫重新登录。

源地址哈希（Source Address Hash）就是为了解决这个问题。

它的做法是：把请求来源IP作为哈希键，计算出一个值，然后映射到对应的服务器。同一个IP地址的请求，永远打到同一台服务器，就像记住了你的家门牌号。

这个算法的好处是简单，不需要额外的会话存储，天然支持长连接场景，比如SSH隧道、游戏服务器、VPN等。它的缺点也很明显：当某台服务器下线时，大量请求的哈希映射会失效，导致大规模会话中断。

轮转是静态的——它不问服务器"累不累"，只管轮流发牌。

最小连接数（Least Connections）算法换了一种思路：哪台服务器当前处理的请求最少，就把新请求发给谁。

这相当于餐厅叫号系统：哪桌吃完了（连接数少），就叫下一位进去。正在大快朵颐的那桌（连接数多），继续慢慢吃。

这个算法的前提假设是：每台服务器处理能力相近。但现实中服务器性能差异往往很大——高配和低配机器同时运行，最小连接数算法可能把大量请求发给低配机器，导致它先挂掉。

于是，加权最小连接数算法出现了：分子是当前连接数，分母是服务器权重，比值最小的优先。性能高的服务器权重高，分摊的负载自然更多。

2026年，Cloudflare披露了一组数据：他们的全球网络承载了约20%的互联网流量，日均请求超过万亿级别。一次路由策略的选择，不只影响延迟，还直接影响成本。

这和AI推理场景有异曲同工之妙。

以Kimi为例，其API通过Mooncake推理架构实现了超过90%的缓存命中率。缓存命中率高，意味着大量相似请求根本不需要打到模型推理节点，而是在缓存层直接返回——这极大降低了计算资源的消耗。

但这套体系要运转，依赖的正是流量分配层的精准调度：相似请求要打到同一缓存节点，不同请求要均匀分散到不同推理实例——负载均衡算法在其中扮演了看不见的基础角色。