利特尔法则计算器

利特尔法则（Little's Law，1961）：系统中平均请求数 L = 到达率 λ × 平均逗留时间 W。它不假设任何分布——泊松到达、任意服务时间、任意队列结构都成立，这种普适性在排队论中绝无仅有。工程翻译：并发数 = QPS × 平均响应时间。100 QPS × 0.5s = 50 并发——你的服务任意时刻在同时处理 50 个请求，这就是线程池/连接池/协程数的下限。

法则的三个实战推论：① 响应时间恶化时并发自动膨胀（同样的 100 QPS，RT 涨到 2 秒并发就变 200）——这就是为什么慢查询会拖垮线程池；② 容量上限可用 L 反推：线程池 200 上限 ÷ RT 0.5s = 系统理论极限 400 QPS；③ 全链路串联相乘：网关（5ms）→ 应用（45ms）→ DB（5ms），应用层的并发占用是网关的 9 倍——逐层用法则，找到并发压力最大的环节。注意尾延迟效应：平均 RT 骗人，P99 RT 时的并发才是池子要扛的真实峰值。

法则成立只需两个宽松条件：系统长期稳定（没有持续的堆积或排空趋势）、请求守恒（来的都会处理完离开）。它不关心到达是泊松还是突发、服务时间是均匀还是长尾、队列是单线还是并行——因为它本质上是「对足够长时间窗口做平均」的恒等式，而非概率模型。反例只有一个：系统已经崩了（请求无限堆积），这时 L 发散，法则用它自己的方式告诉你系统死了。

尾延迟放大是工程上最容易踩的坑：响应时间常呈对数正态分布，P99 通常是平均值的 3–5 倍。按平均 RT 配池子，等于按晴天设计屋顶——1% 的慢请求时段（缓存失效、GC、慢查询）里并发需求瞬间放大数倍，池子打满后健康请求也开始排队，时延进一步恶化，正反馈形成雪崩。所以容量口径必须用 P99 甚至 P999 的 W 来算 L。

三层池子要配套计算：应用线程池（Tomcat/Netty worker）、数据库连接池（HikariCP）、以及它们之间的等待队列。常见错误是把线程池开到 500、连接池只给 20——200 QPS 的请求全堵在等连接上，线程空转。正确顺序是逐层用法则：每层自己的 λ × 自己的 W，瓶颈层的 L 决定全局。结合 QPS 估算计算器 先定 λ，再逐层配池。

限流与背压的设计也由法则导出：池满之后的请求去哪里？队列长度上限 = 允许排队数 = λ × 可容忍的额外等待时间——超过即快速拒绝（fail fast），而不是让请求无限排队直到超时。快速拒绝看似残忍，实则保护系统：被拒的请求立刻得到错误可重试，排队的请求拖慢了所有人。排队等待时间计算器 可以量化等待队列的时延代价。

观测侧的高阶用法是交叉验证：监控同时给你 QPS（λ）、响应时间（W）与并发数（L）三个指标，任意时刻算 λ×W 与实测 L 对账——对不上说明指标口径错了（比如 W 只统计了成功请求，漏掉了超时请求）。这个恒等式是分布式追踪与 APM 系统的底层校验器，也是让监控数据「自洽」的最快体检。