4. 峰值压测基础
在银行系统的容量规划工作中，峰值压测不是一次“跑个脚本看看TPS”的临时动作，而是一套有明确目标、可复现、可度量的工程方法。它的核心价值在于：用可控的施压手段，提前暴露系统在真实峰值场景下的容量边界与薄弱环节，为扩容决策、架构优化和应急预案提供数据依据。
一、压测的定义与核心目的
峰值压测是指在受控环境中，通过模拟真实业务请求的并发量、数据分布和调用链路，对目标系统施加接近或超过预期峰值的负载，并持续观测其响应时间、吞吐量、错误率和资源消耗的过程。它回答的不是“系统能不能跑”，而是“在多少负载下、以什么代价、能稳定跑到什么程度”。
压测的目的可以归纳为四个层次：
- 验证容量：确认当前系统在目标TPS下是否满足SLA，例如“日终批量前30分钟，联机交易TPS≥8000，P99≤200ms”。
- 发现瓶颈：定位CPU、内存、数据库连接池、线程池、网络带宽、锁竞争等具体限制点。
- 评估稳定性：观察系统在长时间高负载下是否存在内存泄漏、连接泄漏、GC恶化或队列堆积。
- 支撑决策：为扩容规模、限流阈值、降级策略和灾备切换提供量化输入。
二、四类压测的定位与区别
负载测试、压力测试、稳定性测试和并发测试经常被混用，但它们在施压方式、观测重点和结论输出上差异明显。下表给出对比清单：
| 类型 | 施压方式 | 核心观测指标 | 典型结论 |
|---|---|---|---|
| 负载测试 | 按预期峰值逐步加压 | TPS、响应时间、错误率 | 是否满足目标容量 |
| 压力测试 | 持续加压至系统崩溃或严重降级 | 最大吞吐、崩溃点、恢复时间 | 容量上限与失效模式 |
| 稳定性测试 | 在目标负载下长时间运行 | 内存、GC、连接数、错误率趋势 | 能否7×24小时稳定运行 |
| 并发测试 | 固定并发用户数或线程数 | 并发处理能力、锁冲突、资源争用 | 并发模型是否合理 |
四类测试并非互斥，而是组合使用。例如，先做并发测试验证线程模型，再做负载测试确认目标容量，接着做压力测试找到崩溃点，最后做稳定性测试验证长跑表现。
三、压测与容量规划的关系
容量规划的核心问题是：未来某个业务峰值到来时，现有资源能否支撑，若不能，需要增加多少资源、在哪些环节增加。压测是回答这个问题的关键输入。二者关系可以用“测量—建模—决策”来理解：
- 测量：通过压测获得单节点或单集群在不同负载下的性能曲线，包括TPS、响应时间、资源利用率。
- 建模：将压测数据与业务增长预测结合，建立容量模型，例如“TPS每增加1000，数据库CPU增加8%”。
- 决策：根据模型计算扩容节点数、数据库分片数、缓存容量和限流阈值。
没有压测数据，容量规划只能拍脑袋；只有压测数据而没有业务峰值模型，容量规划又会脱离实际。因此，压测必须与业务日历、交易峰值系数、数据增长趋势联动。
四、案例场景：某银行日终批量前的联机峰值
某银行核心系统在每日20:00—21:00出现联机交易峰值，历史最高TPS约6200。容量规划团队需要判断当前集群能否支撑即将到来的季度结息日峰值（预计增长30%）。
团队设计了一组压测：
- 负载测试：以5000、6500、8000 TPS三档各运行15分钟，观测P99和错误率。
- 压力测试：从8000 TPS开始每5分钟增加1000，直到错误率超过1%或P99超过1秒。
- 稳定性测试：在6500 TPS下持续运行4小时，监控Full GC频率和堆内存回收后水位。
- 并发测试：固定800并发线程，验证数据库连接池和线程池配置是否匹配。
压测发现：当TPS达到7200时，数据库CPU升至92%，P99从180ms跳升至650ms；继续加压至8500时，连接池等待队列溢出，错误率升至3.7%。结论是当前集群安全容量约为6800 TPS，无法支撑预计的8060 TPS峰值，需要增加数据库只读节点并调整连接池参数。
五、常见误区与复盘要点
在实际项目中，峰值压测容易陷入以下误区：
- 只压应用不压数据库：应用层TPS很高，但数据库连接池和慢SQL才是真正瓶颈。
- 用平均响应时间代替P99：银行交易对尾部延迟敏感，平均值会掩盖长尾问题。
- 压测数据量过小：生产环境亿级数据量下的索引深度和缓存命中率与测试环境差异巨大。
- 忽略施压机自身瓶颈：施压机CPU或网络先打满，导致压测结果偏低，误判系统容量。
- 一次性压测代替持续观测：容量规划需要定期复测，因为业务量、数据量和版本都在变化。
复盘时建议围绕三个问题展开：瓶颈是否定位到具体组件和参数？扩容建议是否有压测数据支撑？下一次压测需要调整哪些场景或数据？只有把压测、监控、容量模型和扩容动作串成闭环，峰值压测才能真正服务于银行系统的稳定运行。