流量分配:互联网的"红绿灯"系统,是谁在决定你的请求去哪儿?
Site Owner
Published on 2026-05-31
每一个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)算法换了一种思路:哪台服务器当前处理的请求最少,就把新请求发给谁。
这相当于餐厅叫号系统:哪桌吃完了(连接数少),就叫下一位进去。正在大快朵颐的那桌(连接数多),继续慢慢吃。
这个算法的前提假设是:每台服务器处理能力相近。但现实中服务器性能差异往往很大——高配和低配机器同时运行,最小连接数算法可能把大量请求发给低配机器,导致它先挂掉。
于是,加权最小连接数算法出现了:分子是当前连接数,分母是服务器权重,比值最小的优先。性能高的服务器权重高,分摊的负载自然更多。
四、为什么CDN厂商和AI推理平台格外在意流量分配
2026年,Cloudflare披露了一组数据:他们的全球网络承载了约20%的互联网流量,日均请求超过万亿级别。一次路由策略的选择,不只影响延迟,还直接影响成本。
这和AI推理场景有异曲同工之妙。
以Kimi为例,其API通过Mooncake推理架构实现了超过90%的缓存命中率。缓存命中率高,意味着大量相似请求根本不需要打到模型推理节点,而是在缓存层直接返回——这极大降低了计算资源的消耗。
但这套体系要运转,依赖的正是流量分配层的精准调度:相似请求要打到同一缓存节点,不同请求要均匀分散到不同推理实例——负载均衡算法在其中扮演了看不见的基础角色。