1. 课程导入

银行系统的稳定性不是靠“上线后观察”获得的，而是在设计、建设、演练、运营各阶段被持续验证出来的。容量规划回答“系统能承载多少、何时需要扩容、扩容到哪里”，峰值压测回答“在真实峰值或超预期峰值下，系统是否仍然可控”。两者结合，构成银行核心系统、支付系统、信贷系统、手机银行、开放银行等关键业务连续性的底座。

一、学习目标：从“能跑”到“可证明能扛”

本课程的学习目标不是记住若干压测工具命令，而是建立一套可落地、可审计、可复盘的容量工程方法。完成学习后，你应当能够：

• 用业务指标（TPS、并发用户、日交易量、峰值倍数）和技术指标（CPU、内存、IOPS、连接数、队列深度、P99 延迟）共同描述容量。
• 基于历史交易数据与业务增长模型，推导未来 6～12 个月的容量需求，并给出扩容窗口与预算依据。
• 设计贴近银行真实场景的峰值压测方案，包括业务模型、数据铺底、链路隔离、监控埋点与熔断降级验证。
• 读懂压测报告中的拐点、瓶颈与错误分布，定位是应用、数据库、中间件、网络还是第三方依赖导致。
• 把压测结论转化为生产变更：限流阈值、线程池参数、连接池大小、缓存策略、扩容规格与应急预案。

二、核心价值：为什么银行必须做容量规划与峰值压测

银行系统的峰值具有明显的“脉冲性”和“不可试错性”。例如代发工资日、理财开售、信用卡账单日、节假日红包、季末结息、双十一支付高峰，都会在短时间内把交易量推高到日常的数倍甚至数十倍。若没有容量规划，扩容往往滞后；若没有峰值压测，系统瓶颈只能在真实故障中暴露。

其价值可归纳为四个层面：

三、整体知识框架：从业务模型到生产参数

本课程的知识框架按“业务—模型—压测—分析—落地”五层展开。第一层是业务容量模型，把交易量、峰值倍数、用户行为转化为可计算的负载；第二层是技术容量模型，把负载映射到 CPU、内存、磁盘、网络与中间件资源；第三层是压测工程，包括场景设计、数据准备、流量染色、监控采集；第四层是瓶颈分析，通过指标关联定位根因；第五层是生产落地，把结论写入配置、预案与扩容计划。

四、典型场景与案例：峰值压测到底在压什么

以手机银行“代发工资日”为例。日常转账 TPS 约 800，代发日 9:00—10:00 可能达到 6000～9000，且伴随大量余额查询、明细查询和短信通知。若只压转账接口，忽略查询与通知链路，生产环境仍可能因数据库连接池被查询占满而拖垮转账。正确的做法是：按真实交易比例构造混合场景，例如转账 35%、余额查询 30%、明细查询 20%、通知 10%、其他 5%，并设置 3 倍日常峰值作为目标水位。

另一个常见场景是理财开售。开售瞬间并发抢购，库存扣减、订单创建、支付扣款、份额确认形成长链路。此时压测重点不是单接口 TPS，而是链路一致性、分布式锁竞争、数据库行锁等待和消息积压。若压测只关注“请求成功”，忽略“最终一致性延迟”，上线后会出现超卖或对账不平。

五、常见误区与复盘要点

• 误区一：只压应用不压数据库。应用层扩容容易，数据库往往才是真瓶颈。压测必须包含慢 SQL、锁等待、主从延迟、连接数水位。
• 误区二：用平均响应时间判断容量。银行峰值更关注 P99、P999 和超时率。平均值正常不代表尾部请求没有雪崩。
• 误区三：压测环境与生产架构不一致。节点数、中间件版本、网络策略、限流配置不同，结论不可直接迁移。
• 误区四：没有熔断降级验证。峰值压测不仅要验证“能扛”，还要验证“扛不住时如何优雅失败”。
• 误区五：压测报告没有行动项。没有责任人、没有截止时间、没有复测计划的报告，只是数据展示。

六、实战路线图与工具准备

本课程后续将按“容量建模—场景设计—压测执行—瓶颈定位—生产落地”推进。建议提前准备以下环境与工具认知：

# 典型压测工具链示例
压测引擎：JMeter / Locust / Gatling / wrk / 自研全链路压测平台
监控采集：Prometheus + Grafana / SkyWalking / Arthas / 慢查询日志
数据铺底：影子表 / 流量染色 / 脱敏数据 / 热点账户构造
生产验证：限流阈值 / 线程池参数 / 连接池大小 / 缓存命中率

容量规划与峰值压测的最终目标，是让银行系统在业务脉冲面前“有数、有底、有预案”。有数，指容量模型可计算；有底，指压测结论可证明；有预案，指峰值异常时可切换、可限流、可降级、可恢复。掌握这套方法，你不仅是在做一次压测，更是在为银行关键业务建立可验证的稳定性防线。