解读

1. 业务场景：滑块验证码通常位于登录、注册、秒杀、领券等关键入口，一旦并发升高，后端需要实时生成缺口坐标、验证轨迹、防刷风控，CPU/内存/网络瞬时飙升，极易成为系统短板。
2. 瓶颈类型：
   • 生成侧——图片切割、缺口随机算法、Redis 缓存命中率低导致重复造图；
   • 验证侧——轨迹相似度算法、机器学习模型推理、风控规则引擎；
   • 存储侧——验证码状态高频读写，Redis 大 key 或慢查询；
   • 安全侧——防重放、防 Token 复用，带来额外加解密开销。
3. 评估目标：不是“接口能跑多快”，而是“在保证 99% 成功率、99th 响应时间 < 800 ms、滑块图片生成耗时 < 300 ms 的前提下，系统能承载的最大并发虚拟用户数”。
4. 国内落地约束：
   • 需过等保，日志留存 6 个月，压测数据必须脱敏；
   • 公有云 WAF/验证码厂商多数有 QPS 上限，超出即丢包或强制降级；
   • 金融、电商大促时段，监管要求“一键关停”验证码，必须提前验证降级开关有效性。

知识点

1. 性能指标三维：并发虚拟用户数（VU）、吞吐量（QPS/TPS）、响应时间（RT 分布及 99th 线）。
2. 验证码特有指标：
   • 图片生成成功率、生成耗时、图片平均大小；
   • 校验通过率、误杀率、轨迹重放率；
   • Token 过期命中率、Redis key 空间增长率。
3. 压测模型：
   • 梯度加压（Stepping）找拐点；
   • 脉冲模型（Spike）验证瞬时毛刺；
   • 长时间 soak（≥8 h）观察内存泄漏、缓存穿透。
4. 监控体系：
   • 应用层——QPS、RT、错误码分布、线程池队列长度；
   • 中间件——Redis 缓存命中率、慢查询、大 key 分析；
   • 系统层——CPU 利用率、上下文切换、内存分配速率、网卡 PPS；
   • 安全层——验证码请求量与登录请求量比例，异常 IP 聚合。
5. 瓶颈定位工具：
   • Java——Arthas 火焰图、JProfiler、async-profiler；
   • Redis——redis-cli --bigkeys、Redis slowlog；
   • OS——perf、pidstat、tcpdump 抓包看 TLS 握手比例。
6. 容量公式：
   最大并发 VU = (目标 QPS × 平均 RT(s)) / 思考时间(s)
   反向推导：若单台验证码服务极限 QPS 为 1200，目标 RT 0.3 s，思考时间 1 s，则单台支持 VU ≈ 360；如需支撑 1 万并发，需 28 台实例 + 20% 冗余。
7. 国内合规：
   • 压测前在工信部备案“网络安全测试”，避免被封 IP；
   • 灰度期间开启“验证码降级为短信验证码”开关，防止因压测误杀真实用户。

答案

1. 需求澄清
   与产品、安全、运维三方对齐 SLA：

   • 业务目标：秒杀峰值 3 万并发，验证码环节 99% 请求 RT < 800 ms，成功率 ≥ 99%，误杀率 ≤ 1%。
   • 约束条件：只开放 20 台 4C8G 容器，预算不扩容；Redis 集群 8 G 内存；禁止调用外部 AI 推理接口。

2. 场景设计
   a. 单接口基准：使用 JMeter 线程组 200 并发，循环 300 s，只看“获取滑块图片”接口，拿到 baseline QPS 与 RT。
   b. 混合场景：按漏斗比例 1:0.8:0.75 模拟“获取验证码→提交轨迹→登录”，更贴近真实。
   c. 梯度加压：每 2 min 递增 500 VU，直至错误率 > 1% 或 RT 99th > 800 ms，记录拐点。
   d. 脉冲测试：瞬间注入 2 倍拐点并发，持续 30 s，观察自愈时间。
   e. 稳定性 soak：以 80% 拐点负载持续 8 h，检查内存、Redis key 增长、日志滚动。

3. 监控与埋点

   • 在验证码服务内部新增 Micrometer 指标：captcha_generate_total、captcha_verify_total、ai_score_seconds。
   • Redis 监控加上 key 过期事件速率，防止雪崩。
   • 使用阿里云 SLS 配置关键字告警：“验证码生成失败”“image cut timeout”。

4. 执行与调优
   第一轮结果：拐点 4200 VU，QPS 2600，RT 99th 1.1 s，超过 SLA。
   瓶颈定位：

   • CPU 火焰图发现 68% 耗时在 java.awt.Graphics2D 做图片旋转，属同步阻塞；
   • Redis 大 key 单值 180 k，网卡打满 1.2 Gbps。
     优化措施：
   • 预生成 2 万张滑块模板，启动时加载到内存，请求时随机挑选，CPU 降到 25%；
   • 采用 Redis pipeline + 压缩位图，单值降到 12 k，网卡降至 180 Mbps；
   • 引入本地 Caffeine 二级缓存，命中率 92%，Redis QPS 下降 70%。
     第二轮结果：拐点 7200 VU，QPS 4500，RT 99th 650 ms，满足 SLA。

5. 容量结论
   单容器 4C8G 可支撑 350 QPS，20 容器集群可扛 7000 QPS；对应并发虚拟用户数 7000 × 0.8 / 1 ≈ 5600 VU，满足秒杀峰值 3 万登录请求所需的验证码流量（按转化率 20%，需 6000 QPS），预留 15% 缓冲，可安全上线。

6. 报告与评审
   输出《滑块验证码容量评估报告》，包含测试环境拓扑、风险清单、降级预案、监控大盘截图，邀请安全、运维、DBA 三方评审，通过后归档 Confluence，并在压测平台录入基线，作为下次版本回归的基准。

拓展思考

1. 如果公司使用第三方验证码 SaaS，如何评估其“理论最大并发”？
   思路：在合同 SLA 范围内，采用“阶梯压测 + 费用熔断”双控——每上升 1 k QPS 观察账单与 RT，一旦费用达到预算 80% 或 RT 超标即停止，形成“经济拐点”曲线，为商务谈判提供数据。

2. 验证码服务容器化后，HPA 根据 CPU 70% 阈值弹性伸缩，压测时如何防止“抖动”？
   答案：在压测脚本里预埋预热阶段，先 50% 负载跑 3 min，让 Pod 数量稳定；再关闭 Cluster Autoscaler，避免节点级伸缩干扰；压测结束后再开启，保证指标纯净。

3. 未来想从“滑块”升级为“无感行为验证码”，性能基线如何继承？
   核心是把“前端 SDK 采集→后端模型推理”链路纳入同一套压测框架，用 Gatling 模拟 10 k 并发浏览器，通过 Chrome DevTools Protocol 回传行为数据，验证模型推理 RT 与 GPU 利用率，确保升级后容量不退化。