Cloudflare 用数学与 Rust 省下 100TB 内存
Saving another 100TB of RAM with math (and Rust)
在 Cloudflare 的庞大规模下，每一分资源都至关重要。我们的 Performance 团队发现，Pingora Backend Router 中的 pingora-ketama 库存在严重的内存浪费。通过深入分析 consistent hashing 算法的统计特性，我们发现单纯增加哈希点数量虽能平衡负载，却导致内存呈指数级爆炸。最终，我们利用 Rust 的内存对齐机制，将存储索引的字段从 32 位优化为 16 位，在不牺牲功能的前提下，成功在全球范围内回收了超过 100TB 的 RAM。
在这个规模下，微小的改进会被极大地放大，因此即便是百分之一的提升也值得庆祝。
HN 评论区
109- zer0x4d
看到 CF 这一系列文章，我高兴极了。以前内存和处理能力稀缺时，开发者们不得不绞尽脑汁，连最基础的功能都要精打细算才能塞进预算，我对此一直深感自豪。在我看来，自从内存和处理能力变得充裕后，大多数人就放弃了优化，转而专注于快速交付，结果导致现在即便有多核 CPU，连一个简单的记事本或音乐播放器都跑不起来。从某种意义上说，内存成本的上升开启了一个被迫优化的新时代，这让我非常欣慰。
- nopurpose
我理解对了吗？他们是在每台服务器上花费内存来存储较大的 N 个哈希值，以便通过请求哈希值，在所有服务器哈希值中选取最接近的较大值，从而决定将请求发送到哪台服务器？
这实际上等同于以概率 P 一致地选择服务器 S，其中 P 是权重和服务器总数的函数？
肯定有更好的方法可以在不存储巨大哈希查找表的情况下，以给定概率选择服务器吧？比如某种形式的 Randevouz 哈希。
- dr_dshiv
Cloudflare 真的太棒了，他们让我主要的副业项目（http://sourcelibrary.org）以我无法完全归功于自己的价格和性能成为了可能。我不在乎他们的文章是不是用 AI 写的，我只希望我的 AI 也能像这样把哈希讲得如此动听……但等等……今天我注意到 Claude 明明用个时间戳就能解决的问题，却非要尝试用哈希，现在我真的开始怀疑自己了，嗯……
- vlovich123
我会抛弃 consistent hashing 和 ketama，采用一个更好的系统，从而额外节省 600TiB。
你可以用键哈希的前 N 位来选择服务器分区，使其成为一个合理的数量（例如每个分区 128 台服务器）。然后用高质量的预计算哈希（sha256 的前 64 位）作为服务器名称的 N 值，用于 H(K + N)。使用 wyhash 中的 wymum 作为 H，这样你只需要进行 O(n) 次整数乘法，同时保留统计上依然良好的哈希结果。
现在你使用的是锦标赛哈希（tournament hash），由于 N 很小，O(N) 和 O(N log N) 的区别并不重要，而且这个 O(N) 也比他们现在每键计算 160 个哈希所消耗的 CPU 少得多，因此每个请求增加的延迟会小得多。
- Fordec
这类事情让我觉得，我们即将进入一个软件开发领域将出现大量失业的时代。你无法仅靠一次性的“ vibes coding”（凭感觉写代码）就达到这种效果。但对于真正的软件工程来说，这些岗位是安全的，因为越来越多的问题将需要通过创造性地运用数学来解决，因为个人交付的问题只会变得越来越大。人们只是在哀叹那些容易摘取的果实已经没了。
- ricardobeat
这些优化令人印象深刻，但也让我思考：一家公司在什么程度上会变成一堆无法穿透的孤岛，以至于没有任何东西能按你预期的方式工作？也许有了 AI，这个问题就不那么严重了，因为探索代码库的速度也快多了。
- agosta
很棒的文章！作为一个在日常编程任务中很少（几乎从不）用到微积分的人，我非常享受阅读 Kevin 对那个推导过程的深入探讨（补充文章中有链接）。这里所有唱反调的人，请吃葡萄干吧。
- proc0
唯一提到 Rust 的部分是关于存储改进中存储哈希的结构体，但他们真的需要那么多哈希值，以至于 2 个字节能产生这么大的差异吗？文章没有展开说明，但我猜这是每台计算机上每个任务都有一个哈希，所以也许确实是这样。