通用面試：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 延遲、最終放棄數與服務恢復時間，並按租戶或資源維度切分。