性能度量与目标：延迟、吞吐量、一致性模型、SLA/SLO
做高并发系统，第一件事不是写代码。
是先把「度量」搞清楚。
我见过太多团队，一上来就堆机器、上缓存、搞分库分表。结果呢？延迟还是高，吞吐上不去，线上事故不断。为什么？因为他们根本不知道自己要优化什么。
说白了，没有度量，就没有优化。
延迟：P50、P99、P999 到底在说啥？
延迟，就是一次请求从发起到返回的时间。但问题来了——一次请求快不代表所有请求都快。
你想想看，一个接口平均耗时 10ms，但偶尔有 1% 的请求卡了 5 秒。用户感知到的，就是那个 5 秒的慢请求。平均延迟会骗人，百分位延迟不会。
核心概念：
- P50（中位数延迟）：一半请求比它快，一半比它慢。反映系统「通常」的表现。
- P99（99分位延迟）：99% 的请求比它快，1% 的请求比它慢。这是用户体验的「红线」。
- P999（99.9分位延迟）：千分之一的慢请求。往往是系统瓶颈的「放大镜」。
我在项目中遇到过一件事。有个支付接口，P50 只有 20ms，看起来挺漂亮。但 P99 飙到了 800ms，P999 直接 3 秒。用户投诉说「偶尔卡死」。后来一查，是某个数据库连接池在高峰期打满了，慢查询排队导致的。
嗯，这就是只看平均延迟的坑。
我的习惯：线上监控至少看 P50、P99、P999 三个指标。P50 管日常，P99 管体验，P999 管稳定性。任何一个出问题，都得追。
吞吐量：TPS 和 QPS 别搞混了
吞吐量，就是系统单位时间能处理多少请求。
但这里有个常见的混淆点——TPS 和 QPS 不是一回事。
| 指标 | 全称 | 含义 | 典型场景 |
|---|---|---|---|
| QPS | Queries Per Second | 每秒查询数 | 读多写少的场景，比如商品详情页 |
| TPS | Transactions Per Second | 每秒事务数 | 写多读少的场景，比如下单、转账 |
一个事务可能包含多次查询。比如下单：先查库存（1次Q），再扣库存（1次T），再生成订单（1次T），再发消息（1次T）。所以 TPS 通常比 QPS 更「重」。
我曾经帮一个电商团队做压测，他们报的 QPS 是 5000，但 TPS 只有 800。我说你们这系统扛不住双十一。他们不信。结果大促那天，订单接口直接被打挂了。为什么？因为 QPS 高不代表事务处理能力强。
避坑指南：我曾经犯过一个错——用 QPS 去衡量写接口的性能。后来发现，写接口的瓶颈往往在事务、锁、磁盘 IO 上，QPS 根本反映不出来。所以，读接口看 QPS，写接口看 TPS，别混着用。
一致性模型：强一致性 vs 最终一致性
这是高并发系统里最让人头疼的选择题。
强一致性：写完之后，任何读都能立刻看到最新数据。听起来很完美，但代价是性能。因为你要加锁、要同步、要等待所有副本确认。
最终一致性：写完之后，不保证立刻读到最新数据，但保证「过一会儿」一定能读到。性能好，但业务上要能容忍短暂的不一致。
你想想看，银行转账能用最终一致性吗？不行。用户转完钱，余额没变，那不得炸锅？但一个论坛的点赞数，晚几秒更新，谁在乎？
我的经验：
- 强一致性：适用于金融、支付、库存扣减等场景。我做过一个支付系统，用的就是 Paxos 协议保证强一致。性能确实有损耗，但业务安全第一。
- 最终一致性：适用于社交、日志、统计等场景。比如用户发了一条动态，好友晚几秒看到，完全没问题。
但要注意，最终一致性不是「不管一致性」。你得设计好补偿机制。比如订单超时未支付自动取消，这就是一种补偿。
SLA 和 SLO：别让老板拍脑袋定目标
SLA（Service Level Agreement）是服务等级协议，说白了就是「你跟用户承诺了什么」。
SLO（Service Level Objective）是服务等级目标，是「你自己给自己定的内部指标」。
举个例子：
- SLO：P99 延迟 < 200ms，可用性 99.99%
- SLA：如果 P99 延迟超过 500ms 持续 5 分钟，赔偿用户 10% 的月费
看到了吗？SLO 比 SLA 更严格。你内部的目标要比对外承诺的高，这样才有缓冲空间。
我见过一个团队，SLA 写的是「可用性 99.9%」，但 SLO 定的是 99.99%。为什么？因为一旦触发 SLA 赔偿，成本很高。留出 0.09% 的余量，就是给自己留条活路。
我的建议：SLO 要基于真实数据来定。别拍脑袋。先跑一个月监控，看看 P99 实际是多少，再定一个「跳一跳够得着」的目标。定得太松，没意义；定得太紧，天天报警，团队也受不了。
知识体系总览
下面这张图，把这一章的核心逻辑串起来了。你可以把它当作一个「度量地图」。
这张图里，四个模块是互相影响的。延迟高了，吞吐量自然上不去。一致性要求越强，延迟和吞吐的代价就越大。SLO 定得太严，可能逼着你在延迟和一致性之间做取舍。
所以，做性能优化之前，先把这四个维度想清楚。你优化的是哪个指标？牺牲的是哪个指标？心里要有数。
一句话总结：延迟看百分位，吞吐量分 TPS/QPS，一致性按场景选，SLO 要基于数据定。这四个东西搞明白了，性能优化才有方向。
公众号:蓝海资料掘金营，微信deep3321