对于Cloudflare而言，运营规模的庞大往往超乎想象。在全球数千台服务器、PB级内存和数百万CPU核心全负荷运转的背景下，任何微小的资源浪费都被无限放大。因此，即使是1%的性能提升也极具价值。
近日，Cloudflare工程团队通过优化基于Pingora构建的服务，显著降低了内存占用。这一调整在全球范围内回收了超过100TB的RAM。加上此前DNS团队释放的100TB内存，成效惊人。
定位内存瓶颈
此次优化源于性能团队对内部负载均衡服务——Pingora后端路由器（PBR）的排查。工程师Ivan发现，PBR中用于处理一致性哈希的开源库pingora-ketama存在异常的内存高占用问题。
一致性哈希是Cloudflare将可缓存请求路由至特定服务器的核心机制，它确保了每个数据中心仅存储一份文件副本，并提供稳定的查找方式。然而，随着功能组合的增加，系统需要维护数十个独立的一致性哈希环，导致内存消耗呈指数级增长。
数据结构与算法的双重优化
解决思路分为两步：存储结构精简与哈希数量削减。
首先，工程师Zaidoon指出，PBR中存储哈希点的结构体包含一个32位哈希值和一个32位服务器索引。鉴于PBR协调的服务器数量不太可能超过6.5万（2^16），32位索引造成了空间浪费。通过将索引改为16位，并采用字节数组绕过Rust的内存对齐规则，单个数据点的大小从8字节缩减至6字节。这一改动使一致性哈希的内存占用直接降低了25%。
其次，团队重新审视了哈希数量的设定。传统做法是为每台服务器分配大量哈希点以平衡负载，默认值通常为160乘以权重。但数学推导显示，随着哈希数量增加，边际效益递减，且32位哈希空间的碰撞概率上升会引入不可预测的误差。基于新的变异系数公式，团队确认可以将每台服务器生成的哈希数量减少90%，而不会造成明显的负载不均。
无感迁移与灰度发布
更改哈希环会导致缓存请求路由变化，若一次性切换将引发缓存失效，导致源站流量激增。为此，Cloudflare设计了平滑迁移方案：
- 双环并行：PBR在内存中同时保留旧版ketama环和新版优化环，通过迁移框架决定每个请求的路由策略。
- 分层灰度：从小型验证位置开始，逐步扩展至大规模集群及全球其他地区，严格控制爆炸半径。
- 实时监控：全程监控后端选择、内存使用、启动时间及源站流量，确保异常时可即时回滚。
迁移完成后，旧环路径被移除。数据显示，此次变更使PBR的内存使用量减少了100TB。
目前，相关优化已整合进pingora-ketama库的v2版本中，支持更紧凑的存储格式和灵活的哈希缩放。这一案例表明，深入底层数据结构与数学原理，往往能在看似成熟的系统中挖掘出巨大的性能红利。