處理 Azure Logic Apps 中的節流問題 (429 -「要求太多」錯誤)
適用於：Azure Logic Apps (使用量 + 標準)
如果您的邏輯應用程式工作流程遇到節流，當要求數目超過目的地可處理特定時間的速率時，就會發生 「HTTP 429 太多要求」錯誤。 節流可能造成資料處理延遲、效能速度降低等問題，以及導致超過指定重試原則等錯誤。
例如，取用工作流程中的下列SQL Server動作會顯示 429 錯誤，其中會報告節流問題：
下列各節說明工作流程可能會遇到節流處理的常見層級：
邏輯應用程式資源節流
Azure Logic Apps 有自己的 輸送量限制。 如果您的邏輯應用程式資源超過這些限制，您的邏輯應用程式資源就會受到節流，而不只是特定的工作流程實例或執行。
若要在此層級尋找節流事件，請遵循下列步驟：
在 Azure 入口網站中，開啟您的邏輯應用程式資源。
在邏輯應用程式資源功能表上的 [ 監視] 底下，選取 [ 計量]。
在 [圖表標題] 底下，選取 [ 新增計量]，將另一個計量列新增至圖表。
在第一個計量列中，從 [ 計量 ] 清單中，選取 [ 動作節流事件]。 從 [ 匯總 ] 清單中，選取 [ 計數]。
在第二個計量列中，從 [ 計量 ] 清單中，選取 [觸發節流事件]。 從 [ 匯總 ] 清單中，選取 [ 計數]。
圖表現在會顯示邏輯應用程式工作流程中動作和觸發程式的節流事件。 如需詳細資訊，請參閱 在 Azure Logic Apps 中檢視工作流程健康情況和效能的計量。
若要處理此層級的節流，您有下列選項：
限制可以同時執行的工作流程實例數目。
根據預設，如果您的工作流程觸發條件同時符合多次，則觸發程式的多個實例會同時引發並 平行執行。 每個觸發程式實例都會在上一個工作流程實例完成執行之前引發。
雖然可以同時執行的觸發程序執行個體預設數目無上限，但您可以開啟觸發程序的並行設定以限制此數目，並視需要選取預設值以外的限制。
啟用高輸送量模式。
取用工作流程對於 可在 5 分鐘滾動間隔內執行的動作數目有預設限制。 若要將此限制提高為最大動作數目，請在邏輯應用程式資源上開啟 高輸送量模式 。
標準工作流程對於任何間隔內可執行檔動作數目沒有任何限制。
停用觸發程式中的陣列取消批次處理或「分割開啟」行為。
如果觸發程式傳回要處理的其餘工作流程動作陣列，觸發程式的Split On設定會分割陣列專案，並為每個陣列專案啟動工作流程實例。 此行為實際上會觸發多個並存執行到 分割開啟 限制。
若要控制節流，請關閉觸發程式的 Split On 行為，並讓工作流程處理整個陣列並搭配單一呼叫，而不是處理每個呼叫的單一專案。
將動作重構為多個較小的工作流程。
如先前所述，取用邏輯應用程式工作流程僅限於 可在 5 分鐘期間內執行的預設動作數目。 雖然您可以啟用 高輸送量模式來增加此限制，但您也可以考慮是否要將工作流程的動作細分成較小的工作流程，讓每個工作流程中執行的動作數目維持在限制之下。 如此一來，您就可以減少單一工作流程的負擔，並將負載分散到多個工作流程。 這個解決方案較適合用於處理大型資料集的動作或加速許多同時執行的動作、迴圈反覆項目，或每個迴圈反覆項目內超過動作執行限制的動作。
例如，下列取用工作流程會執行所有工作，從SQL Server資料庫取得資料表，並從每個資料表取得資料列。 For each 迴圈會同時查看每個資料表，讓取得資料列動作傳回每個資料表的資料列。 依據這些資料表中的資料量，這些動作可能會超過動作執行的限制。
重構之後，原始工作流程會分割成父工作流程和子工作流程。
下列父工作流程會從SQL Server取得資料表，然後呼叫每個資料表的子工作流程以取得資料列：
父工作流程會呼叫下列子工作流程，以取得每個資料表的資料列：
連接器節流
每個連接器都有自己的節流限制，您可以在 每個連接器的技術參考頁面上找到。 例如，Azure 服務匯流排連接器的節流限制允許每分鐘最多 6，000 次呼叫，而 SQL Server 連接器的節流限制會根據作業類型而有所不同。
部分觸發程序和動作 (例如 HTTP) 有「重試原則」，您可以根據重試原則限制自訂原則，以實作例外狀況處理。 此原則會指定若原始要求逾時或失敗，並傳回 408、429 或 5xx 回應，觸發程序或動作是否要重試要求，以及重試頻率為何； 這樣一來，當節流開始並傳回 429 錯誤，Logic Apps 就會遵循支援的重試原則。
如要了解觸發程序或動作是否支援重試原則，請查看觸發程序或動作的設定。 若要檢視觸發程式或動作的重試嘗試，請移至邏輯應用程式的執行歷程記錄、選取您想要檢閱的執行，然後展開該觸發程式或動作，以檢視輸入、輸出和任何重試的詳細資料。
下列取用工作流程範例顯示您可以在何處找到 HTTP 動作的這項資訊：
雖然重試歷程記錄會提供錯誤資訊，但您或許依然會難以區分連接器節流與目的地節流。 在這種情況下，您可能必須檢閱回應的詳細資料或執行節流間隔計算以識別來源。
針對多租使用者 Azure Logic Apps 中的取用邏輯應用程式工作流程，節流會在 連線 層級發生。 對於在整合服務環境中執行的邏輯應用程式工作流程 ， (ISE) ，非 ISE 連線仍會發生節流，因為它們是在多租使用者 Azure Logic Apps 中執行。 不過，ISE 連接器所建立的 ISE 連線會在您的 ISE 中執行，因此不會發生節流。
若要處理此層級的節流，您有下列選項：
設定單一動作的多個連線，讓工作流程可以分割資料以供處理。
請考慮您是否可以使用相同的認證，將動作的要求分割至相同目的地的多個連線，以分散工作負載。
例如，假設您的工作流程會從SQL Server資料庫取得資料表，然後從每個資料表取得資料列。 您可以根據必須處理的資料列數目，使用多個連線和多個 For each 迴圈，將資料列總數分割成較小的集合進行處理。 此案例會使用兩個 For each 迴圈將資料列總數分割為兩半。 第一個 For each 迴圈使用取得前半部的運算式， 另一個 For each 迴圈使用其他運算式取得後半部，例如：
為每個動作設定不同連線。
請考慮您是否可以藉由將每個動作的要求分散到自己的連線，即使動作連線到相同的服務或系統，還是使用相同的認證來分散工作負載。
例如，假設您的工作流程會從SQL Server資料庫取得資料表，並取得每個資料表中的每個資料列。 您可以在此使用不同連線，也就是透過一個連線取得資料表，透過另一個連線取得每個資料列。
下列範例顯示取用工作流程，會針對每個動作建立和使用不同的連線：
變更 "For each"迴圈上的並行或平行處理原則。
根據預設，"For each" 迴圈反覆項目會同時執行至並行上限。 如果您有在「針對每個」迴圈內進行節流處理的連線，您可以減少平行執行的迴圈反復專案數目。 如需詳細資訊，請參閱下列文件：
目的地服務或系統節流
連接器有自己的節流限制，連接器所呼叫的目的地服務或系統也可能有節流限制。 例如，Microsoft Exchange Server 中部分 API 的節流限制比 Office 365 Outlook 連接器更嚴格。
根據預設，邏輯應用程式的工作流程實例和這些實例內的任何迴圈或分支，會 以平行方式執行。 這種行為代表多個執行個體可以同時呼叫相同的端點。 每個執行個體都不知道其他執行個體的存在，因此嘗試重試失敗的動作可建立競爭條件 (英文)，讓多個呼叫嘗試同時執行，但唯有在節流開始前抵達目的地服務或系統的呼叫才會成功。
例如，假設您有一個包含 100 個項目的陣列， 您可以使用 「For each」 迴圈逐一查看陣列，並開啟迴圈的並行控制，以便將平行反復專案的數目限制為 20 或 目前的預設限制。 在該迴圈內，動作會將陣列中的項目插入每秒只允許 15 次呼叫的 SQL Server 資料庫， 此案例會導致節流問題，因為重試的待處理專案會向上建置，且永遠不會執行。
下表描述當動作的重試間隔為 1 秒時，迴圈中會發生什麼情況的時間軸：
| 時間點 | 執行的動作數目 | 失敗的動作數目 | 等候的重試次數 |
|---|---|---|---|
| T + 0 秒 | 20 次插入 | 因 SQL 限制導致 5 次失敗 | 5 次重試 |
| T + 0.5 秒 | 15 次插入，因為前 5 次重試還在等候 | 15 次全部失敗，因為先前的 SQL 限制對於多出的 0.5 秒仍然有效 | 20 次重試 (先前 5 次 + 新的 15 次) |
| T + 1 秒 | 20 次插入 | 5 次失敗加上先前的 20 次重試 (因為有 SQL 限制) | 25 次重試 (先前 20 次 + 新的 5 次) |
若要處理此層級的節流，您有下列選項：
建立個別工作流程，讓每個工作流程處理單一作業。
繼續進行本節中的範例SQL Server案例，您可以建立可將陣列專案放入佇列中的工作流程，例如Azure 服務匯流排佇列。 然後，您可以建立另一個工作流程，只針對該佇列中的每個專案執行插入作業。 如此一來，在任何特定時間只會執行一個工作流程實例，這會完成插入作業並移至佇列中的下一個專案，或實例收到 429 錯誤，但不會嘗試不具生產力的重試。
建立父工作流程，以呼叫每個動作的子或巢狀工作流程。 如果父系需要根據父系的結果呼叫不同的子工作流程，您可以使用條件動作或切換動作來決定要呼叫哪一個子工作流程。 此模式有助於減少呼叫或作業數目。
例如，假設您有兩個工作流程，每個工作流程都有輪詢觸發程式，每分鐘都會檢查電子郵件帳戶是否有特定主旨，例如「成功」或「失敗」。 這個設定每小時會產生 120 個呼叫。 相反地，如果您建立單一父工作流程來輪詢每分鐘，但會呼叫根據主旨為「成功」或「失敗」執行的子工作流程，您會在此案例中將輪詢檢查數目剪下為一半或 60。
設定批次處理。 (僅) 取用工作流程
如果目的地服務支援批次作業，您便能以群組或批次方式處理項目並解決節流問題，而不必個別處理項目。 若要實作批次處理解決方案，您可以建立「批次接收者」邏輯應用程式工作流程和「批次傳送者」邏輯應用程式工作流程。 批次傳送者會收集訊息或項目，直到符合您指定的標準，然後將這些訊息或項目傳送到單一群組中。 批次接收者會接受該群組並處理這些訊息或項目。 如需詳細資訊，請參閱以群組方式批次處理訊息。
使用觸發程序和動作的 Webhook 版本，而不是輪詢版本。
原因為何？ 輪詢觸發程序會持續按照特定間隔檢查目的地服務或系統， 如果間隔非常短 (如每秒)，就可能會發生節流問題。 相較之下，HTTP Webhook 等 Webhook 觸發程序或動作只會在訂閱時間對目的地服務或系統建立單一呼叫，且僅要求目的地在事件發生時通知觸發程序或動作。 如此一來，觸發程序或動作就不需要持續檢查目的地。
因此，如果目的地服務或系統支援 Webhook 或提供具有 Webhook 版本的連接器，則此選項會比使用輪詢版本好。 識別 Webhook 觸發程序和動作時，請確認具有
ApiConnectionWebhook類型，或其無需您指定週期。 如需詳細資訊，請參閱 APIConnectionWebhook 觸發程序與 APIConnectionWebhook 動作。