Cloudflare的规模大到什么程度？全球数千台服务器，内存以PB计，CPU核心数以百万计，而且全部拉满运行。资源再庞大也是有限的，当每个节点都要跑所有服务时，浪费一点空间都是奢侈。

在这种体量下，小改进会被急剧放大。1%的优化都值得庆祝，而有些调整带来的收益远超于此。Cloudflare工程团队最近披露，他们通过修改一个算法，让某个基于Pingora的服务内存占用大幅下降，全球范围内回收了超过100TB的内存。这还是在DNS团队上个月刚释放100TB内存的基础上。

打开网易新闻 查看精彩图片

一张工单引出的问题

故事始于工程师Ivan提交的一张工单：Pingora Backend Router（内部负载均衡服务，简称PBR）的内存使用量异常偏高，问题集中在与pingora-ketama相关的数据结构上。pingora-ketama是Cloudflare处理一致性哈希的开源库。

要理解内存为何被吃掉，得先搞清楚一致性哈希是什么、PBR为什么用它，以及它怎么变得如此耗内存。这中间还涉及一些Rust和数学。

一致性哈希的简单与代价

一致性哈希是一种广泛使用的任务分配方法，在增删服务器时不需要大规模调整。Cloudflare内部用它按URL把可缓存请求路由到服务器，这样每个数据中心只存一份文件副本，并能稳定找到每个文件的位置。

核心概念是：哈希函数接受任意输入，但输出限定为一个无符号整数（32、64或128位）。多数讨论会把输出空间想象成一个首尾相接的圆环，但Cloudflare选择用数轴来呈现32位输出。

假设有服务器A、B、C和任务t到z，按各自代表值的哈希映射到数轴上。分配任务就是找每个任务左侧最近的服务器。服务器C覆盖的范围会绕回起点，这就是“环”的由来。

问题很快显现：服务器A覆盖的范围明显大于B和C。服务器处理的请求比例与其在数轴上的范围大小成正比。理想情况下每个服务器范围相等，但哈希本质上是随机数，只能从统计角度讨论范围大小。

数学给出的警告

用期望值和标准差就能量化这种不确定性。期望值给出分布的中心点，标准差说明多数测量值离中心有多近。对于N台服务器中的一台，可以计算其范围占比的这两个指标。

具体到100台服务器，计算结果显示每台服务器处理的范围期望在总体的0.99%左右，多数长度落在期望值1%以内。听起来不错，但这是总长度的0.99%。把标准差按期望值缩放，得到变异系数，才能看出误差相对于目标尺寸有多大。

一致性哈希的简单是双刃剑。所有东西都变成数轴上易关联的哈希，理解实现都容易，但任何改进也只能通过增加哈希来实现。这不像金锤子，更像金钉子——它把所有工具都变成了锤子。

解决负载不均的办法，是给每台服务器添加多个哈希而非一个。数学推导还在继续，但方向已经明确：用更多哈希换取更均衡的分布，同时控制内存开销。