Azure 服務匯流排上的節流作業
雲端原生解決方案提供可隨工作負載調整的無限制資源概念。 雖然此概念在雲端中比在內部部署系統中更適用，但雲端中仍存在限制。 如本文所述，這些限制可能會導致 標準和進階層中用戶端應用程式要求的節流 。
標準層中的節流
服務匯流排的標準層會以隨用隨付定價模式作為多租用戶設定運作。 在這裡，相同叢集中的多個命名空間會共用已配置的資源。 標準層是針對開發人員環境、QA 環境和低輸送量生產系統的建議選項。
過去，服務匯流排有嚴格相依於資源使用率的粗略節流限制。 不過，有機會精簡節流邏輯，並將可預測的節流行為提供給共用這些資源的所有命名空間。
在嘗試確保資源在使用相同資源的所有 服務匯流排 標準命名空間之間公平使用和分配資源時，服務匯流排 標準目前會使用信用型節流邏輯。
注意
請務必注意，節流不是 Azure 服務匯流排或任何雲端原生服務的新作法。
點數型節流只是精簡各種命名空間在多租用戶標準層環境中共用資源的方式，從而讓共用資源的所有命名空間都能公平使用。
什麼是點數型節流？
點數型節流會限制在特定時段內可在給定命名空間上執行的作業數目。 以下是點數型節流的工作流程。
- 在每個時間週期開始時，服務匯流排 為每個命名空間提供一些點數。
- 傳送者或接收者用戶端應用程式執行的任何作業都會根據這些點數計算（並從可用的點數減去）。
- 如果點數用完，後續作業將會進行節流，直到下一個時段開始。
- 點數會在下一個時段開始時補充。
什麼是點數限制？
點數限制目前設定為每秒 1000 個點數 (每個命名空間)。 並非所有作業都會採用相等的方式來建立。 以下是每個作業的點數成本。
| 作業 | 點數成本 |
|---|---|
資料作業 (SendSendAsyncReceiveReceiveAsyncPeek) |
每則訊息 1 個點數 |
管理作業 (佇列、主題、訂用帳戶、篩選條件上的 Create、Read、Update、Delete) |
10 個點數 |
注意
傳送至主題時，系統會先針對篩選條件評估每則訊息，然後在訂用帳戶上提供這些訊息。 每個篩選條件評估也會計入點數限制（也就是每個篩選條件評估 1 個點數）。
如何? 知道我正在節流？
當用戶端應用程式要求受到節流時，用戶端應用程式會收到下列伺服器回應。
The request was terminated because the entity is being throttled. Error code: 50009. Please wait 2 seconds and try again.
如何避免受到節流？
使用共用資源時，請務必跨共用這些資源的各種服務匯流排命名空間強制執行某種公平的使用方式。 節流可確保單一工作負載中的任何尖峰不會導致相同資源上的其他工作負載受到節流。 如本文稍後所述，因為用戶端軟體開發工具包（SDK）和其他 Azure PaaS 供應專案內建的預設 重試原則 ，因此不會有節流的風險。 任何節流要求會以指數輪詢重試，最後會在補充點數時通過。
可以理解的是，某些應用程式可能會因為節流而敏感。 在此情況下，建議您將目前的 服務匯流排 標準命名空間移轉至進階。 在移轉時，您可以將專用資源配置給服務匯流排命名空間，並在工作負載出現尖峰時適當地擴大資源，並降低節流的可能性。 此外，當您的工作負載減少至一般層級時，您可以縮減配置給命名空間的資源。
進階層中的節流
服務匯流排進階層會根據傳訊單位，將專用資源配置給客戶設定的每個命名空間。 這些專用資源提供可預測的輸送量和延遲，並建議用於高輸送量或敏感性生產等級系統。 此外，進階層也可讓客戶在工作負載中遇到尖峰時擴大輸送量容量。 如需詳細資訊，請參閱自動更新 Azure 服務匯流排命名空間的傳訊單位。
節流如何在服務匯流排進階中運作？
透過進階層的獨佔資源配置，節流純粹是由配置給命名空間的資源限制所驅動。 如果要求數目超過目前資源可服務的數量，則會節流要求。
如何? 知道我正在節流？
有各種方式可識別服務匯流排進階層中的節流。
- 節流要求顯示在 Azure 監視器要求計量上，以識別已節流的要求數目。
- 高 CPU 使用量 表示目前的資源配置很高，如果目前的工作負載未減少，要求可能會受到節流。
- 高 記憶體使用量 表示目前的資源配置很高，如果目前的工作負載未減少，要求可能會受到節流。
如何避免受到節流？
當服務匯流排進階命名空間已有專用資源時，您可以藉由擴大在工作負載出現尖峰時配置給命名空間的傳訊單位數目來減少節流的可能性。 如需詳細資訊，請參閱自動更新 Azure 服務匯流排命名空間的傳訊單位。
常見問題集
節流如何影響我的應用程式？
當要求受到節流時，其表示服務忙碌中，因為該服務面臨比資源允許更多的要求。 如果在片刻後重試相同的作業，一旦服務完成其目前的工作負載，就可以接受要求。
由於節流是任何雲端原生服務的預期行為，因此重試邏輯會內建至服務匯流排 SDK 本身。 預設值會設定為使用指數輪詢自動重試，以確保我們每次都沒有相同的要求受到節流。 默認重試邏輯會套用至每個作業。
注意
呼叫其他第三方服務的訊息處理程式碼也可能受到其他服務節流。 如需如何處理這些案例的詳細資訊，請參閱有關節流模式的文件。
節流會導致資料遺失嗎？
Azure 服務匯流排 已針對持續性進行優化。 我們會確保傳送至 服務匯流排 的所有數據都會認可至記憶體，然後服務才會確認要求成功。
一旦服務匯流排成功確認要求，就表示服務匯流排已成功處理要求。 如果服務匯流排傳回失敗，則表示服務匯流排無法處理要求，且用戶端應用程式必須重試要求。
不過，當要求受到節流時，服務表示由於資源限制，其目前無法接受並處理要求。 這並不表示任何種類的資料遺失，因為服務匯流排只是未查看要求。 在此情況下，依賴服務匯流排 SDK 的預設重試原則確保最終會處理要求。
相關內容
如需使用服務匯流排傳訊的詳細資訊和範例，請參閱下列進階主題：