限流的不同API，用户的阈值的设计

目录

• • 一、先给结论式框架（你可以直接拿去用）
  • 二、第一步：确定“系统真实可承载能力”（最关键）
    • 1. 你必须先有压测结果
    • 2. 生产一定要留安全余量
  • 三、API 级限流：先做“总闸门”
    • 建议区间
    • 示例
  • 四、租户（Tenant）限流：防“一个大户拖死所有人”
    • 原则
    • 常见三种定法
      • 1. 平均分摊（最简单）
      • 2. 分层（生产最常见）
      • 3. 动态配额（成熟系统）
  • 五、用户（User）限流：主要是“防滥用”
    • 用户限流不是为了保护系统，而是为了：
    • 常见定法（比租户低一个数量级）
  • 六、一个完整的生产示例
    • 规则组合：
  • 七、非常重要的一条经验（很多系统踩坑）
  • 八、一句话总结
• 如何估算不同API压测的比例
  • 一、先澄清一个常见误区
  • 二、生产“API 比例压测”的总体流程（标准做法）
    • 全流程概览
  • 三、第一步：从生产数据“反推真实 API 比例”
    • 必须基于真实生产数据（不是拍脑袋）
    • 至少要拿到三类数据：
      • 示例（真实常见）
  • 四、第二步：对 API 做“负载分组”，而不是只看比例
    • 按资源模型分组
  • 五、第三步：构建“混合负载模型”
    • 关键不是工具，是“权重”
  • 六、第四步：压测时一定要“逐级升压 + 稳态观察”
    • 正确节奏
  • 七、第五步：不要忘了“异常流量注入”
    • 1. 读多写少 → 写突增
    • 2. 慢 API 被放大
    • 3. 重试风暴
  • 八、一个非常实用的经验法则
  • 九、压测结果如何反推限流
  • 十、一句话总结

【结论】

限流阈值 = 系统可承载能力 × 安全系数 × 维度分摊系数

其中：
系统可承载能力：压测得出
安全系数：0.6～0.8（生产常用）
维度分摊系数：API / 租户 / 用户的分配比例

生产流量分析
   ↓
API 分组 & 权重建模
   ↓
混合负载模型设计
   ↓
比例压测（逐级升压）
   ↓
找瓶颈 & 反推限流阈值

这是一个没有“统一数值答案”，但有一套“可落地方法论”的问题。在生产环境里，限流阈值不是拍脑袋定的，而是一个能力约束 + 业务目标 + 风险容忍度共同作用的结果。

下面我给你一套在真实生产环境可执行的定标方法，并分别说明 API / 用户 / 租户 三类限流该如何定。

---

一、先给结论式框架（你可以直接拿去用）

限流阈值 = 系统可承载能力 × 安全系数 × 维度分摊系数

其中：

• 系统可承载能力：压测得出
• 安全系数：0.6～0.8（生产常用）
• 维度分摊系数：API / 租户 / 用户的分配比例

---

二、第一步：确定“系统真实可承载能力”（最关键）

1. 你必须先有压测结果

不要先谈限流规则，先回答一个问题：

这个 API 在稳定 SLA 下，最大能扛多少 QPS？

压测目标不是“压挂”，而是找到：

• P99 延迟开始明显劣化的点
• 错误率开始抬头的点

例如：

• 某 API：

  • 1500 QPS：P99 = 120ms（稳定）
  • 1800 QPS：P99 = 400ms（抖动）
    → 可承载能力 ≈ 1500 QPS

---

2. 生产一定要留安全余量

经验值：

场景	安全系数
内部系统	0.7～0.8
对外 API	0.6～0.7
核心链路	≤ 0.6

例如：

• 1500 × 0.7 ≈ 1050 QPS
  → 这是你限流系统里的“总预算”

---

三、API 级限流：先做“总闸门”

API 限流是最重要、也是最优先的

建议区间

• API 总 QPS：系统预算的 80%～100%

• 剩下的留给：

  • 重试
  • 抖动
  • 突发流量

示例

• 系统预算：1050 QPS

• 单核心 API：

  • 限流：900 QPS

• 非核心 API：

  • 限流：200～300 QPS

---

四、租户（Tenant）限流：防“一个大户拖死所有人”

原则

• 租户限流是 公平性保护
• 一定要 低于 API 总限流

常见三种定法

1. 平均分摊（最简单）

tenant_qps = api_qps / 活跃租户数

例如：

• API = 900 QPS
• 活跃租户 = 30
  → 每租户 ≈ 30 QPS

适合：

• 租户规模接近
• 内部系统

---

2. 分层（生产最常见）

租户级别	QPS
S 级	200
A 级	80
B 级	20

适合：

• 商业化 SaaS
• SLA 不同

---

3. 动态配额（成熟系统）

• 基础保障 + 弹性上限

tenant_limit = base + burst

例如：

• base = 20 QPS
• burst = 50 QPS（短时）

---

五、用户（User）限流：主要是“防滥用”

用户限流不是为了保护系统，而是为了：

• 防爬虫
• 防脚本
• 防刷接口

常见定法（比租户低一个数量级）

场景	建议
登录 / 下单	5～10 QPS
查询类	10～30 QPS
写接口	1～5 QPS

用户限流一定 < 租户限流 < API 限流

---

六、一个完整的生产示例

假设：

• 压测能力：1500 QPS
• 安全系数：0.7 → 1050 QPS

规则组合：

1. API 总限流：900 QPS

2. 租户：

   • S：200 QPS
   • A：80 QPS
   • B：20 QPS

3. 用户：

   • 单用户：10 QPS

最终效果：

• 高峰不会打爆系统
• 大客户不会挤死小客户
• 单用户无法恶意刷接口

---

七、非常重要的一条经验（很多系统踩坑）

限流阈值一定要“线上可调、分钟级生效”

否则：

• 一次营销活动
• 一次外部依赖抖动
  就会把你拖入发布地狱。

---

八、一句话总结

生产限流不是“限多少”，而是“谁先被挡、挡到什么程度”。
API 保系统，租户保公平，用户防滥用。

如果你愿意，下一步我可以帮你：

• 把这些规则 映射成 Sentinel FlowRule（含集群模式）
• 或给你一套 压测 → 定阈值 → 上线 → 动态调参 的标准流程文档

如何估算不同API压测的比例

这是一个非常成熟、也非常容易被低估的生产问题。
核心结论先给出来：

生产压测不是“把所有 API 拉满”，而是“按真实流量比例回放负载”。

下面我按可执行的方法论来讲，而不是停留在工具层。

---

一、先澄清一个常见误区

错误做法（非常常见）：

• 对每个 API 单独压到极限
• 然后简单相加，认为系统能扛住

为什么错：

• 生产是 混合流量

• 不同 API：

  • CPU / IO / DB / Cache 消耗模型完全不同

• 混合负载下，瓶颈会提前出现

---

二、生产“API 比例压测”的总体流程（标准做法）

全流程概览

生产流量分析
   ↓
API 分组 & 权重建模
   ↓
混合负载模型设计
   ↓
比例压测（逐级升压）
   ↓
找瓶颈 & 反推限流阈值

---

三、第一步：从生产数据“反推真实 API 比例”

必须基于真实生产数据（不是拍脑袋）

数据来源（优先级）：

1. API Gateway / Nginx 访问日志
2. APM（SkyWalking / Zipkin / Pinpoint）
3. Sentinel / Prometheus 指标

至少要拿到三类数据：

• 每个 API 的 QPS 占比
• 每个 API 的平均 RT / P99
• 每个 API 的资源特征（DB / Cache / RPC）

示例（真实常见）

API	占比	P99
查询列表	55%	120ms
查询详情	25%	180ms
下单	10%	350ms
支付	5%	500ms
其他	5%	—

---

四、第二步：对 API 做“负载分组”，而不是只看比例

这是很多团队没做，导致压测结果失真的地方。

按资源模型分组

而不是按业务名字：

分组	特征
Read-Light	只走缓存
Read-Heavy	DB Join / 大表
Write	事务 / 锁
External	调外部系统

你会发现：

• 10% 的 API 可能吃掉 50% 的 DB

---

五、第三步：构建“混合负载模型”

关键不是工具，是“权重”

一个典型混合模型长这样：

总 QPS = 1000

查询列表    55% → 550 QPS
查询详情    25% → 250 QPS
下单        10% → 100 QPS
支付         5% → 50 QPS
其他         5% → 50 QPS

⚠️ 注意：

• 比例保持不变
• 总 QPS 逐步升高（300 → 500 → 800 → 1000 → 1200）

---

六、第四步：压测时一定要“逐级升压 + 稳态观察”

正确节奏

1. 升到 300 QPS，稳定 5–10 分钟

2. 升到 500 QPS，稳定

3. 升到 800 QPS，稳定

4. 直到出现：

   • P99 明显抬升
   • Error rate > SLA
   • 某资源（DB / CPU）饱和

这个点才是“系统真实能力”

---

七、第五步：不要忘了“异常流量注入”

生产一定不是完美比例。

你必须额外测三种情况：

1. 读多写少 → 写突增

• 写接口比例从 10% → 30%
• 看锁、事务、队列

2. 慢 API 被放大

• 人为延长一个慢 API
• 看线程池、连接池耗尽

3. 重试风暴

• 模拟下游超时 + 重试
• 这是很多系统真正崩的原因

---

八、一个非常实用的经验法则

混合压测下得到的极限 QPS，通常比“单 API 极限相加”低 30%～50%。

这就是为什么：

• 限流一定要基于混合压测结果
• 而不是单接口压测结果

---

九、压测结果如何反推限流

你最终得到的是：

• 总系统安全 QPS
• 各 API 在混合场景下的安全占比

然后反推：

API_limit = 总_limit × API_比例 × 安全系数

---

十、一句话总结

生产压测的本质是：用“真实比例 + 真实资源模型”去逼近真实世界，而不是把工具跑满。

如果你愿意，下一步我可以：

• 给你一个 JMeter / k6 混合比例压测模型示例
• 或帮你设计一套 压测 → Sentinel 限流阈值反推表

你更想看哪一个？