優先順序佇列模式

Azure 服務匯流排

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

內容和問題

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

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

解決方案

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

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

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

• 容納不同的工作負載管理需求。 您有一個任務，其中一些工作需要立即處理，而不太緊急的工作則可以等候。

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

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

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

單一佇列

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

此圖說明支援訊息優先順序的佇列機制。
圖 1. 單一佇列和單一取用者集區的架構

多個佇列

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

多個消費者集區

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

在以下情況中，請使用多個消費者池：

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

此圖說明針對每個優先順序使用不同的消息佇列。
圖 2. 多個佇列和多個取用者集區的架構。

單一取用者集區

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

使用單一使用者池：

• 簡單管理：單一使用者池適用於設定和維護方便且優先考量這些特性的應用程式。 其可降低組態和監視的複雜性。
• 統一處理需求：當傳入任務的確切性質相似時，單一消費者池非常有用。

此圖說明針對每個優先順序使用不同的消息佇列。
圖 3. 多個佇列和單一取用者集區的架構。

優先順序佇列模式的建議

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

一般建議

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

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

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

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

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

多個佇列建議

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

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

單一消費者池建議

• 實作先占和暫停。 決定所有高優先順序專案是否必須在任何較低優先順序的專案之前處理。 使用演算法來確保高優先順序的佇列總是比低優先順序的佇列先被服務，當你使用單一使用者池來處理多個佇列時。

• 將成本優化。 使用單排隊方法時，透過縮減消費者數量來優化營運成本。 高優先順序訊息會先處理，但速度可能較慢，而優先順序較低的訊息可能會面臨較長的延遲。

工作負載設計

架構師應評估優先佇列模式如何涵蓋Azure Well-Architected框架支柱所涵蓋的目標與原則。 例如：

支柱	此模式如何支援支柱目標
可靠性設計決策可協助工作負載在發生故障時具備復原能力，並確保它會在失敗發生後恢復到完全正常運作的狀態。	根據商務優先順序來分隔專案，可讓您將可靠性工作放在最重要的工作上。 RE：02 關鍵流程 RE：07背景工作
效能效率可透過調整規模、資料、程式碼達到最佳化，有效率地協助您的工作負載符合需求。	根據商務優先順序來分隔專案，可讓您將效能工作集中在最耗時的工作上。 PE：09 關鍵流程

如同任何設計決策，請考慮可能伴隨此模式引入的其他支柱目標的取捨。

優先順序佇列模式的範例

以下範例在 GitHub 展示了使用 Azure 服務匯流排 實現優先佇列模式的實作。

圖 4。 GitHub 中 PriorityQueue 範例的架構

以下是架構的概觀：

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

• Message broker and queues：範例使用 Azure 服務匯流排 作為訊息代理。 它使用兩個Azure 服務匯流排佇列，分別對應每個訊息優先順序（High 和 Low）。 應用程式 （產生者） 會根據訊息 ，將訊息傳送至正確的佇列。

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

範例架構中的角色	Azure 服務範例	範例中的名稱
申請	Azure Functions app	優先佇列發送者
消息佇列訊息代理程式	Azure 服務匯流排	您的服務總線命名空間
訊息佇列	Azure 服務匯流排 queues	您的佇列名稱
消費者	Azure Functions app	PriorityQueueConsumerHigh 優先佇列消費者低

相關資源

當您實作此模式時，下列模式可能會對您有所幫助：

• 競爭消費者模式：此模式牽涉到實作多個消費者，這些消費者會同時接收並處理同一個佇列中的任務，以增加吞吐量。 每個訊息僅由一個消費者處理。 本文提供此方法優點和缺點的詳細資訊。

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

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

內容和問題

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

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

解決方案

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

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

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

• 容納不同的工作負載管理需求。 您有一個任務，其中一些工作需要立即處理，而不太緊急的工作則可以等候。

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

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

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

單一佇列

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

此圖說明支援訊息優先順序的佇列機制。
圖 1. 單一佇列和單一取用者集區的架構

多個佇列

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

多個消費者集區

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

在以下情況中，請使用多個消費者池：

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

此圖說明針對每個優先順序使用不同的消息佇列。
圖 2. 多個佇列和多個取用者集區的架構。

單一取用者集區

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

使用單一使用者池：

• 簡單管理：單一使用者池適用於設定和維護方便且優先考量這些特性的應用程式。 其可降低組態和監視的複雜性。
• 統一處理需求：當傳入任務的確切性質相似時，單一消費者池非常有用。

此圖說明針對每個優先順序使用不同的消息佇列。
圖 3. 多個佇列和單一取用者集區的架構。

優先順序佇列模式的建議

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

一般建議

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

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

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

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

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

多個佇列建議

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

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

單一消費者池建議

• 實作先占和暫停。 決定所有高優先順序專案是否必須在任何較低優先順序的專案之前處理。 使用演算法來確保高優先順序的佇列總是比低優先順序的佇列先被服務，當你使用單一使用者池來處理多個佇列時。

• 將成本優化。 使用單排隊方法時，透過縮減消費者數量來優化營運成本。 高優先順序訊息會先處理，但速度可能較慢，而優先順序較低的訊息可能會面臨較長的延遲。

工作負載設計

架構師應評估優先佇列模式如何涵蓋Azure Well-Architected框架支柱所涵蓋的目標與原則。 例如：

支柱	此模式如何支援支柱目標
可靠性設計決策可協助工作負載在發生故障時具備復原能力，並確保它會在失敗發生後恢復到完全正常運作的狀態。	根據商務優先順序來分隔專案，可讓您將可靠性工作放在最重要的工作上。 RE：02 關鍵流程 RE：07背景工作
效能效率可透過調整規模、資料、程式碼達到最佳化，有效率地協助您的工作負載符合需求。	根據商務優先順序來分隔專案，可讓您將效能工作集中在最耗時的工作上。 PE：09 關鍵流程

如同任何設計決策，請考慮可能伴隨此模式引入的其他支柱目標的取捨。

優先順序佇列模式的範例

以下範例在 GitHub 展示了使用 Azure 服務匯流排 實現優先佇列模式的實作。

圖 4。 GitHub 中 PriorityQueue 範例的架構

以下是架構的概觀：

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

• Message broker and queues：範例使用 Azure 服務匯流排 作為訊息代理。 它使用兩個Azure 服務匯流排佇列，分別對應每個訊息優先順序（High 和 Low）。 應用程式 （產生者） 會根據訊息 ，將訊息傳送至正確的佇列。

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

範例架構中的角色	Azure 服務範例	範例中的名稱
申請	Azure Functions app	優先佇列發送者
消息佇列訊息代理程式	Azure 服務匯流排	您的服務總線命名空間
訊息佇列	Azure 服務匯流排 queues	您的佇列名稱
消費者	Azure Functions app	PriorityQueueConsumerHigh 優先佇列消費者低

相關資源

當您實作此模式時，下列模式可能會對您有所幫助：

• 競爭消費者模式：此模式牽涉到實作多個消費者，這些消費者會同時接收並處理同一個佇列中的任務，以增加吞吐量。 每個訊息僅由一個消費者處理。 本文提供此方法優點和缺點的詳細資訊。

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