Appearance
容量规划与全链路压测
定位：金融级稳定性方法论（2/6）。容量不是"机器够不够"，是"在最贵的那一分钟，系统还能不能站在水里线上"。本篇写四件事：容量估算的公式与系数、信贷业务的大促/月结双峰日历。以及全链路压测三种方案的对比选型、压测数据构造与敏感数据脱敏。前置阅读：SLO 与稳定性工程（水位目标由 SLO 推导）。方案文档里的容量账本写法见 如何出一个技术方案 第四节。
一、容量估算：一个公式和三个系数
规划容量 = 峰值 QPS × 放大系数 ÷ 目标水位
峰值 QPS = 日请求量 / 86400 × 峰值系数 （日常口径）
放大系数 = 业务增长 × 突发余量 × 故障余量 （三系数相乘，别只取其一）- 业务增长：按规划周期取（半年 1.3~1.5 倍），信贷余额驱动的量随资产规模涨，不随活动。
- 突发余量：重试风暴与超时放大。下游变慢时上游重试，1 次 timeout × 3 次重试 = 3 倍流量。压垮系统的常常不是用户是重试（见 问题定位步骤 的流量信号）。
- 故障余量：同城双活架构下，单机房故障另一半要接住全量。日常水位必须低于 50%，这是"多活"两个字真实的价格。
| 资源 | 目标水位 | 超水位的先兆 |
|---|---|---|
| 应用 CPU | ≤ 50%（双活）/ ≤ 70%（单活） | P99 首先抖，错误率还正常 |
| DB 连接池 | ≤ 60% | 获取连接排队，表现为超时无错误日志 |
| DB 磁盘/主从延迟 | ≤ 70% / 延迟 < 1s | Seconds_Behind_Master 抖动 |
| 缓存内存 | ≤ 70% | 逐出率上升，命中率下降 |
| MQ 堆积 | 消费能力 × 2 小时 | 堆积先于用户感知，是最好的前置告警 |
三个常见坑。其一，只算应用不算 DB（QPS 上去了先死的是连接数和磁盘）。其二，只算均值不算峰值（压垮系统的是峰值，均值只在报表里好看）。其三，只算自己不算下游（自己扛住了把征信渠道打挂，事故照样是自己的）。
二、金融日历：大促与月结双峰
信贷的容量不是均匀的，被两张日历拽着走：
QPS
│ 大促峰（脉冲型） 月结峰（块状型）
│ ██ ████
│ ██ ████
│ ██ ████
│ ▂▂▂▂▂▂▂▂ ██ ▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂
└────────────┬──────────────────────────────┬────────► 时间
11.11 大促 每月账单日/还款日- 大促峰（脉冲型）：提额、放款、支付在几分钟内堆到超过日常 10 倍。特征是来得快去得快，靠提前扩容 + 弹性资源 + 限流兜底（见 应急预案三板斧 的限流一节）。
- 月结峰（块状型）：账单日扣款、还款查询持续数小时高位，且是定时任务驱动而非用户 QPS 驱动。扣款 Job 的并发度、渠道限速才是真正的容量参数。特征是可精确预测，靠常态化容量规划消化，不需要大促式保障。
反例：按日均均量配容量，账单日第一天批量扣款把 DB 连接池打满，用户主动还款全部超时——月结峰不是"多一点流量"，是另一种负载模型（批量写 + 渠道回调风暴）。容量规划必须 max(两峰) 分别建模，而不是拿一条"峰值系数"套所有场景。
三、全链路压测：三种方案对比
单机/单服务压测只能验证组件上限，"大促当天生产会不会挂"这个问题只有全链路压测能回答。三种方案：
| 方案 | 做法 | 优势 | 劣势 | 适用 |
|---|---|---|---|---|
| 影子库（独立环境回放） | 录制生产流量，在独立环境回放 | 零侵入生产 | 环境与生产漂移、数据量级失真、维护一套全量环境成本高 | 中小规模、无全链路改造条件 |
| 流量染色 + 影子表 | 生产环境压测流量打标，全链路透传，数据落影子表/影子 topic | 拓扑、容量、数据分布全真实 | 改造成本高：RPC/MQ/缓存/DB 全链路中间件要识别标 | 大规模金融核心链路（主流选择） |
| 存储隔离（影子集群） | 压测流量路由到独立 DB/缓存集群 | 存储隔离最彻底 | 存储资源接近翻倍、路由层自身成为故障点 | 数据绝对不能混写的高敏场景 |
选型逻辑（大厂走"染色 + 影子表"的原因）：容量问题的本质是"真实拓扑上的真实瓶颈"。影子库环境复现不了生产的连接数分布与热点行竞争。而影子集群把最贵的存储层隔离掉，恰恰压不到 DB 真实水位。染色方案的代价是全链路改造，这个投入一次性、长期复用。
压测流量 ──► 网关打标 ──► 服务A ──► 服务B ──► DB
│ │ 标记随 ctx 透传 │
│ ▼ ▼
│ MQ 影子 topic 影子表 order$_test
│ 缓存 key 前缀 shadow_
真实流量 ─────┴───────► 同一条链路，落真实表四、压测数据构造与敏感数据脱敏
金融场景的压测数据有两条铁律：数据分布必须保真，敏感信息必须脱敏。
| 数据域 | 构造方式 | 脱敏/隔离要求 |
|---|---|---|
| 用户与账户 | 生产画像抽样克隆 + 独立号段的压测专用账户 | 手机号/身份证格式保留加密（FPE），保持唯一性与格式校验可过 |
| 账单与借款 | 按真实金额分布/期龄分布铺底 | 账单金额分布保真——扣款峰的 DB 热点依赖它 |
| 第三方依赖 | 渠道挡板（mock 征信/支付/卡组织） | 绝不允许压测流量触达外部渠道，金融合规红线 |
| 旁路动作 | 短信/推送/外呼一律拦截 | 压测账号向真实用户发营销短信是事故，不是测试 |
- 铺底数据：只造"量"不造"分布"是常见假压测。一亿笔等额账单压不出热点行冲突，真实生产是少数大户/少数商户集中。按生产分位数采样铺底。
- 脱敏要可逆可控：不可逆哈希会破坏"按手机号查用户"的链路语义。格式保留加密（FPE）既脱敏又保格式与唯一性。脱敏字典单独管控，本身就是敏感数据。
- 影子数据的隔离校验：上线前用"标忘传"演练验证。人为构造一次标记丢失，确认写入被拒绝并告警，而不是静默落进真实表。这是染色方案最危险的故障模式。
五、压测执行与读数
逐级加压，每档稳态观察：
10% ──► 30% ──► 50% ──► 70% ──► 100%（目标峰值）──► 120%（超额验证）
│
超额档不看"扛不扛得住"，
看"限流降级预案是否按预期自动触发"读数三个要点：
- 拐点先看 RT 再看错误率：RT 弯了、错误率还没动，就是容量天花板的前兆。等到错误率涨，已经在丢请求了。
- 瓶颈定位交给链路：压测发现的慢 span，按 性能优化方法论 与 问题定位步骤 的方法收敛。压测团队负责"指出哪里弯了"，不做"猜测式优化"。
- 预案联动验证：120% 档位是给限流/降级预案做的实战考场。阈值是不是拍的、开关是不是真的生效，见 应急预案三板斧 与 混沌工程与故障演练。
六、扩容还是优化：压测之后的决策树
瓶颈找到了
│
├─ 拐点远低于目标（如 30%）──► 优化优先：索引/慢 SQL/缓存/异步化
│ （方法见[性能优化方法论](性能优化方法论.md)）
├─ 拐点接近目标（70%~100%）──► 优化 + 扩容并行：扩容保大促，优化降常态成本
└─ 拐点超过目标但水位顶死 ────► 纯扩容（钱能解决的不用加班），
但要复核放大系数是否虚高（重试放大最常见）扩容要算总账：常态水位压到 50% 意味着平时一半机器在"付钱等故障"。月结块状峰适合定时弹性（账单日前 1 小时扩，峰值过自动缩）；大促脉冲峰适合限时弹性 + 限流兜底。容量规划的最终输出不是机器数，是"常态容量 + 弹性策略 + 限流阈值"三件套。第三件见 应急预案三板斧。
七、压测的组织与角色
| 角色 | 职责 | 纪律 |
|---|---|---|
| 压测指挥 | 定加压档位、判稳、下令中止 | 唯一有权加压/停压的人 |
| 平台执行 | 施压、打标、采数 | 只执行指挥的指令 |
| 各域观察员 | 盯本域水位与 SLI，异常喊停 | 每个被压域至少一人在线 |
| 预案值守 | 120% 档验证限流降级触发 | 对照三板斧篇的预案库 |
反例：没有指挥、各域自行加压——A 域想再压一轮，B 域已经在雪崩边缘。压测事故大多不是平台故障，是协同失控：加压指令只能有一个来源，喊停任何一个角色都可以。
八、实践清单
- 容量公式里三个系数相乘，不是取最大值。增长 1.5 × 突发 2 × 故障余量 2 = 6 倍。先别惊呼，去掉冗余后按分层水位逐项核。
- 月结峰按 Job 并发与渠道限速建模，不按 QPS。
- 压测计划表要列出"每次压测验证的假设"。没有假设的压测是打卡，不是工程（对照混沌工程的稳态假设）。
- 压测中断条件前置写死：核心 SLI 越界、影子数据泄漏告警、生产指标异常。任一触发立即停。
- 压测报告归档到容量账本：本次拐点、当时的拓扑与配置、扩容后的新拐点。下次大促前这是最重要的输入。
- 别忘定时任务与回调：账单日扣款是 Job。渠道异步回调的峰值滞后于发起峰值两小时。
- 扩容后做一轮"影子观察"再收保障。新机器缓存冷启动。第一波真实流量的命中率与 RT 和老机器的差异要看过再撤。
- 渠道侧容量对齐：自己扩容 10 倍、支付渠道只给了 2 倍限额等于没扩。压测报告必须包含外部依赖限速的书面确认。
一句话总结
容量 = 峰值 × 系数 ÷ 水位，三个数每一个都要说得出依据。 压测方案选型的本质是"真实性 vs 隔离成本"的折中，金融核心链路的答案通常是染色 + 影子表。 数据分布保真与敏感信息脱敏是压测数据的两条底线，压测本身不能成为事故。
2026-10 新增（金融级稳定性方法论系列）。