性能指标与目标：QPS、TPS、RT、P99延迟、吞吐量、微秒级响应
各位同学，咱们今天聊点实在的。
做抢单系统，你首先得知道「好」的标准是什么。没有指标，你连自己做得烂不烂都不知道。我见过太多团队，一上来就撸代码，结果上线就被流量打趴下。嗯，今天我们就把这些指标掰开揉碎了讲清楚。
一、核心指标速览
先看一张图，这是我个人习惯用的知识框架。你把它印在脑子里，后面就好理解了。
二、逐个拆解
1. QPS（每秒查询数）
说白了，就是系统一秒钟能处理多少个请求。抢单场景下，QPS 往往瞬间飙升。我记得有一次双十一抢购，QPS 从平时的 200 直接飙到 8 万，差点把数据库打崩。
你想想看，如果 QPS 设计目标定在 10 万，那你的系统每一毫秒都要处理 100 个请求。这不是闹着玩的。
关键公式：
QPS = 总请求数 / 时间窗口（秒）
举个例子：1 秒内处理了 5000 个请求，QPS = 5000
2. TPS（每秒事务数）
TPS 和 QPS 容易搞混。我刚开始也犯过这个错。QPS 是查询，TPS 是完整的事务。抢单场景下，一次抢单包含：查询库存 → 扣减库存 → 生成订单 → 返回结果。这才算一个完整的事务。
所以 TPS 通常比 QPS 小。一个 TPS 可能对应 3-5 个 QPS。我个人习惯用 TPS 来衡量核心链路，用 QPS 来衡量整体流量。
避坑指南：我曾经见过一个团队，对外宣称 QPS 10 万，结果 TPS 只有 2000。为什么？因为他们的 QPS 算的是静态页面的访问量，根本不是抢单接口的真实吞吐。所以，一定要区分清楚你测的是哪个指标。
3. RT（响应时间）
RT 就是用户从点击「抢单」到看到结果的时间。毫秒级。100ms 以内算优秀，200ms 以内算及格，超过 500ms 用户就开始骂娘了。
为什么会这样？因为抢单是强实时场景。用户等 1 秒，黄花菜都凉了。我做过一个实验，RT 从 50ms 涨到 200ms，用户流失率直接翻倍。
RT 的组成：
- 网络传输时间（通常 1-10ms）
- 服务端处理时间（核心优化点）
- 数据库/缓存访问时间（最容易出问题）
- 排队等待时间（高并发下显著增加）
4. P99 延迟
这个指标很多人忽略，但它才是真实用户体验的照妖镜。
P99 延迟的意思是：99% 的请求都在这个时间内完成。剩下 1% 的请求，可能慢得离谱。我见过一个系统，平均 RT 只有 30ms，但 P99 延迟高达 2 秒。你想想看，每 100 个用户就有 1 个要等 2 秒，这体验能好吗？
注意：P99 延迟的优化往往比平均延迟难 10 倍。因为那 1% 的慢请求，通常是由 GC 停顿、网络抖动、资源争抢等偶发因素造成的。我曾经为了把 P99 从 500ms 降到 100ms，整整调优了两周。
5. 吞吐量
吞吐量是系统在单位时间内能处理的总工作量。可以理解为 QPS 或 TPS 的宏观版本。通常用「每秒处理订单数」或「每秒处理消息数」来衡量。
吞吐量和 RT 是跷跷板关系。你压得越狠，RT 越高。找到平衡点，才是高手。
吞吐量公式：
吞吐量 = 并发数 / 平均 RT
举个例子：并发 1000，平均 RT 50ms，吞吐量 = 1000 / 0.05 = 20000 TPS
三、微秒级响应：是神话还是现实？
好，到了最刺激的部分。微秒级响应，也就是 1 微秒（μs）到 999 微秒。1 毫秒 = 1000 微秒。也就是说，微秒级响应比毫秒级还要快 1000 倍。
说实话，在纯软件层面，做到微秒级响应非常难。为什么？因为一次内存访问大约需要 100 纳秒，一次 CPU 上下文切换需要几微秒，一次网络往返（哪怕在同机房）也要 100-500 微秒。
我的经验：我曾经在一个证券交易系统中做过微秒级优化。最终我们做到了 50 微秒以内的核心链路响应。怎么做到的？
- 全部用 C++ 编写，避免 JVM GC 停顿
- 使用共享内存代替网络通信
- CPU 绑核，避免上下文切换
- 预分配内存，零动态分配
但说实话，这种方案成本极高，一般抢单系统不需要这么极端。
微秒级响应的可行性分析
| 场景 | 可行性 | 典型方案 | 备注 |
|---|---|---|---|
| 纯内存计算 | ✅ 可行 | CPU 缓存、无锁数据结构 | 10-100 微秒 |
| 本地进程间通信 | ⚠️ 有条件 | 共享内存、Unix Socket | 100-500 微秒 |
| 同机房网络调用 | ❌ 困难 | RDMA、DPDK | 500 微秒以上 |
| 跨机房调用 | ❌ 不可能 | 光速限制 | 至少几毫秒 |
现实建议：对于 99% 的抢单系统，把目标定在 10-50 毫秒的 P99 延迟就非常优秀了。微秒级响应更多是学术追求或极端场景（高频交易、5G 核心网）的需求。不要为了追求微秒级而过度设计，导致系统复杂度爆炸。
四、如何设定你的性能目标
我个人习惯用「三阶目标法」来设定性能指标：
- 保底目标：系统能扛住峰值流量的 80%，P99 延迟不超过 500ms。这是底线，达不到就别上线。
- 优秀目标：峰值流量下 P99 延迟不超过 100ms，平均 RT 不超过 30ms。这是大多数抢单系统的合理目标。
- 极致目标：P99 延迟不超过 10ms，平均 RT 不超过 5ms。这需要大量投入，适合头部互联网公司。
记住一句话：没有目标的优化是瞎优化。先定指标，再谈方案。我见过太多团队，上来就搞 Redis、搞消息队列，结果连自己的 QPS 目标是多少都没想清楚。这是典型的「用战术上的勤奋掩盖战略上的懒惰」。
好了，这一章的内容就到这里。指标是基础，后面的章节我们会基于这些指标，一步步搭建出能扛住百万 QPS 的抢单系统。
课后思考：你的系统目前 QPS 和 P99 延迟是多少？有没有监控？如果没有，建议先搭一套监控，把数据跑出来。没有数据，一切都是空谈。