估规模，就是把数量级对上

一句话总结

容量估算的目的不是得到精确数字，而是确定数量级。需要 3 台实例还是 30 台实例，会让整个设计完全不同。

为什么需要了解这一点

系统设计分四个阶段进行：明确需求 → 估算规模 → 高层设计 → 详细设计（识别并解决瓶颈）。跳过第二阶段，其余部分都会变成空想。

来看一个简单示例。每天写入 1 亿条，QPS 约为 1,160（1 亿 ÷ 86,400）。读取量是其 10 倍时，QPS 约为 11,600。5 年共 1800 亿条，乘以每条记录 500 字节，约为 90TB。得到这三个数字后，便能有依据地回答“单实例是否足够”“是否需要分片”“没有缓存能否实现”等问题。

工作原理

从测量走向规模计算，需要两项安全措施。

第一是余量。不能直接采用测得的最大吞吐量，安全吞吐量应取测量值的 70% 左右。剩余 30% 用于应对流量波动、部署期间实例减少，以及意外的慢请求。如果测得每实例 190 RPS，安全吞吐量就是 133 RPS。

第二是向上取整。目标 300 RPS 除以 133 得到 2.25 台，但 2 台不够，所以需要 3 台。在容量计算中舍去小数部分，计划会当场失败。

调整 pool 大小时也需要同样的思路。如果把单实例建议 pool size 定为 60，就必须在整个 fleet 层面相乘验证。40 台实例 × 60 = 2,400 条连接；如果数据库的 max_connections 是 200，那么每台实例的计算虽都正确，系统仍会在部署后立即崩溃。这是局部最优不等于全局最优的典型案例。

实际工作中的表现

容量文档中最常见的缺陷是没有条件。“我们的服务每秒处理 500 条”这句话没有 concurrency、p95、错误率，也没有测量时间。如果同一个服务在 concurrency 2 时以 p95 20ms 达到 500 RPS，在 concurrency 50 时以 p95 900ms 达到 520 RPS，那么第二个数字不是容量，而是已经饱和状态下的观测值。

所以容量必须始终与 SLA 一起记录。应写成“在 p95 不超过 200ms、错误数为 0 的条件下，每实例 133 RPS”，下一位人员才能按同一基准复现。

四种负载测试

区分名称后，就能明确各自衡量什么。

类型	做什么	能知道什么
负载（load）	维持预期流量	目标负载下的延迟与错误率
压力（stress）	持续提高负载	崩溃点与崩溃方式
峰值（spike）	突然提高到十倍	自动扩缩容能否跟上
耐久（soak）	以正常负载运行数小时	内存泄漏、连接泄漏、磁盘耗尽

压力测试的价值不在极限数字，而在崩溃方式。 是能够优雅地拒绝（429）、全部变慢，还是直接终止，体现了设计质量。相比“每秒可处理 5,000 个请求”，“超过 5,000 后返回 429，降回 4,800 后能够恢复”是更有用的描述。

遗漏耐久测试，就会错过一小时后才出现的问题。connection pool 泄漏、file descriptor 不断积累、GC 时间越来越长，这些都无法在 5 分钟测试中观察到。

闭环与开环

负载工具生成请求的方式有两种，结果完全不同。

폐 루프(closed): 가상 사용자 N 명이 응답을 받아야 다음 요청을 보낸다
                 → 서버가 느려지면 부하도 저절로 줄어든다
개 루프(open):   초당 N 건을 서버 상태와 무관하게 보낸다
                 → 서버가 느려지면 요청이 쌓인다. 현실에 가깝다

真实用户更接近开环。 因为人们不会因服务器变慢而减少请求。如果只用闭环测试，可能得到“100 个虚拟用户时延迟 200ms”这样的漂亮数字，但实际上系统在该点已经崩溃。

k6 使用 constant-arrival-rate、Gatling 使用 constantUsersPerSec 创建开环。 测试自动扩缩容时必须使用开环。

协调遗漏（coordinated omission）

这是闭环工具更隐蔽的问题。响应变慢后，这段时间内未能发出的请求 根本不会进入测量，导致 p99 看起来远好于实际情况。

서버가 10초 멈췄다
  폐 루프: 그동안 요청을 안 보냄 → 느린 요청 1건만 기록 → p99 정상
  현실:    그동안 요청이 계속 옴 → 수천 건이 10초를 기다림 → p99 폭발

应使用能够校正这一问题的工具（--latency-correction、基于 HdrHistogram），或者采用开环测试。如果 p99 好得可疑，应首先怀疑这个问题。

现场判断的顺序

确定目标流量（以峰值为准，不是平均值）。
在 SLA 条件下测量单实例的安全吞吐量。
加入余量，将其降至 70%。
相除后向上取整。
再与共享资源（DB connection、cache、queue）的上限相乘复核。

下一项检查将看什么

本模块不安排练习，以检查概念与计算的测验结束。对前三个模块中得到的 baseline、ladder 和 bottleneck report 数字进行复核，将其转换为平均 QPS、峰值倍数、考虑余量后的安全吞吐量，以及所需实例数量。