Cloudflare 再省 100TB 内存：哈希点并非越多越好
据 Cloudflare 9 月 18 日工程文章，团队通过调整 Pingora 后端路由器的一致性哈希结构，在全球合计回收超过 100TB 内存。这里的 100TB 是大量部署实例累加的结果，不是一台机器，也不是每个采用 Rust 的服务都能得到的收益。
作者：林岚｜OC 开发者生态编辑
据 Cloudflare 9 月 18 日工程文章，团队通过调整 Pingora 后端路由器的一致性哈希结构，在全球合计回收超过 100TB 内存。这里的 100TB 是大量部署实例累加的结果，不是一台机器，也不是每个采用 Rust 的服务都能得到的收益。
一句话结论：这次优化把数据结构、概率分布和上线迁移放在一起处理，省内存只是最后看见的结果。
为什么路由表会吃掉这么多内存
缓存请求需要稳定地找到某台后端。直接对服务器数量取模，扩缩容时容易让大量请求改道；一致性哈希则试图减少这种迁移。但只有一个位置代表一台机器时，随机区间可能很不均匀，因此工程上常为每台机器放多个虚拟点。
点越多，分配通常越平滑，却也要占更多内存。Cloudflare 还按容量给服务器加权，并为不同功能组合维护不同的环。一个看起来便宜的默认参数，经过权重、功能组合和部署数量放大，最终变成值得单独处理的资源项。
数学的作用不是给优化贴一个高级标签，而是判断：继续增加采样点，到底还能买到多少均衡性。如果收益已经很小，保留巨大结构就不是“保险一点”，而是在为过时的假设持续付费。
六个字节，不会自动变成六个字节
团队另一个改动更接近程序员日常：原来的哈希点由两个 32 位字段组成；后端索引缩成 16 位后，字段本身合计六字节，结构却可能因为对齐仍占八字节。文中采用六字节数组及访问方法，才把这一层存储降低四分之一。
它提醒我们，源代码中的类型宽度和进程实际占用不是同一张账单。对象对齐、容器容量、分配器和复制次数，都可能让纸面节省停留在纸面。测量实际布局，往往比猜测编译器会“自动处理好”更快。
此外，缩短索引意味着接受可表示范围的约束。要让优化长期成立，就应把最大规模变成显式检查，而不是留给几年后扩容时的一次溢出。
更小的环，也会带来更大的回源压力
该团队还将每台服务器生成的哈希点数量减少约九成。更容易被标题略过的是上线过程：换环会改变对象归属，旧缓存仍在那里，新请求却可能去另一台机器找它。
因此，直接把全网切换到新算法，可能同时制造大量缓存未命中。团队先让新旧环共存，再分别控制流量比例和数据中心范围，保留切回旧路径的能力。节省在旧结构最终退出后才完整兑现。
这是一种可迁移的工程方法：把内存收益和迁移期间的成本分开。改索引、改分片、改路由，都可能需要暂时增加冗余，以换取可回退的过程。不能因为最终目标是省资源，就拒绝为过渡期预留资源。
别把“少九成”当成配置建议
OC 更看重的是这套验证顺序，而不是参数值。不同业务的热门对象分布、服务器容量差异、缓存命中率都不同。均匀分配哈希空间，也不保证均匀分配真实请求量。
如果少数热点占据多数流量，增加虚拟点未必解决核心问题；如果节点数量很少，另一个系统找到的甜点也未必适用。应该先识别实际失衡的来源，再决定调整算法还是容量、热点处理和缓存策略。
关键事实
- 优化对象：Pingora Backend Router 的一致性哈希结构。
- 厂商报告：全球合计回收超过 100TB RAM。
- 改动：紧凑布局、减少哈希点、分阶段迁移。
- 开源入口：相关实现位于 Pingora 的 ketama 组件，具体版本和开关应以仓库为准。
OC 判断
林岚认为，最值得学习的是把“默认值够用了”重新变成可检验的问题。资源规模越大，小结构越值得认真算；但一个优化只有经过可观测、可回退的迁移，才算真正进入生产。
为什么重要
- 对开发者：内存布局要实测，数学假设也要和真实流量对照。
- 对企业：资源回收能释放容量，但全球累加量不能当单实例采购承诺。
- 对用户：安全迁移意味着效率改善不必伴随一次大范围缓存失效。
评论
围绕这篇文章补充信息、提出问题或分享观察。