優先順序佇列模式

將傳送至服務的請求排定優先順序，讓工作負載能比處理較低優先順序的請求更快地處理高優先順序的請求。 此方法利用發送給一個或多個佇列的訊息，對於提供不同服務水準或服務水準協議（SLA）給不同請求類型或客戶的應用程式非常有用。

內容和問題

工作負載可能需要管理和處理不同重要性與緊急度的任務。 有些工作需要立即注意，而另一些工作可以等候。 未處理高優先權任務可能影響使用者體驗並違反SLA。

為了根據優先順序有效率地處理任務，工作負載需要一個機制來相應地處理並執行任務。 預設情況下，大多數工作負載會依任務抵達的順序處理，採用先入先出（FIFO）排隊結構。 這種方法未考慮任務重要性的不同。

Solution

優先佇列允許工作負載根據其優先順序處理任務，而非嚴格依照抵達順序。 發送請求的應用程式或 產生 者會為訊息分配優先權值， 消費者則依 優先順序處理訊息。 優先佇列模式解決以下需求：

• 處理不同緊急與重要性的任務： 你有不同層級的緊急性和重要性任務，需要確保先處理較關鍵的任務，再處理較不重要的任務。

• 處理不同的服務等級協議（SLA）： 你為不同客戶提供不同的 SLA，必須確保高優先級客戶獲得更好的效能與可用性。

• 滿足不同的工作量管理需求： 你有工作量需要立即處理某些任務，而較不緊急的任務則可以等待。

實作優先順序佇列模式的主要方法有兩種：

• 單排隊： 每個訊息都會被分配一個優先權值，所有訊息共用同一個佇列。

• 多重佇列： 每個訊息都被分配一個優先權值，不同優先權的訊息則使用獨立的佇列。

單一佇列

在單一佇列方式中，應用程式會為每個訊息分配優先順序，並將所有訊息發送到單一佇列。 佇列會依優先順序排序訊息，確保取用者在優先順序較低的訊息之前處理較高優先順序的訊息。

多個佇列

多重佇列會依優先順序區分訊息。 應用程式會為每個訊息分配優先權，並將訊息導向對應其優先順序的佇列，讓消費者處理訊息。 多排隊解決方案可使用單一消費者池或多個消費者池。

單一取用者集區

在單一池設置中，所有佇列共用同一個消費者池。 消費者會先處理最高優先權佇列的訊息，只有在沒有高優先權訊息時才處理低優先權佇列的訊息。 因此，單一消費者池總是先處理高優先權訊息，再處理低優先權訊息。 這種設定可能導致低優先權訊息持續延遲，甚至可能永遠無法處理。

使用單一消費者池的原因如下：

• 簡單的管理。 當簡單的設定和維護是優先事項時，請使用單一消費者池。 單一池則降低設定與監控的複雜度。

• 統一處理需求。 當輸入任務類型相似時，使用單一消費者池。

多個消費者集區

在多消費者池中，每個佇列都有專用的消費者池。 高優先權佇列使用更多消費者或高效能層級，以比低優先權佇列更快處理訊息。

使用多個消費者池的原因如下：

• 嚴格的績效要求。 當不同任務優先順序有嚴格的效能要求，必須獨立滿足時，使用多個消費者池。

• 高可靠性需求。 當可靠性與故障隔離至關重要，且一個佇列的問題不得影響其他佇列時，應使用多個消費者池。

• 複雜的應用。 對於不同任務需要不同處理特性與效能保證的複雜應用，使用多個消費者池。

問題和考慮

當您決定如何實作此模式時，請考慮下列幾點：

一般建議

• 清楚定義優先順序。 建立與你的解決方案相關的明確且明確的優先級級。 例如，你可以將高優先權訊息定義為需要在 10 秒內處理的訊息。 識別消費者對處理高優先項目的需求，並相應分配必要資源。

• 動態調整取用者集區。 根據他們服務的隊列長度來擴大消費者池的規模。

• 監控隊列健康狀況。 追蹤佇列深度、處理延遲、配送次數和吞吐量，讓你能在積壓和延遲影響工作前偵測到它們。

• 使用死字母排隊。 在可設定的投遞次數後，將 有毒訊息 移到死信佇列，這樣一個錯誤訊息就不會阻塞優先路徑。

• 排定服務等級的優先順序。 實作優先順序佇列，以符合需要優先可用性或效能的商務需求。 例如，高優先客戶可以獲得更高的服務水準，從而體驗更好的效能與可用性。

• 考慮低優先權處理。 決定是否必須先處理所有高優先權項目，再處理低優先事項。 如果可能，動態提高舊訊息的優先權，以確保低優先權訊息最終能被處理。

• 優化並降低成本。 使用可用的取用者立即處理重要工作。 在較不忙碌的時段內排程較不重要的背景工作。

  如果只用一個佇列，就透過縮減消費者數量來優化成本。 高優先權訊息會先處理，但可能較慢;而低優先權訊息則可能面臨較長的延遲。

• 保護處理器免於需求高峰。 若生產者抵達率超過消費者處理能力，則將此模式與 Queue-Based 負載平準模式結合。 此方法緩衝流量突發，並有助於防止下游處理資源過載。

多重排隊推薦

• 監視處理速度。 為確保訊息以預期速率處理，需持續監控高優先與低優先佇列的處理速度。

• 實作先占和暫停。 如果你使用多個佇列與單一消費者池，請實作一個演算法，確保高優先權佇列總是先被服務，優先於較低優先順序的佇列。

• 請考慮佇列成本。 請注意檢查與處理隊列所帶來的財務成本。 部分排隊服務會對訊息的發布、檢索及查詢收取費用。 這些費用會隨著排隊人數增加而增加。

使用此模式的時機

當下列情況時，請使用此模式：

• 你必須針對不同類型的工作，例如高級客戶需求與標準客戶需求，達成不同的延遲或服務水準目標。

• 工作是分段到來的，你必須先處理高優先權訊息，同時延後低優先權的工作來保護關鍵作業。

在下列情況下，此模式可能不適用：

• 所有工作項目的業務重要性相似，嚴格的先入先出處理比優先順序排程更為重要。

• 任務在不同優先順序層級間有強烈的排序依賴，依優先順序重新排序工作可能導致結果不一致或需要複雜的協調邏輯。

工作負載設計

評估如何在工作負載設計中使用優先佇列模式，以達成Azure Well-Architected框架支柱所涵蓋的目標與原則。 下表提供此模式如何支援每個要素目標的指引。

支柱	此模式如何支援支柱目標
可靠性設計決策可協助您的工作負載對故障具備韌性，並確保它在發生故障後能恢復至完全正常運作的狀態。	根據業務優先順序來區分項目，可讓您將可靠性工作集中在最關鍵的工作上。 - RE：02 關鍵流程
效能效率 可透過調整、數據和程式碼的優化， 有效率地協助您的工作負載符合需求 。	根據商務優先順序來分隔專案，可讓您將效能工作集中在最耗時的工作上。 - PE：09 關鍵流程

如果此模式在一個支柱內部引入取捨，請將它們與其他支柱的目標進行考量。

範例

GitHub 上的優先佇列範例展示了使用 Azure 服務匯流排 主題與訂閱的優先佇列模式實作。 範例中部署了一個安全儲存帳號、一個用於監控的 Application Insights 資源，以及一個 服務匯流排 命名空間，以促進發送端與消費者函式之間的通訊。

部署包含三個功能應用程式：一個發送者和兩個消費者。 消費者應用程式會使用不同的最大實例數來模擬訊息優先順序。 這個 funcPriorityQueueConsumerHigh 函式可以擴展到 200 個實例，而 funcPriorityQueueConsumerLow 實際功能則限制在 40 個實例。 所有功能應用程式皆使用 Flex 使用方案，並連接 Application Insights 進行診斷與監控。

角色指派透過管理身份提供對 服務匯流排 與儲存裝置的安全存取。 所有功能應用程式共用同一個儲存帳號和 Application Insights 資源。 此配置集中可觀察性與記錄。

下圖顯示優先佇列架構：

在上圖中：

1. 應用程式（生產者）。 應用程式會 PriorityQueueSender 建立訊息，為每個訊息指派一個自訂 Priority 的應用程式屬性，並將值設定 Priority 為 High 或 Low。

2. 訊息經紀人與主題。 服務匯流排 訊息代理會將訊息傳送給一個名為 messages. 的單一 服務匯流排 主題。 服務匯流排 使用 SQL 篩選器，根據訊息的價值將每個訊息導向高優先權或低優先權訂閱Priority。

3. 多個消費者池。 與消費者池會透過Azure Functions 服務匯流排觸發器回應來自高優先權或低優先權訂閱的訊息。PriorityQueueConsumerLowPriorityQueueConsumerHigh

範例中的角色	Azure 服務範例	範例中的名稱
應用程式（製作人）	Azure Functions app	PriorityQueueSender
訊息代理程式	Azure 服務匯流排	<你的服務匯流排命名空間>
訊息主題	Azure 服務匯流排 主題	messages
訊息訂閱	Azure 服務匯流排 subscriptions	highPriority lowPriority
消費者	Azure Functions app	PriorityQueueConsumerHigh PriorityQueueConsumerLow

下一步

• 服務匯流排 佇列、主題與訂閱：檢視 服務匯流排 實體及佇列與主題之間的差異。
• 重複偵測：了解 服務匯流排 如何在發送者在不確定發送後重試時拒絕重複訊息。
• 死信佇列：了解 服務匯流排 如何將無法處理的訊息移至死信佇列進行調查或重新處理。
• 什麼是 Azure 佇列儲存體？：回顧 Azure 佇列儲存體 的核心概念，並與 服務匯流排 佇列做比較。

相關資源

以下模式在實施此模式時可能有所幫助：

• Queue-Based 負載平準模式：使用佇列作為請求接收與處理之間的緩衝區。 當你需要突發防護和差異化處理時，可以搭配優先佇列模式使用。

• 競爭消費者模式：實作多個消費者，讓它們同時監聽同一佇列並平行處理任務，以提升吞吐量。 每個訊息僅由一個消費者處理。

• 限速模式：透過使用佇列來管理請求速率來實作限速。 利用優先訊息將來自關鍵應用程式或高價值客戶的請求優先處理，優先處理較不重要的請求。