2. API 限流基础：限流的概念、为什么需要限流、限流与熔断的区别
2.1 限流的核心概念
限流（Rate Limiting / Throttling）是一种通过控制单位时间内允许通过的请求数量，来保护系统后端资源不被过度消耗的防护手段。在金融系统中，限流通常作用于 API 网关、负载均衡器或业务服务入口层。
定义：限流 = 限制访问速率，拒绝超出阈值的请求，保障系统在安全水位下运行。
限流的关键指标包括：
- QPS（Queries Per Second）：每秒允许通过的请求数。
- TPS（Transactions Per Second）：每秒允许通过的事务数（通常包含多个 API 调用）。
- 并发数（Concurrency）：同时处理中的请求数量上限。
- 窗口时间（Window）：统计周期，如 1 秒、1 分钟、1 小时。
2.2 为什么需要限流：防止雪崩与保障公平性
在金融压力测试场景下，限流的核心价值体现在两个维度：防止系统雪崩和保障资源公平性。
2.2.1 防止雪崩效应
当突发流量（如秒杀、行情暴涨、外部攻击）超过系统处理能力时，若不加限制，会导致：
- 数据库连接池耗尽，请求排队超时。
- CPU/内存持续飙升，触发 GC 或 OOM。
- 单节点崩溃后，重试流量转移到其他节点，引发级联故障。
- 最终导致整个服务集群不可用（雪崩）。
金融案例：某券商在 2020 年行情峰值时，未对行情推送 API 做限流，导致网关线程池打满，所有交易接口（包括下单、撤单）全部超时，造成大面积交易中断。
2.2.2 保障资源公平性
在多租户、多业务线共享同一套 API 网关或数据库连接池时，限流可以防止某个“吵闹邻居”耗尽公共资源，确保所有调用方都能获得合理的服务配额。
| 场景 | 无限流时的后果 | 有限流时的效果 |
|---|---|---|
| 行情推送 vs 交易下单 | 行情请求占满带宽，下单请求被丢弃 | 行情限流 80%，交易保留 20% 带宽 |
| 内部查询 vs 外部客户 | 内部批量查询拖慢客户实时交易 | 内部查询限流 100 QPS，客户交易不限 |
| 测试流量 vs 生产流量 | 压测流量淹没真实用户请求 | 压测流量单独限流，不影响生产 |
2.3 限流与熔断的区别
限流和熔断是两种不同的保护机制，经常被混淆。下表从多个维度进行对比：
| 对比维度 | 限流（Rate Limiting） | 熔断（Circuit Breaker） |
|---|---|---|
| 触发条件 | 请求速率超过预设阈值 | 错误率/超时率超过阈值（如 50% 请求失败） |
| 作用位置 | 通常位于入口（网关、负载均衡） | 通常位于调用方（客户端、RPC 框架） |
| 响应方式 | 直接拒绝（返回 429 Too Many Requests） | 快速失败（返回降级结果或抛出异常） |
| 恢复机制 | 窗口期过后自动恢复 | 半开状态探测，成功后关闭熔断器 |
| 保护目标 | 保护自身不被流量冲垮 | 保护自身不被下游故障拖垮 |
| 典型场景 | 秒杀、爬虫、DDoS 防护 | 数据库宕机、第三方服务超时 |
一句话区分：限流是“我扛不住了，你别再来了”；熔断是“下游坏了，我先不调了”。
2.4 限流与熔断的协同关系
在金融压力测试架构中，限流和熔断通常配合使用，形成多层防护：
2.5 限流算法选型参考
在金融压力测试中，常见的限流算法及其适用场景如下：
| 算法 | 原理 | 优点 | 缺点 | 金融场景推荐 |
|---|---|---|---|---|
| 固定窗口 | 统计每个时间窗口内的请求数 | 实现简单，性能高 | 窗口边界流量突刺 | 非核心监控接口 |
| 滑动窗口 | 将窗口细分为多个小格，滑动统计 | 平滑，边界流量控制好 | 内存占用略高 | 交易类核心接口 |
| 令牌桶 | 匀速放入令牌，请求消耗令牌 | 允许突发，平滑限流 | 需要调整令牌速率和桶大小 | 行情推送、消息队列 |
| 漏桶 | 请求进入队列，匀速流出 | 强制平滑，无突发 | 无法应对突发流量 | 数据库连接池保护 |
压力测试建议：在压测脚本中，应同时验证限流触发时的正确响应（HTTP 429 + Retry-After 头）以及熔断触发时的降级返回，确保生产环境下的用户体验可控。