大促零点接口被限流：第三方 API 的配额、退避与降级实战

零点零三分，监控屏上的订单曲线像被点着了一样往上窜。零点零七分，第一个 429 回来了——快递公司的打单接口开始限流。零点十二分，平台订单拉取接口也开始间歇性拒绝。打包台那边，十几个工人站着等面单，打印机安静得让人心慌。IT 小哥一边重启任务一边在群里喊"别慌"，但所有人都看得出来他在慌。那天晚上我们靠人工抄单撑了两个小时，第二天客服的电话就没停过。

这不是谁家系统写得烂，这是大促的常态：你的系统平时一天调人家接口几万次，大促一晚上能干到平时的十几倍。第三方 API 都有配额，配额一爆，对方不会跟你商量，直接拒绝。仓库这边单子下不来、面单打不出、库存推不上去，整条链路卡在别人的服务器前面。这篇文章不讲概念，讲大促前你真正该干的几件事。

配额这东西，平时没人看，大促夜要命

第一件事：把你调的每一个第三方接口的配额找出来，白纸黑字写下来。快递打单、平台拉单、ERP 回传库存、短信通知——每个接口的限流规则都不一样，有的是按分钟，有的是按天，有的是按账号，有的是按 IP。别凭印象，"我记得好像是一分钟几百次"——去翻官方文档，把数字抄下来，标好单位。

第二件事：测算。拿去年大促（或者今年 618 这类小考）的峰值订单量，乘以 1.5 的系数，算出零点那一个小时你会发起多少次调用。注意是调用次数，不是订单数——一单可能要调三四次接口（查运费、打单、回传、推库存），这个倍数很多人第一次算都会吓一跳。算出来的数字跟配额一比，缺口就摆在桌面上了。

第三件事：提前申请提额。主流平台和快递公司都支持大促前提额申请，但要走流程、要排期，提前两到三周动手是常识。申请时别只报一个数字，把你的测算过程附上——对方审核的人也是工程师，你把"峰值小时调用量、持续时长、接口分布"写清楚，通过率比只写"请提高配额"高得多。我吃过一次亏：某年只给主力快递商提了额，忘了备用线路，结果大促夜主力线路抖了一下切到备用，备用配额瞬间爆掉，等于白准备了。提额要覆盖所有你会实际调用的账号和线路，包括备用的。

光申请还不够，提额批下来之后要做一次全链路压测。压测的目标不是把系统压垮，而是验证三件事：提额真的生效了（别信邮件，实际打一次看返回头里的剩余额度）；你的队列和消费速度跟得上峰值；告警水位设置得合理。压测安排在大促前一周左右，太早了业务数据对不上，太晚了发现问题没时间改。压测那天把第三方接口的负责人也拉进群，万一压测把对方测试环境打挂了，有人能立刻响应——别问我怎么知道的。

大促期间仓库打包台前堆积的订单包裹

重试不能当无头苍蝇

配额申请了不代表万无一失。大促夜总有意外：对方服务器抖动、网络丢包、某个接口临时降级。这时候重试逻辑怎么写，直接决定你是平稳滑过去还是把对方彻底打挂。

千万别写固定间隔的无脑重试——所有失败请求每 5 秒重试一次，等于把洪峰原样再拍回去，对方刚缓过一口气又被拍死。正确做法是指数退避：第一次等 1 秒，第二次 2 秒，第三次 4 秒，往上翻倍，再加一点随机抖动。抖动这个细节很多人省掉，但它很关键：没有抖动，所有客户端会在同一时刻重试，形成新的同步洪峰。有抖动，重试请求就被打散了。

退避还要设上限：最多重试几次、总共等多久，超过就认栽走降级。无限重试是最危险的写法，我见过一个系统重试队列越积越长，把自家应用服务器的内存先吃光了，对方接口还没恢复，自己先倒了。重试次数和超时时间，压测的时候就要定下来写死在配置里，大促夜现场改配置是赌博。

再往上一层是熔断。重试是"对方可能只是抖一下，我等等再试"；熔断是"对方明显已经不行了，别再去敲门了"。做法很简单：连续失败超过阈值（比如 10 次），直接熔断一段时间，期间所有请求走降级逻辑，不再发往对方。熔断的好处是给对方留恢复的空间，也给自己的系统省资源。熔断阈值和恢复策略（是定时半开试探，还是人工手动恢复）同样要在压测时定好。大促夜值班的人只需要看懂熔断面板上的红绿灯，不需要理解背后的算法。

另外，把"读"和"写"分开看。拉取订单这种读操作，重试代价小；打单、扣库存这种写操作，重试前先想清楚幂等性——同一单打两次面单，是会去重还是会打出两张？面单费算两次吗？这些问题平时不问，大促夜会教你做人。幂等键（idempotency key）这东西，凡是涉及钱和实物的写接口都应该带上，别等到对账时才发现重复。

真扛不住了，学会体面地降级

退避和队列是争取时间，降级是承认现实：对方接口就是不通了，我的仓库不能停。降级预案要在大促前写好、演练过，而不是零点十二分现想。

最常用的一招是"先接单、后补推"。平台订单拉不下来？先让仓库按本地缓存的订单生产，面单用备用快递商打，等接口恢复再补推数据。库存回传堵住了？先保证出库，把库存差异记下来，事后对账手工调。核心思想就一条：保住"货能发出去"这条生命线，非实时的动作都可以滞后。

降级还要分档。轻度降级：关掉非核心调用，比如短信通知改成大促后再补发，省出配额给打单这种保命接口。中度降级：切备用线路，哪怕备用线路的时效慢一点、贵一点。重度降级：转人工——打印空白面单手写、Excel 导单。听起来土，但真到那一步，有土办法比干瞪眼强。每一档的触发条件和操作步骤，写成一页纸贴在 IT 值班的桌上，大促夜没人有脑子现场思考。

预案写完一定要演练一次，而且是真演练：挑个业务低峰，把某个接口的调用掐掉（或者 mock 成 429），看团队能不能按预案在 15 分钟内切到降级模式。演练时一定会发现预案里的漏洞——比如备用快递商的账号密码没人记得、手工导单的模板版本号不对、值班表上的人那天空不出来。把这些坑在演练时踩完，大促夜才能睡得着。没演练过的预案，等于没有预案。

队列削峰是降级的底座。平时直连第三方接口的调用，大促前全部改成先进本地队列、再按配额匀速消费。队列长度设告警水位：超过多少就自动触发轻度降级。这个改造平时做，不要堆到大促前一周——队列本身的稳定性和监控，也需要时间验证。