奇普夫定律 (Zipf's Law)

AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

你以为你只是在写代码。

设计 API。扩展系统。在凌晨 2 点调试奇怪的边缘情况。

但在所有这些逻辑之下，隐藏着一个奇怪的模式。一个在计算机存在之前很久就被发现的模式。不知何故，它不断出现在我们构建的一切中。

它叫做齐普夫定律。

说实话，它感觉像是现实中的一段故障。

齐普夫定律说了一件非常简单但非常奇怪的事情。在几乎任何数据集中，第二常见的项目出现频率大约是第一项的一半。第三项大约是三分之一。第四项，四分之一。

这听起来太整齐了，不像是真的。

但它是。

1、一个完美得不真实的快速例子

拿《哈利·波特》这样的书来说。

如果你统计词频，"the"主宰一切。然后"and"出现的频率大约是一半。然后是"to"。然后是"of"。

不是精确的，但足够接近让你感到不安。

现在拉远看。

城市人口遵循这个模式。最大的城市大约是第二大城市规模的两倍。网站流量也是如此。少数页面获得了大部分访问量。大多数页面几乎没有访问量。

甚至连你的代码库也不例外。

有些函数被调用得非常频繁。其他函数存在但几乎不被触及。少数端点承载了你后端的大部分负载。

你不是这样设计的。

它就是……自然而然地发生了。

2、你后端系统中的幽灵

想想你上一个项目。

可能有几个 API 承担了大部分繁重工作。也许是一个登录端点、一个信息流端点、一个搜索端点。其余的都是次要的。

你的数据库查询也遵循同样的故事。一小部分查询主导了流量。其余的很少被使用。

甚至日志也是如此。少数类型的事件不断重复，而其他事件偶尔出现一次然后永远消失。

它不是均匀分布的。它从来都不是。

而这正是齐普夫定律所预测的。

这有点令人不安，因为没有人告诉你的系统要这样运行。

3、为什么这实际上很重要

这不仅仅是一个有趣的观察。

它直接影响我们如何构建软件。

缓存之所以有效，正是因为齐普夫定律。如果少数请求主导了流量，缓存它们会带来巨大的收益。如果所有请求的可能性都相同，缓存的帮助微乎其微。

数据库索引基本上是对这种模式的承认。你为频繁查询而非所有查询进行优化。

负载均衡、CDN 策略，甚至限流决策都受到使用量不均匀分布这一事实的影响。

我们没有明确说出来，但我们一直在为不平衡进行设计。

也许我们应该更经常地承认这一点。

4、没有人完全理解的部分

这里事情变得有点令人不安。

没有人真正知道为什么齐普夫定律到处出现。

一种解释是最省力原则。人类重复那些容易的事情。我们复用词语，重新访问熟悉的应用，遵循习惯。随着时间的推移，这创造了一个倾斜的分布。

另一种解释是系统朝着效率方向进化。活动不是均匀分布的，而是集中在最有效的事情上。

但这仍然不能完全解释它。

为什么相同的模式出现在语言、互联网流量、城市规模，甚至生物学中

它感觉太一致了，不像是随机的。

几乎就像系统从一开始就被设计好了。

5、这对你作为程序员意味着什么

一旦你注意到这个模式，你的思维方式会发生一些变化。

你停止假设均匀的行为。

你停止尝试平等地优化一切。

取而代之，你开始问更好的问题。

哪些端点最重要 哪些查询真正驱动负载 哪些用户行为主导实际使用

因为事实是，大多数事物不是同等重要的。

假设它们同等重要来设计是在浪费精力。

这就是很多性能提升的真正来源。不是花哨的算法，而是简单地将注意力集中在不成比例地重要的部分上。

6、一个稍微令人不安的领悟

这里有一点花了我很长时间才接受。

我们所谓的系统设计，不完全是关于控制。

它是关于对齐的。

我们并不总是在创造模式。有时我们只是在发现它们并围绕它们进行调整。

齐普夫定律就是这些模式之一。

它在我们之前很久就已经存在了。它可能会比我们构建的大多数系统更持久。

而我们只是……在围绕它工作。

7、试一次

下次当你查看日志、分析数据或甚至代码使用指标时，做一件简单的事情。

按频率对项目进行排序。

观察曲线下降的速度有多快。

它不会完美干净，但你会看到的。

同样的模式。

一旦你注意到了它，它就会伴随着你。

你开始到处看到它。

甚至在你希望没有的地方。

原文链接：Why Every Programmer is Unknowingly Following a Rule From 1935: The Zipf Mystery

汇智网翻译整理，转载请标明出处