Cloudflare 的运营规模如此之大，以至于即使在这里工作了多年，也让人觉得不太真实。我们在全球拥有数千台服务器，配备 PB 级的内存和数百万个 CPU 核心，而所有这些资源都被推到了极限。尽管这些资源感觉非常庞大，但它们仍然是有限的，当你需要每个服务在每个节点上运行时，就没有浪费空间的余地。在这种规模下，微小的改进会被极大地放大，因此即使是每次 1% 的改进也值得庆祝。而有些调整加起来效果要大得多：在这篇文章中，我们将探讨对单个算法的小改动如何显著减少我们某个基于 Pingora 的服务的内存占用。这使我们能够在全球范围内回收超过 100TB 的 RAM，这还不包括 DNS 团队上个月释放的 100TB 内存。

杜绝浪费 在团队之间维持公平的资源共享并不容易，尤其是在大型组织中。Cloudflare 确保平衡得以维持的方式之一，是通过出色的 Performance 团队的不懈努力。这个故事始于 Ivan 提交的一张工单，他发现：Pingora Backend Router 中 pingora-ketama 的内存使用过多。这一发现是，我们的内部负载均衡服务 Pingora Backend Router（没错，就是 PBR）使用的内存远超预期——特别是在与 pingora-ketama 相关的结构中，这是我们用于处理一致性哈希的开源库。为了讨论我们如何解决这种看似过度的内存使用，我们需要谈谈一致性哈希到底是什么、我们为什么在 PBR 中使用它，以及它如何变得如此耗内存。在此过程中，我们将学习一些 Rust，甚至一点数学。

一致性哈希 一致性哈希是一种广泛使用的方法，用于在多个服务器之间分配任务，并且在添加或移除服务器时不需要大规模更改。在内部，我们用它按 URL 将可缓存的请求路由到服务器。这使我们能够在每个数据中心只保留一份文件副本，并提供一种稳定的方式来查找每个文件的位置。我们之前提到过这个系统，但让我们花点时间详细讲解这个算法的使用方式和原因，以及它是如何工作的。一致性哈希的关键概念是，虽然哈希函数可以接受任何类型的输入，但它们的输出仅限于一个无符号整数（根据所使用的哈希函数，可以是 32、64 或 128 位整数）。这使我们能够以一致的方式将任务和服务器相互关联。大多数关于一致性哈希的讨论都会让你把那个输出空间想象成一个连续的、循环的环，从最大值回绕到零。这种描绘可以做出一些漂亮的视觉化效果，但它也可能让整数范围这个简单的概念显得比实际需要的更复杂。在我们的讨论中，我们将把哈希函数的 32 位输出表示为一条数轴。现在，假设我们有一组服务器 A、B 和 C，以及一组任务 t-z。我们可以根据它们代表值的哈希将它们映射到数轴上，比如服务器的 IP 地址和任务的缓存键。将任务分配给服务器现在只需找到每个任务左侧的第一个服务器。我们可以通过为每个服务器关联的哈希区域着色来直观地表示这一点。请注意，服务器 C 覆盖的范围回绕到了开头，因此有了哈希存在于一个环上的想法。就是这样。在基本层面上，一致性哈希就是这么简单——但用不了多久就会发现还有改进的空间。请注意，在我们的示例中，服务器 A 覆盖的范围明显大于 B 或 C 的范围。这是一个问题，因为服务器处理的请求比例将与其在数轴上的范围大小成正比。理想情况下，我们希望保证每个服务器都有相同的大小，但由于哈希本质上是随机数，我们不得不……