大促零点订单接口被限流：队列、重试、降级的三件套实战

先说结论：大促零点被平台接口限流，拼的不是谁的服务器更贵，而是谁的订单链路里备齐了三件套——消息队列削峰、指数退避重试、降级预案兜底。少一件，429 都会变成事故；三件齐了，限流来了现场可能都没人察觉。这个坑我见过三次，每次都是同一个剧本。

接口限流不是故障，是平台在喊停

先把认知对齐：HTTP 429 不是系统 bug，是平台在告诉你"我忙不过来了，你慢点"。大促零点，平台要同时服务几十万商家，接口限流是它的自我保护。你这边正确的反应只有一个：退下来，按它的节奏来。

最常见的作死姿势，是把 429 当成普通网络抖动——"没拉到？那我再刷一次"。2023 年双 11，杭州一家美妆代运营仓就是这么干的。他们的 OMS 拉单任务每 5 秒扫一次平台订单接口，零点一过 429 就回来了，任务不退避、不降速，继续 5 秒一次硬刷。平台的限流带惩罚升级：你越刷，它掐得越狠。结果这个应用的调用额度被一路压到最低，接下来 20 多分钟一单都拉不下来，仓库现场几百号人对着空波次干等。凌晨 1 点多额度才慢慢恢复，单子是补回来了，但当晚的截单时间全错过了。这个锅，系统背一半，人背一半。

应对接口限流的三件套，一步一步搭

2024 年 618，佛山一家小家电品牌，自建仓，平时日单几千，大促能翻十几倍。他们提前一个月按三件套把链路改了。零点那波，429 来了三次，每次几分钟，系统自己退、自己等、自己恢复，现场打单节奏一点没乱。值班的兄弟跟我说，他是看监控屏上的退避曲线才知道"哦刚才被限流了"。这就是三件套的价值：把事故变成一条监控曲线。

深夜值班工程师盯着监控大屏上的实时曲线

两个案例放一起看，差别不在技术多难，而在有没有把"被限流"当成正常情况来设计。前者把限流当异常去"重试"，后者把限流当常态去"相处"。下面是三件套的具体搭法，每一步都能直接照着做。

第一步：拉单和消费解耦，中间加队列

这是最关键的一步，也是最容易被"先上线再说"砍掉的一步。

拉单任务只做一件事：从平台接口把订单取下来，取到就扔进队列。它不做审单、不做拆单、不做任何业务逻辑，越傻越好。傻，才不会在限流时添乱。
队列按体量选：大促日单 10 万单以内，Redis Stream 或者云厂商托管的消息队列完全够用；再往上，或者多仓多店铺的，Kafka、RabbitMQ 这类重的才值得。别为了"高大上"上重型队列，运维成本也是成本。
消费端限速：按平台开放文档里限流值的 70%～80% 来设，留出余量。具体数值以各平台官网最新政策为准，文档每年都可能变，大促前夜重新读一遍。
队列深度告警必须接电话通知：积压超过你们 2 小时打单产能，值班手机必须响。只发邮件等于没告警，大促凌晨没人看邮箱。

第二步：重试必须带退避，绝不能固定间隔硬刷

429 回来的第一反应是停，不是冲。先停 1 秒再试，还 429 就等 2 秒，再 4 秒、8 秒，指数往上加，单次等待封顶 5 分钟。这是我们项目里定的规矩，数字可以根据体量调，但"指数"这个形状不能丢。
重试总次数封顶，我们一般设 8 次。超过 8 次还没成功，说明对面是真不行了，这单进死信队列，等人工处理。无上限的重试就是慢性自杀。
分清楚什么值得重试：429、503、网络超时，重试有意义；400 参数错误、401 鉴权失败，重试 100 次也没用，直接进死信，别浪费限流额度。
重试间隔加一点随机抖动（比如正负 20%），避免多个消费者同时醒来，又一起撞上限流墙。

第三步：幂等键先立好，重复消费不翻车

有队列、有重试，就一定有重复投递。幂等是配套工程，不是可选项。

幂等键 = 平台订单号 + 店铺 ID，落库前先查，存在就直接丢弃。键的设计要在写第一行消费代码之前定下来，事后补等于重构。
消费端任何一步异常，都要保证"可重放"：处理到一半崩了，重放一次不能打出两张单、扣两次库存。每个写库动作先问自己一句：跑两遍会怎样？

第四步：降级预案写在纸上，贴在墙上

预案不演练等于没有。大促前夜，四个预案每个都要有人、有步骤：

预案 A（消费跟不上）：保持限速消费，现场加人加波次，用人力换时间。
预案 B（平台接口彻底挂了）：运营从平台后台导出订单 CSV，按固定模板导入 OMS 先打单，财务第二天对账。
预案 C（OMS 也挂了）：纸质拣货单顶上，空白模板提前打印好放现场。
每个预案指定唯一的触发人，不许"到时候再说"。触发条件写死：比如队列积压超过 4 小时产能，预案 B 自动触发。

三条路线的取舍，一张表说清：

路线	优点	代价	适合谁
硬扛：加机器狂刷	实现最快，当天就能改	429 雪崩，越刷限流越狠	大促日单几千、赌平台不掐你的小店
队列削峰	稳，被限流也不丢单	多一套中间件，要人运维	大促必备，单量越大越值
降级人工兜底	永远有退路	慢，容易出错单	极端情况保命，所有人都该有

多说一句：三件套的上线顺序也有讲究，先上队列，再调重试策略，最后写降级预案。顺序反了容易返工——我见过一个客户先写了漂亮的降级 SOP，结果队列没上，限流一来订单直接堆在拉单任务的内存里，机器一重启全丢了。队列是地基，重试是装修，预案是灭火器，地基没打牢，装修再漂亮也没用。

上线前夜 checklist

这个坑我见过三次，所以每年大促前我都会逼客户过一遍这张表，打勾才能睡觉：

□ 平台开放文档的限流说明重新读了一遍，数值记下来了（以官网最新政策为准） □ 消费端限速 = 限流值 × 0.7，已配置，有截图 □ 429 告警接的是电话通知，拨测过，能打通 □ 死信队列有人盯，值班表排到人 □ 降级 CSV 模板实际导过一遍，能正常进 OMS □ 空白纸质拣货单打印好了，在现场 □ 压测跑过 429 场景：模拟限流，看系统是不是真退避，而不是硬刷

顺带把最常见的翻车点也列了，条条都是血泪：重试不带退避、固定间隔硬刷，见过三次；幂等键没立，重复消费打出重复单；告警只发邮件；压测只压正常链路，不压 429 场景；降级预案只存在 PPT 里，没演练过。