利特尔定律（Little's law）是一个令人震惊的方程式，它非常简单，但它可以为你的分布式系统的能力带来惊人的洞察力。
举例：首先，假设我们去一个杂货店。想象一下，有一个店员，平均在四分钟内处理一个顾客。很明显，他可以提供服务：60分钟除以4--每小时15个顾客。这是可持续的到达率。如果为一个顾客服务需要三分钟而不是四分钟，那么数学就很简单了。六十分钟除以三。这使得每小时有二十名顾客。正如你所看到的，店员处理顾客的速度越快，他或她在给定的时间单位内能处理的顾客就越多。
但如果我们增加第二个店员呢？我们假设他或她有同等的吞吐量，以服务一个顾客的平均时间来衡量。我们系统的吞吐量突然增加了一倍。这还是在假设店员之间是独立的。他们之间不需要同步。同时，也没有共享的资源需要他们去等待。每个店员都有自己的登记簿。因此，不再是每小时20个顾客，而是每小时40个顾客。你可能可以猜到，增加第三个店员也会增加商店的吞吐量。应该很容易算出，总体吞吐量等于一个店员的吞吐量乘以店员的数量。在上述假设下。
信不信由你，这就是利特尔/李特定律的全部光辉。利特尔定律本质上是说，我们每小时能服务的顾客数量与办事员的数量成正比。但它也与平均处理时间成反比。为一个顾客服务的时间越长，我们得到的吞吐量就越少。工作人员的数量除以平均交易时间。这就是了!
让我们回到分布式系统和IT。在我们的行业中，我们可以通过用CPU/服务器/线程/程序取代办事员来使用李特定律。我们不用衡量完成结账的时间，而是用交易或请求-响应时间。在所有这些情况下，真正令人惊讶的是，这些是唯一的依赖关系。例如这一定律不受响应时间分布的影响（如常数与正常数与指数数）。它也不受客户到达率分布的影响。在一个稳定的系统中，即使我们只知道平均数，它也是有效的。我们所需要的是每秒平均请求数、平均响应时间和吞吐量。知道了其中两个，我们就可以计算出第三个。
让我们举一个具体的例子。想象一下，处理CPU密集型请求的Node.js服务器。Node.js是著名的单线程，所以如果一个请求需要你的CPU 100毫秒，我们每秒最多可以有效地处理十个请求。然而，如果我们在负载平衡器后面部署四个Node.js服务器，我们的理论吞吐量就会增长到每秒40个请求。另一方面，让我们来看看老式的Tomcat服务器，默认配置了100个工作线程。如果一个交易是IO绑定的，平均需要100毫秒，那么这个Tomcat实例每秒可以提供1000个请求。注意我说的是IO-bound。如果这个Tomcat实例上的事务是受CPU约束的，我们就使用可用的CPU核心数，而不是线程数来计算。
利特尔定律的神奇之处在于很多原因。首先，它允许你在对系统内部知之甚少的情况下估算出系统的理论最大吞吐量。你只需要知道你的瓶颈是什么（服务器、CPU、数据库连接），或者反过来说，你需要多少资源来维持给定的流量，在你的SLA中列出。如果你考虑到它是多么的简单，那就更令人吃惊了。无论传入请求的分布如何，无论你是否有随机的GC暂停，等等，它都能发挥作用。你只需在平均数上下功夫。