限流怎么测
限流测试验证系统在用量异常时的自保行为：阈值内正常放行、超出后按策略拒绝（HTTP 常见 429，带 Retry-After）、窗口滚动后恢复、多维度（按 IP、用户、接口、全局）互不串扰。重点覆盖窗口边界——刚好超一档、跨窗口瞬间的并发。常见算法：固定窗口、滑动窗口、令牌桶、漏桶。
基本信息
| 常见返回 | 429 Too Many Requests 加 Retry-After 秒数 |
|---|---|
| 响应头 | X-RateLimit 系列自定义头：上限、剩余、重置时间 |
| 限流维度 | 全局、IP、用户、接口、租户，多数系统组合使用 |
| 算法差异 | 固定窗口简单但对窗口边界突发不友好；令牌桶更平滑 |
| 测试手段 | 并发脚本打阈值、等待窗口滑动、检查余量头 |
| 分层验证 | 网关层与应用层可能各自限流，两层分别测 |
阈值探测示例
阈值探测示例
for i in $(seq 1 120); do
curl -s -o /dev/null -w "%{http_code}\n" \
-H "Authorization: Bearer $TOKEN" https://api.example.com/v1/query
done | sort | uniq -c # 统计 200 与 429 的数量分布是否符合阈值典型使用场景
- 网关限流上线前的策略验收
- 防刷验证：短信、登录验证码这类高价值接口
- 多租户公平性：单个租户刷满不拖垮其他租户
- 恢复验证：窗口滑动或令牌桶回填后应恢复放行
- 客户端配合：验证 429 后按 Retry-After 退避重试
- 容量测试配套：压测时确认限流不误伤正常流量模型
测试点与预期
| 测试点 | 预期 | 核对 |
|---|---|---|
| 阈值内请求 | 全部正常 200 | 余量头递减正确 |
| 刚好超出阈值 | 超额部分 429 | 边界判定精确 |
| 窗口滚动后 | 恢复 200 | 重置时间与头一致 |
| 不同维度并发 | 互不干扰 | 单用户不限死全局 |
| 无 Retry-After | 禁止 | 客户端无法合理退避 |
用并发而不是串行探阈值：串行请求的间隔可能让固定窗口永远测不爆，测出来的阈值没有意义。
把临界判定写进用例：第 N 个请求通过、第 N+1 个被拒，多测一个少测一个都会在复盘时扯皮。
测试环境开了限流白名单或限流关闭，测试全绿但上线即炸：先确认测试环境的限流开关与线上一致。