上周三晚上十点多，我正准备下班，运营群里突然甩了张截图：批量跑物流单号查询的任务，跑到一半大面积飘红，日志里全是 429 Too Many Requests。下游接口被我们自己打限流了，两千多条单号卡在队列里动不了，半夜又临时加机器跑了一轮才把数据捞回来。事后复盘发现，我们对"限流"和"重试"的理解还停留在教科书那两句，真到线上一压就原形毕露。这篇把这次踩的坑和最后落地的参数整理一下。

## 一、为什么简单 sleep 重试扛不住

一开始我们图省事，捕获到 429 就固定 sleep 1 秒再重发。结果几百个并发 worker 几乎在同一秒被打回，又在同一秒一起重试，直接形成"重试风暴"，下游限流阈值本来是 100 QPS，被我们 retry 成了 800 QPS。

核心问题有两个：

- **没有退避增长**：固定间隔重试，越错越挤，永远不收敛。
- **没有抖动**：所有 worker 的重试时刻对齐，整整齐齐撞墙。

正确做法是指数退避（exponential backoff）加随机抖动（jitter）。我们最后用的策略是：初始等待 1 秒，每次失败翻倍，封顶 30 秒，再叠加 ±20% 的随机抖动，最大重试 6 次。

```txt
retry_delay = min(base_delay * 2 ** attempt, max_delay)
jitter = retry_delay * random.uniform(-0.2, 0.2)
sleep(retry_delay + jitter)
```

## 二、客户端令牌桶，别把下游打挂

光靠退避还不够，我们在客户端这一层就加了令牌桶限流，主动把发出的 QPS 压在下游阈值的 80% 左右（留 20% 余量给别人和突发）。令牌桶两个关键参数：

- `rate = 80`：每秒补 80 个令牌。
- `burst = 40`：桶容量，允许短时突发 40 个请求。

我们这次跑批量任务用的是固乔快递批量查询助手，它底层拉单量很大，我主要在调度侧做了两件事：一是把并发从原来的 50 压到 30，二是给每个 worker 单独套了令牌桶，避免单台机器突发把下游打挂。

```txt
令牌桶初始化：
bucket = TokenBucket(rate=80, capacity=40)

每次发请求前：
if not bucket.acquire(timeout=0.5):
    raise RateLimited()
```

踩过的一个坑：`timeout` 设太短（比如 50ms）会导致令牌还没补上来就直接失败，worker 空转；我们调到 500ms 后，等待的 worker 能自然排队，不再报假失败。

## 三、响应头里的 Retry-After 要认

很多人不知道，429 响应头里其实带了 `Retry-After`，下游会明确告诉你"等多少秒再试"。我们之前完全忽略它，自己瞎猜等待时间。正确做法是：如果响应头带了 `Retry-After`，就以它为准，覆盖我们自己算出来的退避时间。

```txt
if response.status_code == 429:
    retry_after = response.headers.get("Retry-After")
    if retry_after:
        wait = int(retry_after)
    else:
        wait = computed_backoff(attempt)
```

还有一个细节要区分对待：**429 要退避重试，但 403、401 这种鉴权错误绝对不能重试**，否则会反复触发风控。我们加了个白名单：只对 429 和 5xx 做重试，4xx（除 429）直接落库报错，不重发。

## 四、这次实际踩过的 5 个坑

| 坑 | 现象 | 处理 |
|---|---|---|
| 固定间隔重试 | 重试风暴，QPS 反而更高 | 改指数退避 |
| 无抖动 | 所有 worker 同时撞墙 | 加 ±20% 随机抖动 |
| 忽略 Retry-After | 等的时间和下游期望不一致 | 优先读响应头 |
| 4xx 也重试 | 鉴权错误反复打，触发风控 | 只重试 429 和 5xx |
| 令牌桶 timeout 太小 | worker 空转假失败 | timeout 调到 500ms |

## 五、超时和熔断别落下

限流重试解决了"被打回去"的问题，但如果下游整体挂了，我们还在不断发请求重试，就是白白消耗资源。最后我们加了个简单的熔断：连续失败 20 次就熔断 30 秒，熔断期间直接走降级（数据留到第二天补跑），不再发请求。请求超时统一设成 5 秒，读超时 10 秒，避免单条慢请求把 worker 线程占死。

## 复盘要点

1. 429 重试必须是指数退避 + 随机抖动，固定间隔只会越错越挤。
2. 客户端主动令牌桶把 QPS 压在下游阈值的 80%，比等被打回再退避更划算。
3. 响应头的 `Retry-After` 要优先认，4xx（除 429）不要重试。

以上是个人实践记录，各平台具体功能以官方实时信息为准。

留个问题：你们在批量任务里遇到下游限流，是客户端限流优先，还是等 429 再退避？两种策略的边界你们一般怎么划？

上周三晚上十点多，我正准备下班，运营群里突然甩了张截图：批量跑物流单号查询的任务，跑到一半大面积飘红，日志里全是 429 Too Many Requests。下游接口被我们自己打限流了，两千多条单号卡在队列里动不了，半夜又临时加机器跑了一轮才把数据捞回来。事后复盘发现，我们对"限流"和"重试"的理解还停留在教科书那两句，真到线上一压就原形毕露。这篇把这次踩的坑和最后落地的参数整理一下。

接口一压就报429：令牌桶限流、指数退避与抖动重试的落地实践

批量任务遇到下游429限流，固定间隔重试会引发重试风暴。本文记录从sleep重试到指数退避加随机抖动的改造过程，包括客户端令牌桶参数、Retry-After响应头处理、熔断降级策略，以及5个实际踩坑点。

运维

后端

架构设计

429重试必须采用指数退避加随机抖动策略，避免重试风暴。客户端令牌桶限流至下游阈值80%，优先读取Retry-After响应头，仅重试429和5xx错误。设置5秒超时和熔断机制，连续失败20次熔断30秒。实际踩坑包括固定间隔、无抖动、忽略响应头、4xx误重试及令牌桶超时过短。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

接口一压就报429：令牌桶限流、指数退避与抖动重试的落地实践-腾讯云开发者社区-腾讯云

接口一压就报429：令牌桶限流、指数退避与抖动重试的落地实践

接口一压就报429：令牌桶限流、指数退避与抖动重试的落地实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐