深度指南
API 速率限制队列模拟器：流量高峰时第三方限制会让您付出什么代价
行业管理层分析
许多产品都建立在别人的 API 之上：邮件发送、地图、支付、数据补全、语言模型。服务商用速率限制来保护自己，也就是每秒请求数的上限。在平均水平的日子里，没有人会注意到这个限制。麻烦在于，客户并不是按平均水平到来的。他们会在一次产品发布、一阵早高峰或一次批量导入中涌入，在那几分钟里，您的需求可能是平均值的好几倍。无法发出的任务在您的队列中等待，而等得太久的队列就会变成失败。
这个问题的结构，是一个面对固定服务速率的队列。当到达速率远低于限制时，等待几乎为零。当利用率接近百分之百时，等待会增长得非常快，而一旦需求超过限制，积压就会无休止地增长，直到超时把它截断。这就是为什么这种关系不是线性的：接近限制时，流量多几个百分点，就可能让无害的队列变成一股失败的洪流。您所允许的超时，决定了您能吸收多少这样的等待。
多米诺模型分五步展开。任务量和峰值系数决定相对于限制的峰值负载。峰值负载决定队列等待。等待相对于超时的比例，决定失败任务的占比。失败任务会带来收入损失、服务赔偿、重试和工单方面的成本。扣除算力、套餐和固定成本之后，剩下的就是利润。峰值系数的小幅上升，就可能让第一个方框变红，而失败的成本会在第四个方框中显现，早在有人注意到月度总额下降之前。
冰山把套餐的成本与失败的成本区分开来。水面之上是算力和 API 套餐本身。水面之下是从未完成的任务所损失的收入、根据服务协议应付的赔偿、在再次失败的重试上白白消耗的算力，以及客户在东西没有送达时提交的支持工单。合在一起，它们往往超过本可以避免这些问题的更高档套餐的价格。请用模拟器找出失败的损失开始超过升级成本时的负载。
公式与方法论蓝图
该模型按月计算。繁忙时段的到达速率等于任务数除以一个月的秒数，再乘以峰值系数。队列被视为单一服务台，速率限制即其服务速率。利用率等于到达速率除以限制。等待时间超过超时的峰值任务占比，根据队列尾部估算；当需求超过限制时，再加上过载的占比。大约三分之一的任务在繁忙时段到达，同时任何时候都存在一个很小的基础错误率。
- 峰值到达速率
- λ = 任务数 ÷ 2,592,000 × 峰值系数
- 根据月度任务量得出的繁忙时段每秒请求数。
- 利用率
- ρ = λ ÷ 限制
- 高峰时使用的速率限制比例。高于 100% 时队列会无限增长。
- 峰值失败占比
- 过载 + (1 − 过载) × ρ × e^(−限制 × (1 − ρ) × 超时)
- 因过载被丢弃的任务，加上等待时间超过超时的任务。
- 失败任务
- F = 任务数 × (35% × 峰值失败 + 0.4%)
- 繁忙时段的失败，加上任何时候都存在的少量基础错误。
- 净利润
- 净额 = (任务数 − F) × 单价 − 算力 − 套餐 − 重试 − 赔偿 − 工单 − 固定成本
- 每月的结果。临界点就是它降到零的位置。
层层传导的弹性
速率限制和峰值系数是弹性最大的输入项，因为失败占比取决于利用率离百分之百有多近。在这个边缘附近，微小的变化会产生巨大的影响，而在远离它的地方，变化几乎无关紧要。每个任务的收入和任务量决定整条收入线的规模。当负载刚好低于限制时，超时的影响最大，此时耐心可以把一条长队列转化为已完成的工作。
三个真实案例研究
白手起家的初创者
远低于限制的早期产品
一款产品在小型套餐上每月发送一百五十万个任务，峰值适中，超时设置宽裕。每个任务的收入不错，队列很少形成。加载这个案例，可以看到在业务量较小时，较低的限制完全没问题，失败的代价也微乎其微。
处于扩张期的中型市场企业
大型套餐上的高业务量
一个平台在速率限制很高的套餐上每月发送二千八百万个任务。峰值受到控制，利用率保持适中，所以失败很少，套餐只占收入的一小部分。加载这个案例，可以看到当业务量很大时，为余量付费是多么便宜。
黑天鹅危机
营销活动撞上较小的限制
一场营销活动带来一千八百万个任务，峰值是平均值的九倍，而限制为每秒十次请求，超时五秒。利用率超过百分之百，大部分峰值任务失败。加载这个案例，可以看到失败任务、赔偿和重试把整个月的收益抹掉。
行业基准矩阵
| 指标 | 危险区 | 行业平均 | 前 10% 的佼佼者 |
|---|---|---|---|
| 速率限制的峰值利用率 | 高于 95% | 60–80% | 低于 60% |
| 峰值与平均请求量之比 | 高于 7 | 2–4 | 低于 2 |
| 失败或超时的任务 | 高于 4% | 0.5–1.5% | 低于 0.5% |
| 队列等待占超时的比例 | 高于 60% | 10–30% | 低于 10% |
| API 套餐占收入的比例 | 高于 15% | 3–8% | 低于 3% |
变量与杠杆
每月任务数
您的产品每月发送给第三方 API 的任务数量，每个任务对应一次请求。
杠杆: 只有在速率限制和队列能够承载繁忙时段之后才扩大业务量，因为额外的任务会抬高您无法服务的峰值。
峰值与平均值之比
繁忙时段的请求速率是月平均值的多少倍。产品发布、营销活动和批量导入都会提高它。
杠杆: 通过定时批处理、优先级和把导入分散到全天来削平峰值，因为失败是由繁忙时段决定的。
速率限制
API 套餐允许您每秒发送的请求数。超出的请求会在您的队列中等待。
杠杆: 把下一档套餐的价格与它能消除的失败相比较；在接近满载时，限制的小幅提高就能避免很大一部分超时。
队列超时
一个任务在队列中最多可以等待多久，之后用户或系统会放弃，任务失败。
杠杆: 为不紧急的工作设置更长的超时，把较短的超时留给交互式任务，因为耐心就是免费的容量。
每个任务的收入
一个已完成任务的平均收入，例如用量费用，或它所代表的订阅费份额。
杠杆: 提高价格或增设优先级档位，让最需要占用速率限制的任务也为此买单。
如何使用本模拟器
- 1输入每月任务数，并根据请求日志估算您的峰值与平均值之比。
- 2设定当前套餐的速率限制以及您的产品所允许的超时。
- 3加入每个已完成任务的收入。
- 4点击“找出我的临界点”，查看多大的流量或多低的限制会把利润推到零。
- 5在 24 个月内，比较当前套餐与升级加削平峰值的方案。
应避免的错误
- 按平均流量做规划。限制是在最繁忙的几分钟里被触及的，所以请根据峰值而不是月平均值来确定套餐规模。
- 重试时不做退避。重试会给本已在失败的队列增加负载，可能把缓慢的一小时变成一次宕机。
- 只把失败的任务看作损失一笔销售。赔偿、支持工单和浪费的算力，花费可能超过这个任务所赚的钱。
- 忽视增长。一个按今天业务量刚好合适的套餐，在一个好季度之后就可能处于百分之九十五的利用率。
常见问题
为什么接近限制时队列会变得这么糟？
因为小的随机突发在下一波到来之前已无法被清空。随着利用率逼近百分之百，等待时间会陡然增长。
更长的超时一定更好吗？
对交互式任务不是，因为用户不会等待。对后台工作而言它是免费的容量，因为耐心可以吸收突发流量。
我是不是直接买最大的套餐就行？
很少如此。请把下一档的价格与它能消除的失败相比较，并先考虑削平峰值，这往往更便宜。
为什么要把一部分任务计为高峰任务？
真实流量是突发性的。模型假设大约三分之一的任务在繁忙时段到达，这是一个偏保守的通用数值，您可以通过修改峰值系数来调整。
如何找到临界点？
点击“找出我的临界点”。工具会把每个输入项推向更差的一端，并报告月利润降到零时的数值。
这个结果有多准确？
这是假设简单的教学排队模型，不构成工程或财务建议。请测量您真实的请求日志，并核对服务商当前的限制和价格。
这是一个带有明确假设的教育性规划模型，不构成财务、税务或法律建议。请将输入替换为您自己的数据，并就重要决策咨询合格的专业人士。