一句话结论
Cloudflare 重构 Pingora 后端路由一致性哈希数据结构，使单服务器哈希点减少约 90%，全集群节省超 100 TB 内存。
关键要点
- 单台后端服务器哈希点数量减少约 90%，同时保持负载均衡误差在可接受范围内。
- 全集群内存占用降低超过 100 TB，主要来源于哈希环条目压缩与数据结构字节精简。
- 优化采用灰度并行策略，新哈希环与旧环同时运行，避免一次性切换导致的缓存失效与回源流量尖峰。
- 旧版 Pingora-Ketama 使用 8 字节 Point 结构体存储哈希值与服务器索引，新版本精简为 6 字节。
背景与事实
Cloudflare 在其 Pingora 后端路由层依赖一致性哈希，将可缓存请求在多台后端服务器间进行分发。由于业务侧支持加权服务器与差异化功能组合，系统需要维护数量庞大的哈希环，长期运行下内存开销持续攀升。团队最终定位到内存膨胀的根因位于 pingora-ketama 模块的一致性哈希数据结构，并启动了针对性重构。
此次改动核心思路是引入概率统计方法重新计算哈希点数下限。团队测算出，在满足既定分布误差要求的前提下，每个后端服务器实际所需的哈希点远少于原实现保留的数量。随着哈希点增加，误差改善呈边际递减：误差每降低一个数量级，（几乎）需要每服务器哈希数量增加一个数量级；最后新增的 90,000 个哈希仅将误差改善 0.7%。与此同时，生日悖论（描述随机取值集合中碰撞概率远超直觉的现象）表明，32 位哈希点数量增长会显著提升碰撞概率，碰撞本身又会引入额外的分布误差。基于上述分析，团队将单台服务器的哈希数量削减约 90%。
在数据结构层面，原实现使用 8 字节的 Point 结构体保存哈希值与服务器索引，但实际仅需 6 字节即可完整存放，该精简直接降低了每个哈希条目的常驻内存。据 Cloudflare 披露，整套优化全集群累计节省内存超过 100 TB。
影响分析
对中文开发者与从业者而言，本次优化首先提示一个现实：在高并发缓存与负载均衡系统中，看似微不足道的单条数据结构调整，乘以海量请求与节点规模后，会形成以十亿、十 TB 量级计的成本差异。对架构师而言，评估一致性哈希方案时不应只看算法正确性，还应把内存足迹、缓存命中率与回源流量纳入统一指标。需要明确的是，这是基于 Cloudflare 内部实践的分析判断：其 100 TB 内存节省建立在自有流量规模与硬件配置之上，中小规模集群未必能复现同等绝对收益，但“先统计建模、再灰度切换、最后并行验证”的方法论具有通用迁移价值。
适用边界
该结论主要适用于自研一致性哈希或可定制负载均衡中间件的大规模生产系统。若使用的是开源默认参数、且请求模式与 Cloudflare 可缓存流量差异较大的系统，90% 的哈希点压缩比未必保持同等误差水平，需重新做分布与碰撞统计。对于无法并行运行新旧哈希环、或缓存层不具备灰度能力的架构，一次性切换风险较高，文中并行过渡方案不适用。此外，100 TB 的内存节省为 Cloudflare 全集群口径，单一公司或单一数据中心的绝对数字不能直接平移。
孤本观察
作为编辑判断，本次事件真正值得注意的是 Cloudflare 把概率论与生日悖论前置到哈希点数量决策中，而非停留在“减少内存”的工程直觉层面。这种用统计推导为数据结构规模定下限的做法，比单纯优化字节宽度更具可复用性。
常见问题
新版本的 Pingora-Ketama 数据结构将 Point 结构体从多少字节精简为多少字节？
原实现使用 8 字节 Point 结构体，新版本精简为 6 字节。
此次优化使单台后端服务器的哈希点数量减少了约多少百分比？
单台后端服务器哈希点数量减少约 90%。
Cloudflare 全集群因该优化累计节省了超过多少内存？
全集群内存占用降低超过 100 TB。
为了缓存失效与回源流量尖峰，优化采用了哪种切换策略？
采用灰度并行策略，新哈希环与旧环同时运行。
最后新增的 90,000 个哈希点仅将误差改善了多少？
最后新增的 90,000 个哈希仅将误差改善 0.7%。
来源：InfoQ 中文 AI