通用面试：HTTP 429 与 Retry-After 如何指导客户端重试？
题干与适用场景
一个 API 在流量突增后返回 429 Too Many Requests。面试官希望你说明这个状态码表达的责任边界、如何读取 Retry-After、哪些请求可以重试，以及怎样避免客户端把过载放大成级联故障。
面试官考察点
- 是否理解 429 是限流信号，不等同于服务端永久故障。
- 能否正确处理 Retry-After 的两种格式和缺失情况。
- 能否结合幂等性、请求截止时间和业务副作用决定重试。
- 能否用指数退避、抖动、预算和限流保护服务。
回答前需要澄清的问题
- 429 是按用户、令牌、租户、IP 还是共享资源限流？
- 响应是否包含 Retry-After，客户端时钟是否可信？
- 请求方法和业务操作是否幂等，是否有幂等键？
- 是否存在总截止时间、最大重试次数和重试预算？
- 服务端是否同时返回配额、剩余量或请求 ID 供观测？
30 秒回答框架
我会先把 429 当作限流反馈，读取 Retry-After；它可以是秒数，也可以是 HTTP 日期。等待时间取服务端建议与客户端退避策略的安全上界，并加入抖动。只有幂等或有幂等键的操作才自动重试，同时受截止时间、次数和预算约束；没有 Retry-After 时使用带抖动的指数退避，持续 429 则停止并交给上层处理。
分步骤深入解答
第一步：确认 429 的语义
RFC 6585 将 429 定义为在给定时间内请求过多，响应可以包含 Retry-After。它通常表示客户端需要降低速率，不能简单当成 500 立即重试。
第二步：解析 Retry-After
Retry-After 可以是非负整数秒，也可以是 HTTP 日期。解析日期时使用响应的 Date 或可信时钟估算等待时间，并对负值、过大值和格式错误设置边界。
Retry-After: 8
Retry-After: Wed, 02 Aug 2026 02:00:00 GMT第三步：判断操作是否可安全重放
GET、HEAD 等安全方法通常可以重试；写操作需要确认幂等语义、幂等键和服务端去重能力。即使方法相同，也要考虑支付、发信或任务创建等业务副作用。
第四步：计算等待与退避
优先遵守服务端 Retry-After，再叠加客户端的指数退避上限和随机抖动。抖动避免大量客户端在同一秒醒来；等待必须受请求截止时间约束，不能无限延长用户请求。
第五步：限制重试放大
设置每请求最大次数、全局重试预算和并发上限。对持续 429 的资源降低发送速率，必要时使用本地队列或熔断，让正常流量不被重试占满。
第六步：区分客户端与服务端动作
服务端应提供明确限流信号和可观测字段；客户端负责尊重信号、退避和停止。若资源已恢复，逐步放量，避免所有客户端同时恢复造成第二次尖峰。
第七步：记录结果并改进
记录 429 比例、Retry-After 分布、最终成功率、重试次数和截止时间放弃数。用这些数据调整配额、客户端预算和告警，而不是只把 429 当成单次请求失败。
高质量示范回答
我会先确认 429 的限流维度和响应头。如果有 Retry-After: 8，客户端至少等待八秒；如果是 HTTP 日期，就用可信时钟换算并限制最大等待。对于带幂等键的订单查询可以自动重试，创建扣款这类没有去重保证的操作则交给业务层确认。退避采用指数上限加随机抖动，设置每请求三次、全局重试预算和总截止时间。连续 429 时降低并发并暂停队列，不让重试放大过载。监控记录 429 率、等待时间和最终成功率，用于调整配额与告警。
常见错误
- 把 429 当成 500，收到后立即密集重试。
- 只支持整数 Retry-After，忽略 HTTP 日期格式。
- 不区分幂等读操作和有副作用的写操作。
- 没有截止时间、预算或并发上限，导致重试无限增长。
- 所有客户端使用固定等待时间，形成同步重试尖峰。
追问及应对
追问一：没有 Retry-After 时等待多久？
使用带随机抖动的指数退避，并设置最大等待、重试次数和总截止时间。根据 429 比例和服务配额持续调整，而不是采用固定常数。
追问二：HTTP 日期早于当前时间怎么办？
将等待视为零但仍应用本地退避和抖动，同时记录时钟或服务端生成问题；不能因为日期异常立即发起高并发重试。
追问三：POST 能不能重试？
只有在接口明确幂等、提供幂等键或业务层能去重时才自动重试；否则返回上层，让业务决定是否重新提交。
追问四：多个实例共享一个限额怎么办？
把重试预算和速率控制做成进程间或租户级协调，至少用共享指标反馈降低并发；单实例退避无法防止整体超额。
追问五：如何避免恢复时再次过载？
让队列逐步放量，加入抖动和并发上限，观察 429 与延迟后再增加速率；不要让所有等待请求同时释放。
追问六：哪些指标证明策略有效？
比较 429 率、重试放大倍数、成功率、P95 延迟、最终放弃数和服务恢复时间，并按租户或资源维度切分。