解读

1. 场景还原：国内互联网面试常把“并发用户”与“在线用户”混用，此处 5 k 指“同时发起请求、对系统产生压力的用户数”，而非单纯登录态。
2. 指标口径：RT 200 ms 是端到端平均响应时间，含网络、网关、应用、DB；TPS 是系统每秒能完成的事务数，通常按 95% 成功率折算。
3. Little 定律本质：稳态系统“系统中的请求数 = 到达率 × 平均停留时间”，单位必须对齐（秒）。
4. 陷阱提示：若直接 5000 ÷ 0.2 = 25 000 会被追问“并发用户是否等于系统内请求数”，需说明“用户 Think Time 已视为 0，即长连接/持压模型”。

知识点

• Little 定律：L = λ × W
  L：系统内并发请求数（单位 个）
  λ：到达率即 TPS（单位 个/秒）
  W：平均停留时间即 RT（单位 秒）
• 持压模型：压测线程（虚拟用户）在收到响应后立即发送下一请求，无 Think Time，此时“并发用户”≈“系统内同时处理的请求数”。
• 单位换算：200 ms = 0.2 s；1 s 内要完成 λ 个事务，则 λ = L / W。
• SLA 反向推导：若业务要求峰值 5 k 并发且 RT 不超 200 ms，则系统必须提供 ≥ 25 k TPS 的容量，否则队列会堆积，RT 被拉长。
• 经验系数：国内大厂面试常让候选人留 20% 余量，回答 25 k TPS 后补一句“线上按 1.2 倍冗余，目标 30 k TPS”可加分。

答案

在持压模型下，并发用户 5 k 全部处于“等待响应”状态，即系统内同时有 5 k 个请求。
根据 Little 定律：
λ = L / W = 5000 / 0.2 = 25 000 TPS
因此，系统需稳定输出 25 000 TPS；考虑国内峰值冗余 20%，建议目标值设定为 30 000 TPS。

拓展思考

1. 若真实场景存在 3 s Think Time，则并发用户 5 k 时系统内平均请求数 L = 5000 × 0.2 / (0.2 + 3) ≈ 312，所需 TPS 仅 312/0.2 ≈ 1 560，面试需先问清模型。
2. 当 RT 由于瓶颈涨到 400 ms，同样 25 k TPS 会导致 L = 25 000 × 0.4 = 10 k，线程池/连接池瞬间打满，触发雪崩，面试可借此引出“线程池隔离、限流、降级”三板斧。
3. Little 定律同样用于容量规划：若业务预估日活 1 千万，峰值 QPS 按“二八法则”折算为 6 万，目标 RT 100 ms，则系统内并发请求 L = 6 万 × 0.1 = 6 k，可反向评估连接池、队列长度与缓存命中率的设计下限。