📘 性能与负载 入门名词描述

“没有解决方案，只有利弊权衡。尽你所能获取最好的利弊权衡，这是你唯一能指望的事。” ——《DDIA》

🧩 一、什么是负载（Load）

📌 定义

负载 = 系统正在承受的压力，可以通过多个维度的指标来描述。

• 用途：监控系统瓶颈 / 评估是否需要扩容 / 优化调度资源

🧮 常见负载指标

类型 指标 描述

Web 服务 QPS（每秒请求数） 测量并发请求处理能力

数据库 TPS（每秒事务数） 事务处理能力，包括多步 SQL 操作

内存 已用内存 / 可用内存 / 使用率 判断内存是否吃紧

Linux 系统 Load Average（1/5/15分钟） 平均运行队列长度，不是 CPU 使用率

📌 系统负载 != CPU 使用率！

LoadAvg 是“等待 CPU 调度的进程数（Runnable + Running）”

🔢 一、QPS 和 TPS 的区别与联系

🧠 基本定义

指标 全称 含义 应用场景

QPS Queries Per Second 每秒处理的查询请求数 Web 服务、接口调用

TPS Transactions Per Second 每秒处理的完整事务数 数据库、支付、下单等事务性服务

📌 举例区分

场景1：Web 服务

一个电商网站：

• 每秒收到 10000 个用户请求
• 都是类似 GET /product/123

✅ 这里就是 QPS = 10000（高并发读请求）

场景2：数据库服务

一个用户下单流程：

• 下单接口执行 1 次
• 这个接口背后执行了 5 条 SQL（查库存、扣库存、写订单、写流水、写用户操作）

✅ 一个“下单事务” = 多个 SQL 查询

所以：

• QPS（N * TPS） = 5000

• TPS（下单事务数） = 1000

✅ 总结区别

项目 QPS TPS

粒度 单个查询（如 SQL 或接口） 一个完整事务（可包含多个操作）

描述 并发处理能力 原子操作能力

场景 Web 接口、Redis、MySQL 查询 支付系统、订单、银行交易

📌 TPS 更适合描述事务系统的处理能力（如支付、订单），QPS 更常用于接口服务和缓存系统。

📊 二、P99 / P999 / P95 的含义

📌 定义：百分位响应时间指标（Percentiles）

用来描述 延迟 / 响应时间的分布情况，比平均值更能反映“极端情况”。

例如：P99 就是第 99% 个请求所用的耗时。假如 P99 现在是 10ms, 那么我们可以说 “99% 的请求都在 10ms 内完成”。虽然在一些请求量较小的情况下，P99 可能受长尾请求的影响。但是由于 SRE 一般不会给在量小的业务上花费太多精力，所以这个问题并不是很大。

指标 含义

P50 中位数：一半请求耗时比它低，一半比它高

P95 95% 的请求响应时间 ≤ 该值

P99 99% 的请求响应时间 ≤ 该值

P999 99.9% 的请求响应时间 ≤ 该值（极端尾部响应）

🔍 举例说明

假设你统计了 10000 个请求响应时间：

• P50 = 100ms → 有 5000 个请求耗时 ≤ 100ms
• P95 = 200ms → 有 9500 个请求耗时 ≤ 200ms
• P99 = 500ms → 有 9900 个请求耗时 ≤ 500ms
• P999 = 1000ms → 有 9990 个请求耗时 ≤ 1000ms，只有 10 个 > 1000ms

🚨 为什么不用平均值（Average）？

平均值会被“极端慢请求”影响，看不出长尾风险。

• 示例数据：[50ms, 60ms, 55ms, 12000ms]
• 平均值 = 3025ms ❌ → 完全不符合大多数请求的真实情况
• P95 = 60ms ✅ → 95% 都非常快
• 只有极个别请求“拖后腿”，这才是你要关注的 P99 / P999

🧯 实战意义

百分位 用途 关注点

P50 系统常态表现 用户平均体验

P95 看临近瓶颈前状态 高峰期参考

P99 / P999 尾部请求监控 长尾、慢查询、GC、队头阻塞

✅ 总结一图流

|------P50---------P95-------P99-----------P999----------->
|     常规请求      稍慢       慢请求         极慢请求
|     快速路径      网络抖动    GC/锁/IO      超长队列阻塞

📎 最佳实践建议

类别 建议

接口监控 一定要记录：P50 / P95 / P99 / 最大响应时间

Web 服务 用 QPS + P99 评估稳定性

数据库 用 TPS + P99 评估峰值事务处理能力

SLA 一般要求 “P99 ≤ 100ms，99.9% 可用”

压测 用 P95/P99 判断系统“压力临界点”

⚙️ 二、如何描述性能（Performance）

📌 定义

性能 = 在当前负载下，系统的响应能力 + 资源利用率

性能指标帮助我们量化“服务好不好用”。

🚀 1. 吞吐量（Throughput）

• 定义：单位时间系统处理请求数（QPS / TPS）
• 关注点：系统最大处理能力

📌 适用场景：

场景 吞吐量指标

Web 服务 QPS

数据库事务 TPS

消息队列 / 日志系统 每秒写入记录数

⏱️ 2. 延迟与响应时间（Latency / Response Time）

📌 基本概念

项目 含义

延迟（Latency） 请求在服务端被处理的时间

响应时间（Response Time） 客户端看到的总耗时 = 延迟 + 排队时间 + 网络时间

🚨 延迟来源

• 服务处理时间慢（业务慢 / 下游慢）
• 排队等待（连接池满、线程池打满）
• 网络波动（RTT抖动、丢包）
• GC 暂停（STW）
• I/O 磁盘写慢

📊 延迟度量方式

• 平均值：容易被极端值掩盖 ❌
• P99、P95、P50（中位数）：反映不同程度的请求耗时 ✅

🏷️ 举例：

• P99 = 120ms → 说明 99% 的请求小于 120ms，1% 的请求 ≥ 120ms

⚠️ 注意“长尾延迟”：

• 慢请求集中影响系统
• 队头阻塞：有限线程并行，长请求拖慢短请求

🤝 SLA 与 SLO

项目 含义

SLA 服务级别协议（企业间签订）Service Level Agreement 服务水平协议

SLO 服务级别目标（内部制定） Service Level Object 服务水平目标

SLI 服务级别指标（如 P99 ≤ 100ms）Service Level Indicator 服务水平指示器

常见 SLA 示例：

• 可用性 ≥ 99.9%（月宕机时间 ≤ 43.2分钟）
• P99 响应时间 ≤ 100ms
• 恢复时间 ≤ 5 分钟

🔗 三、指标关系与公式

🔁 三者关系公式

平均并发数 ≈ 吞吐量 × 平均响应时间

📌 举例：

• 每秒处理 1000 请求（QPS）
• 平均响应时间 200ms = 0.2 秒
• 平均并发 ≈ 1000 × 0.2 = 200

🔧 四、排查与调优实战

🧐 问题排查流程

❓ 高并发场景下系统响应慢，但 CPU/内存正常，该怎么查？

1. 判断症状：

• 是所有接口慢？还是某类请求？
• 是平均响应时间升高，还是 P99/P95 升高？

2. 排查方向：

排查项 举例说明

下游慢 SQL 慢查询、Redis 超时、外部 HTTP 慢

排队阻塞 DB连接池耗尽、线程池阻塞、异步队列积压

热点锁竞争 同步锁 / Redis分布式锁导致串行化

网络问题 跨区调用 / 网络抖动 / DNS 延迟

GC 抖动 Full GC 频繁，或 STW 超长

3. 辅助工具：

工具 功能

链路追踪 (Jaeger / Skywalking) 查看请求耗时分布

pprof(go) / arthas 查看线程 / 堆栈 / 锁竞争状态

Prometheus / Grafana 可视化吞吐、延迟、内存等指标

🏗️ 五、系统设计视角下的性能保障

🎯 设计高并发、高吞吐接口的原则

📦 拆分架构

• 读写分离 / 拆服务 / 拆库分表 / 分区分片

⚡ 缓存加速

• Caffeine / Redis / 本地缓存
• 防穿透 / 击穿 / 雪崩处理

💥 限流降级

• 漏桶 / 令牌桶 / Sentinel
• 接口降级默认返回 / 超时熔断

🔁 异步削峰

• 消息队列缓冲（Kafka / RocketMQ）
• 支付下单先入队，后续异步处理

🧰 并发控制

• 增大连接池 / goroutine 控制
• 避免请求堆积 / 调整队列大小

📚 六、术语速查表

名词 含义

QPS 每秒请求数（Query Per Second）

TPS 每秒事务数（Transaction Per Second）

P99 99% 请求响应时间

SLA 服务等级协议

SLO 服务等级目标

SLI 服务等级指标

并发数 系统同时处理的请求数

吞吐量 每秒可处理多少请求

响应时间 请求从发起到返回的总耗时

延迟 服务端处理请求所耗时间

📖 推荐读物

• 《Designing Data-Intensive Applications》📘 DDIA
• 《系统性能：企业与云计算视角》Brendan Gregg
• 《Site Reliability Engineering》SRE 团队指南

✅ 总结与建议

• 性能问题没有绝对值，关键在于定位瓶颈、合理权衡资源与用户体验
• 学会用指标说话，从数据中发现性能问题根因
• 把握三个核心维度：吞吐、延迟、并发
• 面试/实战场景中注重：性能压测 + 调优措施 + 架构设计能力