1.1 高并发的本质与核心指标

1.1 高并发的本质与核心指标

本节摘要：高并发不是一个“高”字能概括的，它得用一组指标来量化。本节讲清五个核心指标——QPS（每秒请求数）、RT（响应时间）、吞吐量、错误率、可用性——它们各自的含义，以及最关键的：它们之间相互制约。想提吞吐往往牺牲延迟，想压低错误率往往得降并发。理解这套制约关系，你才能为自己的系统定合理的并发目标，而不是盲目追高 QPS。

学习目标

阅读完本节，你应当能够：

1. 准确说出 QPS、RT、吞吐量、错误率、可用性的定义和计量方式
2. 解释吞吐量和延迟之间的制约关系（Little's Law）
3. 区分平均 RT、P95、P99 等延迟统计指标的差别和适用场景
4. 说清为什么“追高 QPS”是错误的目标设定方式
5. 为一个具体系统设定合理的并发能力目标

一、问题与直觉

问一个团队“你们的系统能扛多少并发”，答案常常是“QPS 能到几万”。这个回答里藏着一个危险的简化——把“高并发”等同于“高 QPS”。

QPS（Queries Per Second，每秒请求数）确实是衡量系统处理能力的核心指标，但单独看它没意义。一个系统能扛 5 万 QPS，但响应时间 5 秒、错误率 10%，这算“能扛”吗？显然不算——用户体验极差，请求一大半失败。真正有意义的问题不是“能到多少 QPS”，而是“在可接受的响应时间和错误率下，能到多少 QPS”。

这就是高并发的本质：它不是单一指标的拉高，而是一组相互制约指标的平衡。你要在吞吐量（QPS/吞吐）、延迟（RT）、可靠性（错误率/可用性）、成本之间找平衡点。想提任何一个，往往得牺牲另一个。理解这套制约关系，是设计高并发系统的起点。

二、核心原理

2.1 五个核心指标

先把五个核心指标的定义和计量方式讲准。

QPS（每秒请求数）：单位时间内系统处理的请求数量。它衡量系统的处理能力上限。类似的还有 TPS（每秒事务数），区别在于“事务”可能包含多个请求。日常说并发能力，多数指 QPS。

RT（响应时间）：一个请求从发出到收到响应的耗时。它衡量用户感受到的速度。RT 不能只看平均值，还要看分位数——P95（95% 的请求在多少毫秒内完成）、P99。因为平均值会被少数极慢请求拉高，掩盖大多数用户的真实体验。看 P99 才知道最倒霉的那 1% 用户体验多差。

吞吐量（Throughput）：单位时间内系统处理的数据量或工作量。在接口语境下，吞吐量常和 QPS 混用；在数据层语境下，吞吐量指每秒读写的数据量（MB/s）。它衡量系统的“产能”。

错误率：失败的请求占总请求的比例。它衡量系统的可靠性。高并发下错误率往往上升，因为资源竞争、超时、依赖故障都会导致失败。

可用性：系统正常运行时间占总时间的比例，常用几个 9 衡量（99.9%、99.99%）。它衡量系统的整体稳定性。可用性和错误率相关但不等同——可用性看的是“能不能用”，错误率看的是“用得好不好”。

2.2 指标之间的制约关系

这五个指标不是独立的，它们相互制约。理解制约，才知道为什么不能盲目追高 QPS。

吞吐量与延迟的制约。这是最经典的一对矛盾。系统负载低时，加并发吞吐量上升、延迟基本不变；但负载接近系统极限时，再加并发，吞吐量提升很小，延迟却急剧上升。原因是资源（CPU、锁、连接）开始竞争，请求排队等资源的时间暴涨。这个关系可以用 Little's Law（利特尔法则）描述：系统里的平均请求数 = 到达速率 × 平均响应时间。当请求数逼近资源上限，排队效应让 RT 指数级增长。

并发与错误率的制约。并发超过系统能力，资源耗尽（连接池打满、内存溢出、超时），失败请求增多，错误率上升。想压低错误率，就得限流，主动拒绝超出能力的请求——这就牺牲了一部分并发量。

可用性与成本的制约。想提高可用性（从三个 9 到四个 9），要做冗余、容灾、多活，成本成倍上升。每多一个 9，投入往往翻几倍。

2.3 延迟分位数：别被平均值骗了

RT 这个指标，最容易踩的坑是只看平均值。平均 RT 100 毫秒听起来不错，但可能藏着这样的分布：80% 的请求 50 毫秒，20% 的请求 300 毫秒。那 20% 的用户体验很差，但平均值把问题掩盖了。

所以高并发系统看延迟，要看分位数：P50（中位数）、P95、P99、P999。P50 反映大多数人的体验，P95 反映多数人的下限，P99 反映长尾用户的体验。对一个面向消费者的系统，P99 往往比平均值更重要——因为一个用户一次会话发几十个请求，只要有一个落在 P99 那段，体验就卡顿。

三、工程实践要点

3.1 设定合理目标：先定 SLO 再谈并发

做高并发，第一步不是想办法提性能，而是想清楚目标是什么。这个目标要用 SLO（Service Level Objective，服务等级目标）来表达，比如“P99 RT 不超过 200 毫秒，错误率不超过 0.1%，可用性 99.95%”。

有了 SLO，才有判断标准：当前系统能不能在满足 SLO 的前提下扛住目标 QPS？瓶颈在哪一层？哪个手段能缓解？没有 SLO，优化就是无的放矢，团队会在“还能不能再快一点”里无限打转。

⚠️ 常见坑：没有明确的 SLO，拍脑袋定“QPS 越高越好”。结果团队盲目优化，把 P99 RT 从 200 毫秒压到 50 毫秒，但用户根本感知不到（人眼对 200 毫秒以内的差异不敏感），投入的资源本该用在别的地方。先定 SLO，再按 SLO 的短板优化。

3.2 吞吐量优先 vs 延迟优先

不同系统对指标的取舍不同。吞吐量优先的系统（如批处理、日志收集、大数据计算），更看重单位时间处理总量，对单次延迟容忍度高。延迟优先的系统（如在线交易、搜索、实时推荐），更看重单次响应快，宁可吞吐量低也要保延迟。

设计时要先判断自己的系统属于哪类，然后按类取舍。把延迟优先的系统按吞吐量优先来设计（比如为了多处理而堆积请求），会导致延迟雪崩；反过来，把吞吐量优先的系统按延迟优先来设计（为了快而拒绝排队），会浪费产能。

3.3 用指标定位瓶颈

系统在高并发下出问题，第一步是定位瓶颈在哪一层。方法是看指标在不同负载下的变化：如果 CPU 打满但 RT 没暴涨，瓶颈在计算；如果 RT 暴涨但 CPU 不忙，瓶颈在等待（锁、IO、网络）；如果错误率突升，多半是资源耗尽或依赖故障。带着指标去定位，比凭感觉猜准得多。

💡 关键直觉：高并发的目标不是把某个指标拉到最高，而是让一组指标在你设定的 SLO 内达成平衡。能说清“我的系统在 P99 小于 200 毫秒、错误率小于 0.1% 的约束下，能稳定扛 3 万 QPS”，比说“我能扛 10 万 QPS”专业得多——前者是工程师的语言，后者是营销话术。

收获清单

• 五个核心指标：QPS（处理能力）、RT（用户体验）、吞吐量（产能）、错误率（可靠性）、可用性（稳定性）。
• 指标制约：吞吐量与延迟、并发与错误率、可用性与成本，相互制约，不能既要又要。
• Little's Law：负载接近极限时，再加并发吞吐量微升但延迟暴涨，排队效应是主因。
• 延迟分位数：别被平均值骗，要看 P95、P99，长尾体验才是质量底线。
• 先定 SLO：用服务等级目标约束优化方向，别盲目追高 QPS。
• 两类系统：吞吐量优先和延迟优先，设计取向不同，别用错框架。

下一节我们顺着时间线，看高并发方案是怎么从“加机器”一步步进化到今天的智能流量治理的。

指标之外：三个容易误读的统计口径

教科书讲 QPS、RT、并发数，但线上排障时真正拉开差距的是对统计口径的理解，这里补三个高频误读。第一是分位数的时间聚合陷阱：监控系统每三十秒输出一个 P99，一天的 P99 是这些值的聚合，而聚合方式（平均还是取最大）不同，结论能差一倍——"日 P99"必须说清是怎么算出来的，否则跨团队对数永远对不齐。第二是并发数的定义歧义：说的是同时在线连接数、正在处理的请求数、还是线程池占用数，三个数字能差一个数量级，容量评审会上先统一口径再谈数字。第三是成功率的遮蔽效应：总量大时，万分之一的全量失败里可能藏着某类用户的百分之百失败，按接口维度统计的成功率好看，按用户维度一拆就露馅。高并发系统的指标体系要有"下钻能力"：每个总量指标都能按用户、渠道、机房、版本四个维度切开，否则你看到的是被平均后的幻象。

顺带一个实践建议：给核心接口建"分位时间序列"的习惯——把每天同一高峰时段的 P50、P90、P99 抽出来画趋势，比看实时大盘更容易发现性能的缓慢劣化。慢查询多一条、缓存命中率掉两个点，这类渐进退化在实时告警里都不够阈值，在月度趋势里却一目了然。容量规划的数据基础就是这些趋势线，而不是某一天的峰值快照。

再补一个建立量级直觉的练习方法：拿自己系统的峰值流量做一套换算。假设峰值五千 QPS、平均响应四十毫秒，先算稳态并发（约两百），再算极端情况下的线程池需求、数据库连接需求、缓存命中率的容忍下限，最后和实际配置对照。多数人第一次做这个练习都会发现配置和推导的偏差——要么资源浪费三倍，要么余量薄如纸。把这套换算做成团队的容量估算模板，新服务上线前过一遍，量级直觉就在一次次对照中长出来了。

关于指标告警阈值再补一个分层技巧：把阈值分为"容量水位线"和"行为异常线"两类分开维护。容量线看资源利用率，百分之六十黄、八十红，触发的是扩容流程；行为线看业务指标，错误率、P99 突变、交易量同比异常，触发的是排障流程。两类混在一张表里，值班的人拿到告警先要判断类型，浪费黄金处置时间——分开维护、分开路由，处置路径各自直达，这是看板设计里低成本高回报的改进。