文件Experience Cloud KCS

Dynamic Media OpenAPI與Asset Gateway：瞭解並解決API RateLimits

最後更新： 2026年6月22日

當請求模式超過動態速率限制時，高容量API活動可能會傳回HTTP 429錯誤。 問題通常是由高載流量、重複輪詢或多步驟工作流程所造成，這些工作流程會分別計算每個呼叫，而快取可能會在更新可見時延遲。 解決方法著重於確認記錄中的節流、減少不必要的請求、遵循快取行為並套用指數輪詢。 在調整請求模式和重試行為後，穩定回應會傳回。

說明 description

環境：

  • API型資產擷取工作流程
  • 中繼資料擷取工作流程
  • 資產傳遞或閘道整合
  • 發出重複或高容量API請求的使用者端

問題/症狀

  • API端點會傳回間歇性HTTP 429過多請求回應，這可以在應用程式記錄或監控資料中確認，並繫結回受影響的端點。
  • 在高載流量或其他高流量請求期間，此問題較為明顯，這表示在較重的請求負載下發生節流現象。
  • 多步驟工作流程可能會不成比例地受到影響，因為單一操作可能會產生數個計算的API請求，例如搜尋、中繼資料查詢、上傳起始和上傳提交。
  • 重複的使用者端活動（包括輪詢、重試或無法重複使用快取回應）可能會增加請求量，並有助於節流。
  • 資產或內容更新可能會延遲，因為快取的回應最多可保留10分鐘；此行為可透過回應標頭（例如Cache-Control: max-age=600）驗證。
  • 在這些情況下，更新內容可能僅在1到10分鐘後才會顯示，這表示發生快取層延遲，而非個別的API失敗。

根本原因：

API使用動態、以負載為基礎的速率限制，而非固定的每秒請求數臨界值。 流量尖峰、未最佳化的輪詢，以及多步驟上傳或查詢流程，可能會將請求量推送到狀況良好上限以外，並觸發節流處理。 此外，回應可能會使用Cache-Control: max-age=600進行快取，因此下游快取可以在來源更新後繼續提供較舊的資料。

解決方法 resolution

使用下列步驟減少節流並確認復原。

  1. 檢閱應用程式記錄檔或API監視，以識別​ HTTP 429太多要求 ​回應。 預期結果會清楚顯示受影響API端點的節流狀況。 確認回應可重複存在於相同工作流程中，且不會隔離至不相關的請求。
  2. 檢查上傳或查詢工作流程的多步驟請求模式。 預期的結果是識別每個呼叫分別貢獻至整體請求數量的流程。 確認已計入搜尋、中繼資料查閱、上傳起始和上傳提交等請求序列。
  3. 檢閱重試行為與回應快取，包括Cache-Control: max-age=600。 預期的結果是發現可移除、延遲或快取的重複呼叫。 確認使用者端遵守快取持續時間，不會立即重新要求相同資料。
  4. 儘可能快取回應並避免重複的中繼資料擷取或重複呼叫，以減少請求量。 預期的結果是較低的API輸送量和較少的節流請求。 檢閱記錄檔或監控以確認要求數量減少，且429回應發生的頻率降低，以確認變更。
  5. 檢查更新時驗證快取行為。 預期結果是，重新整理的內容可能會在一般快取傳輸之後出現，而非立即。 請清除瀏覽器快取、重試請求，並確認重新整理的內容會在預期的1到10分鐘快取視窗內顯示，以確認這點。
  6. 套用指數輪詢，讓使用者端在429回應後重試之前，會以漸進方式等待更長的時間。 預期結果是節流事件的頻率較低。 在部署重試變更後，透過監視記錄來驗證改善，並確認重複的429回應拒絕。
  7. 如果流量持續接近服務限制，請檢閱請求批次或工作流程設計變更是否可以減少每個專案的呼叫。 在正常流量下，預期的結果是較穩定的回應行為。 確認請求模式在一般使用期間保持穩定，且不再觸發重複的節流。
  8. 如果在請求最佳化後繼續節流處理，在聯絡支援人員之前，請先收集時間戳記、受影響的端點、請求和回應標題、預估的請求率，以及快取策略詳細資訊。 預期的結果是完整的技術記錄，可支援更快的調查。 確認收集的資訊可反映節流要求及其發生條件。

如果​ HTTP 429太多請求 ​回應在請求量減少後繼續、快取如預期運作、重試行為已更新，並且相同API工作流程的節流仍可重複，請將票證提交至Adobe支援，並包含時間戳記、受影響的端點、請求和回應標頭、預估請求率，以及疑難排解期間收集的快取策略詳細資訊。

相關閱讀

recommendation-more-help
experience-cloud-kcs-help-kbarticles