優先順序佇列模式

優先順序佇列模式可讓工作負載比優先順序較低的工作更快處理高優先順序的工作。 此模式會使用傳送至一或多個佇列的訊息，在為個別用戶端提供不同服務等級保證的應用程式中很有用。

內容和問題

工作負載通常需要以不同層級的重要性和緊迫性來管理和處理工作。 有些工作需要立即注意，而另一些工作可以等候。 無法解決高優先順序的工作可能會影響用戶體驗和違反服務等級協定 （SLA）。

若要根據工作的優先順序有效率地處理工作，工作負載需要一個機制來據此排定和執行工作的優先順序。 一般而言，工作負載會依照工作到達的順序來處理工作，並使用先出先出 （FIFO） 佇列結構。 這種方法不會考慮工作的不同重要性。

解決方案

優先順序佇列允許工作負載根據其優先順序來處理工作，而不是其抵達順序。 將訊息傳送至佇列的應用程式會將優先順序指派給訊息，而取用者會依優先順序處理訊息。 當您有下列需求時，請使用優先順序佇列模式：

• 處理不同緊迫性和重要性的工作。 您有不同層級的緊迫性和重要性的工作，而且必須確保您在較不重要的工作之前處理更關鍵的工作。

• 處理不同的服務等級協定。 您可以為用戶端提供不同的服務等級保證，而且需要確保高優先順序客戶端獲得更佳的效能和可用性。

• 容納不同的工作負載管理需求。 您有一個工作負載需要立即解決某些工作，且較不緊急的工作可以等候。

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

• 單一佇列：所有訊息都會傳送至一個佇列，而每個訊息都會指派優先順序。

• 多個佇列：每個訊息優先順序會使用不同的佇列。

單一佇列

使用單一佇列時，應用程式（產生者）會將優先順序指派給每個訊息，並將訊息傳送至佇列。 佇列會依優先順序排序訊息，確保取用者在優先順序較低的訊息之前處理較高優先順序的訊息。

圖 1. 單一佇列和單一取用者集區的架構

多個佇列

多個佇列可讓您依優先順序分隔訊息。 應用程式會將優先順序指派給每個訊息，並將訊息導向至對應至其優先順序的佇列。 取用者會處理訊息。 多個佇列解決方案會使用單一取用者集區或多個取用者集區。

多個取用者集區

使用多個取用者集區時，每個佇列都有專用的取用者資源。 優先順序較高的佇列應該使用更多取用者或更高的效能層級，以比優先順序較低的佇列更快處理訊息。

當您擁有下列專案時，請使用多個取用者集區：

• 嚴格的效能需求：當不同的工作優先順序具有必須獨立符合的嚴格效能需求時，需要多個取用者集區。
• 高可用性需求：對於可靠性與錯誤隔離很重要的應用程式，需要多個取用者集區。 一個佇列中的問題不得影響其他佇列。
• 複雜應用程式：適用於需要不同處理特性和效能保證之工作的複雜應用程式。

圖 2. 多個佇列和多個取用者集區的架構。

單一取用者集區

使用單一取用者集區時，所有佇列都會共用單一取用者集區。 取用者會先處理來自最高優先順序佇列的訊息，而且只有在沒有高優先順序訊息時，才會處理來自較低優先順序佇列的訊息。 因此，單一取用者集區一律會在優先順序較低的訊息之前處理較高優先順序的訊息。 此設定可能會導致優先順序較低的訊息持續延遲，而且可能永遠不會處理。

使用單一取用者集區來進行：

• 簡單管理：單一取用者集區適用於容易設定和維護的應用程式優先。 其可降低組態和監視的複雜性。
• 統一處理需求：當傳入工作的確切本質類似時，單一取用者集區很有用。

圖 3. 多個佇列和單一取用者集區的架構。

優先順序佇列模式的建議

當您決定如何實作優先順序佇列模式時，請考慮下列建議：

一般建議

• 清楚定義優先順序。 建立與解決方案相關的不同且清楚的優先順序層級。 例如，高優先順序訊息可能需要在10秒內處理。 識別處理高優先順序專案的需求，並據以配置必要的資源。

• 動態調整取用者集區。 根據取用者集區所維護的佇列長度調整取用者集區的大小。

• 排定服務等級的優先順序。 實作優先順序佇列，以符合需要優先可用性或效能的商務需求。 例如，不同的客戶群組可以接收不同的服務層級，讓高優先順序的客戶體驗更好的效能和可用性。

• 確定低優先順序處理。 在支援訊息優先順序的佇列中，如果系統允許它確保最終處理低優先順序的訊息，就會動態增加過時訊息的優先順序。

• 請考慮佇列成本。 請注意與檢查佇列相關聯的財務和處理成本。 某些佇列服務會收取張貼、擷取和查詢訊息的費用，這可能會隨著佇列數目而增加。

多個佇列建議

• 監視處理速度。 為了確保訊息會以預期的速率處理，請持續監視高優先順序和低優先順序佇列的處理速度。

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

單一取用者集區建議

• 實作先占和暫停。 決定所有高優先順序專案是否必須在任何較低優先順序的專案之前處理。 使用演算法，確保高優先順序佇列在針對多個佇列使用單一取用者集區時，一律會在低優先順序佇列之前提供服務。

• 將成本優化。 使用單一佇列方法時，藉由相應減少取用者數目來優化營運成本。 高優先順序訊息會先處理，但速度可能較慢，而優先順序較低的訊息可能會面臨較長的延遲。

工作負載設計

架構設計人員應該評估優先順序佇列模式如何解決 Azure 良好架構架構支柱中涵蓋的目標和原則。 例如：

如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。

優先順序佇列模式的範例

GitHub 中的下列範例示範如何使用 Azure 服務匯流排 實作優先順序佇列模式。

圖 4。 GitHub 中 PriorityQueue 範例的架構

以下是架構的概觀：

• 應用程式（產生者）：此範例有一個應用程式 （PriorityQueueSender） 會建立訊息，並指派每個訊息中呼叫 Priority 的自定義屬性。 Priority具有或Low的值High。

• 訊息代理程式和佇列：此範例會使用 Azure 服務匯流排 做為訊息代理程式。 它會使用兩個 Azure 服務匯流排 佇列，每個訊息優先順序各一個 （High和 Low）。 應用程式 （產生者） 會根據訊息 Priority，將訊息傳送至正確的佇列。

• 多個取用者集區：此範例會使用多個取用者集區（PriorityQueueConsumerHigh 和 PriorityQueueConsumerLow），專門讀取來自每個佇列的訊息。

相關資源

當您實作此模式時，下列模式可能會對您有説明：

• 競爭取用者模式：此模式牽涉到實作多個取用者，這些取用者會同時接聽相同的佇列和處理工作，以增加輸送量。 每個訊息只有一個取用者處理。 本文提供此方法優點和缺點的詳細資訊。

• 節流模式：您可以使用佇列來實作此模式來管理要求速率。 藉由使用優先順序傳訊，來自重要應用程式或高價值客戶的要求可以優先於較不重要的要求。