一、性能优化概述：目标、指标与方法论
大家好，我是你们的老朋友。今天咱们聊聊性能优化这件事。
说实话，我入行头三年，对性能优化是有点「敬畏」的。总觉得那是架构师才该操心的事，我一个开发把功能跑通就行了。直到有一次线上事故——用户量一上来，系统直接雪崩，老板拍桌子问「谁负责」——我才明白，性能问题从来不是「以后再说」的事。
嗯，今天这一章，咱们就把性能优化的底牌翻一翻。
1.1 性能优化的目标与意义
性能优化，说白了就是让系统在有限的资源下，跑得更快、更稳、更省钱。
目标其实就三个：
- 降低延迟——用户点一下，别让他等太久
- 提升吞吐——同一台机器，能扛住更多人
- 节省成本——少用服务器，少花冤枉钱
我见过不少团队，一上来就追求「极致性能」，结果优化了三个月，用户量没涨，服务器倒是多买了十台。这其实跑偏了。性能优化的真正意义，是在业务增长和成本之间找到平衡点。
核心观点：性能优化不是炫技，是投资。每一分优化，都要能换算成用户体验的提升或成本的降低。
1.2 核心性能指标
聊性能，先得会看指标。就像开车，你得知道时速、油耗、转速表在说什么。我整理了一张图，帮你快速建立知识框架。
下面我逐个拆解一下。
1.2.1 QPS（每秒查询数）
QPS 全称 Queries Per Second，就是系统每秒能处理多少个请求。它最常用于衡量读多写少的系统，比如搜索引擎、内容网站。
我记得有一次帮一个电商团队做压测，他们的首页接口 QPS 标称能到 5000。结果上线后用户一多，实际只有 800。查了半天，原来是缓存策略没做好，每次请求都穿透到数据库。你看，指标和现实之间，往往差着一个「细节」。
小技巧：QPS 不是越高越好。要结合 RT 一起看。如果 QPS 上去了，RT 也暴涨，那说明系统已经过载了。
1.2.2 RT（响应时间）
RT 就是 Response Time，从用户发出请求到收到响应的时间。单位通常是毫秒。
我个人的经验是：200ms 以内用户无感知，500ms 以内可以接受，超过 1 秒用户就开始烦躁了。
曾经有个项目，用户反馈「页面加载慢」。我们一看平均 RT 才 300ms，觉得没问题。后来一查 P99（99% 的请求都在这个时间内完成），好家伙，2.8 秒。原来是有少量慢查询拖了后腿。所以，别只看平均值，要看百分位值。
1.2.3 TPS（每秒事务数）
TPS 全称 Transactions Per Second，衡量的是系统每秒能完成多少个完整的事务。一个事务可能包含多个操作，比如下单：扣库存、生成订单、扣款……这一整套才算一个事务。
TPS 更适合衡量写多读少的系统，比如支付、订单系统。我见过一个支付团队，把 QPS 和 TPS 混为一谈，结果压测时发现 QPS 很高，但实际业务处理能力远低于预期。为什么？因为一个事务里包含了多次数据库写入，QPS 只数了请求次数，没数业务完成度。
| 指标 | 适用场景 | 典型值参考 | 注意事项 |
|---|---|---|---|
| QPS | 读多写少（如内容站、搜索） | 中小系统 1000-5000 | 结合 RT 看，避免缓存穿透 |
| RT | 所有系统 | 平均 < 200ms，P99 < 1s | 别只看平均，看百分位 |
| TPS | 写多读少（如支付、订单） | 中小系统 500-2000 | 区分事务边界 |
| 吞吐量 | 综合评估 | 取决于业务 | QPS/TPS 是它的子集 |
1.2.4 吞吐量
吞吐量是一个更宏观的指标。它可以是每秒处理的请求数（此时等价于 QPS），也可以是每秒处理的数据量（比如 MB/s），甚至可以是每秒完成的业务笔数。
说白了，吞吐量就是「系统在单位时间内能干多少活」。它是一个综合指标，QPS 和 TPS 都是它的具体表现形式。
1.3 性能优化的通用方法论
聊完指标，咱们说说方法论。我见过太多人一上来就「优化代码」，结果优化了半天，瓶颈在数据库连接池上。所以，方法论的核心就一句话：先测量，再优化，后验证。
我总结了一个四步法，你可以直接套用：
- 定义目标——你要优化到什么程度？RT 降到 200ms？QPS 提升到 5000？目标要可量化。
- 测量现状——用压测工具（如 JMeter、wrk）或 APM 工具（如 SkyWalking、Pinpoint）拿到当前数据。
- 定位瓶颈——是 CPU 满了？内存不够？IO 等待？还是数据库慢查询？用 top、vmstat、慢查询日志等工具定位。
- 实施优化——针对瓶颈下手。缓存、索引、连接池调优、异步化……选最有效的方案。
避坑指南：我曾经犯过一个错——优化前没做充分测量，凭感觉改了代码。结果 RT 没降下来，反而引入了 bug。记住：没有数据的优化，都是耍流氓。
另外，我建议你养成一个习惯：每次优化只改一个变量。改完就测，测完再改下一个。这样你才能知道到底是哪个改动起了作用。
举个例子，你怀疑数据库慢查询是瓶颈，那就先加索引，测一下；如果 RT 降了，说明猜对了；如果没降，再查是不是连接池太小。别一次改三个地方，出了问题你都不知道该回滚哪个。
1.4 本章小结
这一章咱们把性能优化的底子打好了。你知道了：
- 性能优化的目标是降延迟、提吞吐、省成本
- 四个核心指标：QPS、RT、TPS、吞吐量，各有各的用法
- 通用方法论：定义目标 → 测量现状 → 定位瓶颈 → 实施优化
嗯，这些内容看起来简单，但真正能做到「知行合一」的人不多。下一章咱们会深入具体的优化手段，从代码层面到架构层面，一步步拆解。到时候见。
一句话记住本章：性能优化不是玄学，是科学。先测量，再动手。
想要更多资料，联系可可