高并发研究：用 Little 定律理解在途请求

吞吐没有提高，请求数却越积越多，通常意味着系统在用排队换取更长等待。

本文使用有限容量的 Java 服务与固定输入的实验负载。性能问题需要同时看吞吐、排队、错误和延迟分布。示例数字用于演算与设计实验，不代表任何真实系统已经达到的性能成绩。

1. 从现象推到机制

稳定系统中，平均在途数量约等于到达率乘平均停留时间，单位必须一致。它描述长期平均关系，不保证突发峰值。若进入速率长期超过完成速率，系统不满足稳定前提，队列就会继续增长。

高并发研究：用 Little 定律理解在途请求的处理、反馈与观察关系

图中的四个节点分别表示进入速率、停留时间、在途数量、容量判断。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。

用每秒一百次与平均零点二秒演算在途二十次，再分别增加到达率和等待时间。数字只用于理解量纲。

L = lambda * W
example: 100 requests/second * 0.2 second = 20 requests
observe arrivals, completions, queue length together

从稳定低负载开始增加压力，分别记录进入与完成速率。固定请求数据、连接策略和观察窗口，保留错误响应；只有成功请求的平均耗时不足以代表系统体验。

下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。

平均在途数量也会增加。观察时记录相同窗口的速率与停留时间。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。

不再能当稳定系统简单套平均值。观察时记录队列长度随时间的趋势。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。

平均关系不能替代峰值容量。观察时记录短窗口峰值与排队上限。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。

在途请求包括排队和执行，不应只统计工作线程。容量规划还需给突发、故障和请求差异留出余量。

一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“瞬间出现流量尖峰”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。