流量的语言：QPS、RT 与并发数的三角关系
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 0 · 度量与估算 · 第 1/49 篇 · 🚧 占位待学
上一篇：《QPS 过万与亿级消息系统设计学习总纲》
下一篇：《从日活到机器数：容量估算的草稿纸算法》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 0 · 单元 0.1
一、本文要解决的问题
「QPS 过万」到底是多大的压力？一个接口说它平均响应 50ms，用户为什么还在骂卡？不建立三个核心指标的量化直觉，后面一切架构讨论都是空谈——你连「系统现在扛了多少、还能扛多少」都读不出来。
二、知识点清单
- QPS / TPS / RT / 并发数四个指标各自的白话含义与单位
- Little 定律 L = λW：并发数 = 到达率 × 平均等待时间，一条公式串起三者
- 平均值的陷阱：P90 / P99 / P999 分位数为什么才是用户体感
- IO 密集型与 CPU 密集型负载的判别，及它们对单机极限的巨大差异
- 峰值 QPS 与日均 QPS：为什么容量永远按峰值算
三、动手实验（学习时必须真跑）
- 写一个最简 Spring Boot 接口（内存计算 + 一次 MySQL 查询两个版本），部署在 WSL
- 用 wrk 以并发 10 / 50 / 100 / 200 四档阶梯压测，每档记录 QPS、平均 RT、P99 RT
- 把四档数据代入 Little 定律验证：并发数 ≈ QPS × RT，观察误差来源
- 观察并记录：并发翻倍时 RT 与 QPS 各自怎么变，找到 RT 开始恶化的拐点
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。