容量不够怎么演变成事故

回顾一下上一次大促事故，多半是这么个剧本：流量涨到平时的三倍，系统开始变慢、然后开始报错、最后直接挂掉。根因往往不是代码突然写崩，而是容量从来没规划过——不知道现在的机器到底能扛多少流量，所以也不知道三倍够不够。

容量规划要回答的就是这个问题：现在这套系统，正常能扛多少？峰值能扛多少？离扛不住还有多远？压测则是回答这个问题的手段——别等大促那天才知道答案。

在实验室里把它压垮，好过在大促当天被用户压垮。
本文核心知识点
  • 压测在测试环境模拟高流量，先把系统压垮一次。
  • 瓶颈定位找到慢在数据库、缓存还是应用层。
  • 容量模型推算一台机器能扛多少 QPS，好按需扩容。
  • 余量永远留着冗余，别把机器用满。
容量规划与性能压测配图：左侧服务器堆叠、中间彩色刻度弧仪表盘、右侧向上流量箭头曲线的蓝色扁平科技插画
先知道这个表盘到哪儿会爆，才知道该备多少机器。

压测：先在实验室里压垮它

压测（压力测试）就是在测试环境人为制造高并发流量，看系统什么时候扛不住。常用工具里，JMeter 适合搭场景、上手快；想压更大规模可以用 wrk 或更专业的分布式压测平台。核心思路都一样：模拟真实用户请求，逐步加流量，记录每一档下的响应时间和错误率。

最简单的一轮压测流程：
1. 在测试环境准备和生产同等配置的一套系统
2. 从 100 并发开始，每档跑 5 分钟
3. 记录每档的：QPS、平均响应时间、错误率
4. 一直加压，直到响应时间明显变长或开始报错
5. 那个临界点，就是这套系统的容量上限

千万别在生产环境直接压——压测是为了发现极限，压崩测试环境没事，压崩生产就是事故了。

压测怎么设计：场景和目标

压测不是「越多人越好」，得按真实业务来设计场景。一个网站的真实流量构成里，首页打开、商品列表、下单这些接口的调用比例是不一样的——下单接口最重，却被调得少；首页最轻，却被调得最多。压测场景得按这个真实比例配比，而不是无脑全压首页。

还要定清楚目标：我们想达到多少 QPS？在这个 QPS 下，响应时间要在多少毫秒以内、错误率要低于多少？没有目标，压完了也不知道算不算合格。一般做法是：按历史峰值流量的 1.5 到 2 倍设目标，留好未来增长的余量。

找瓶颈：慢在哪一层

压到一定程度，系统开始变慢。这时候要定位到底卡在哪一层。常见的瓶颈位置：

先看各层资源：
- CPU 打满？→ 应用层计算瓶颈，考虑加机器或优化代码
- 内存打满？→ 可能有内存泄漏或缓存过大
- 数据库慢查询多？→ SQL 没走索引，加索引或加缓存
- 数据库连接数满？→ 连接池配置或慢查询堆积
- 磁盘 IO 高？→ 日志写太猛或数据库在大量读写

经验上，大多数 Web 系统的第一个瓶颈都在数据库——一个慢查询把连接占住，后面的请求全排队。所以压测时第一件事是盯着数据库的慢查询日志和连接数，十有八九问题就出在那儿。配合前面讲的全链路监控，每一跳的耗时都能看到，定位就快了。