訊息工作階段
Azure 服務匯流排工作階段能夠聯合和依序處理未繫結的相關訊息序列。 工作階段可在先進先出 (FIFO) 和要求-回應模式中使用。 本文說明如何在利用服務匯流排時，使用工作階段來實作這些模式。
注意
基本層的服務匯流排並不支援工作階段。 標準層和高階層則支援工作階段。 如需這些階層之間的差異，請參閱服務匯流排定價。
先進先出 (FIFO) 模式
若要在處理服務匯流排佇列或訂用帳戶中的訊息時實現 FIFO 保證，請使用工作階段。 服務匯流排對於訊息之間關聯性的本質並無任何規範，且也不會定義特殊的模型來判斷訊息序列開頭或結尾位置。
所有傳送者均可在將訊息提交至佇列或主題時建立工作階段，方法是將工作階段識別碼屬性設定為某個應用程式定義的識別碼，此識別碼對該工作階段而言是唯一的。 在 AMQP 1.0 通訊協定層級，這個值會對應至群組識別碼屬性。
在工作階段感知的佇列或訂用帳戶中，工作階段會在至少有一個訊息具備工作階段識別碼時變成存在。 一旦工作階段存在之後，就不會有針對工作階段到期或消失時定義的時間或 API。 理論上，今日可接收工作階段的訊息，一年內的下一個訊息，而且如果工作階段識別碼相符，則從服務匯流排的觀點來看，工作階段是一樣。
不過，一般而言，應用程式會對一組相關訊息開頭與結尾位置具有清楚的概念。 服務匯流排不會設定任何特定的規則。 例如，您的應用程式可以將第一個訊息的標籤屬性設定為開始，將中繼訊息的屬性設定為內容，並將最後一個訊息的屬性設定為結束。 內容訊息的相對位置可從 start 訊息的 SequenceNumber 計算成為目前訊息的 SequenceNumber 差異。
重要
在佇列或訂用帳戶上啟用工作階段後，用戶端應用程式「無法再」傳送/接收一般訊息。 所有訊息都必須作為工作階段的一部分傳送 (藉由設定工作階段識別碼)，並透過接受工作階段來接收。 用戶端可能仍會查看已啟用工作階段的佇列或訂用帳戶。 請參閱訊息瀏覽。
適用於工作階段的 API 會存在於佇列和訂用帳戶用戶端上。 有一個命令式模型可供控制接收工作階段與訊息的時間，還有一個以處理常式為基礎的模型，其可隱藏管理接收迴圈的複雜度。
如需範例，請使用後續步驟一節中的連結。
工作階段功能
工作階段會提供交錯式訊息資料流的並行分離信號，同時保留並保證會依序傳遞。
工作階段接收者會由接受工作階段的用戶端來建立。 當用戶端接受並保留工作階段時，如果在佇列或訂用帳戶中，訊息有該工作階段的工作階段識別碼，則用戶端就會在這些訊息上保留獨佔鎖定。 此用戶端會對稍後抵達、具有工作階段識別碼的所有訊息保留獨佔鎖定。
當您在接收者上呼叫 close 方法或鎖定到期時，就會釋放鎖定。 接收者上也有方法可以更新鎖定。 相反地，您也可以使用自動鎖定更新功能，在其中指定您想要持續更新鎖定的持續時間。 工作階段鎖定應被視為類似檔案上的獨佔鎖定，這表示只要應用程式不再需要工作階段和/或不預期會有任何後續訊息時，就應儘速關閉該工作階段。
當多個並行接收者從佇列提取時，就會將屬於特殊工作階段的訊息分派給目前保有該工作階段之鎖定的特定接收者。 透過該作業，一個佇列或訂用帳戶中的交錯式訊息資料流就會被完全分離信號到不同接收者，而那些接收者也可以存留於不同的用戶端機器上，因為鎖定管理會發生於服務匯流排內部的服務端。
上圖顯示三個並行工作階段接收者。 帶有 SessionId = 4 的工作階段沒有任何作用中的所有權用戶端，這表示沒有訊息從此特定工作階段傳遞。 工作階段的行為在許多方面類似子佇列。
工作階段接收者所保留的工作階段鎖定是對於「查看鎖定」安置模式所使用之訊息鎖定的保護傘。 只有一個接收者可擁有工作階段的鎖定。 接收者可能會有許多進行中的訊息，但會依序接收這些訊息。 放棄訊息會導致下一個接收作業再次提供相同的訊息。
訊息工作階段狀態
在高延展性且高可用性的雲端系統中處理工作流程時，與特定工作階段建立關聯的工作流程處理常式必須能夠從非預期失敗中復原，並能在與工作開始之處不同的處理序或機器上，繼續執行部分完成的工作。
工作階段狀態設施會在訊息代理程式內部，為訊息工作階段啟用應用程式定義的註釋，因此，相對於該工作階段所記錄的處理狀態會在新的處理器取得該工作階段時立即變成可用狀態。
從服務匯流排的觀點而言，訊息工作階段狀態是一個不透明的二進位物件，其可保存一個訊息大小的資料，針對服務匯流排標準為 256 KB，針對服務匯流排進階則是 100 MB。 相對於工作階段的處理狀態可以保留在工作階段狀態內部，或者工作階段狀態可以指向某個保留這類資訊的儲存體位置或資料庫記錄。
您可以在工作階段接收者物件上找到用於管理工作階段狀態、SetState 和 GetState 的方法。 先前沒有任何工作階段狀態的工作階段會針對 GetState 傳回 Null 參考。 先前設定的工作階段狀態可以透過將 Null 傳遞至接收者上的 SetState 方法來加以清除。
只要未清除 (傳回 null)，工作階段狀態就會維持不變，即使取用工作階段中的所有訊息也一樣。
保留於佇列或訂用帳戶中的工作階段狀態會計入該實體的儲存體配額。 使用工作階段完成應用程式時，接著會建議應用程式清除其保留狀態以避免產生外部管理成本。
傳遞計數的影響
工作階段內容中每個訊息的傳遞計數定義，與沒有工作階段情況下的定義略有不同。 以下是摘要說明傳遞計數何時遞增的資料表。
| 案例 | 訊息的傳遞計數是否會遞增 |
|---|---|
| 已接受工作階段，但工作階段鎖定過期 (由於逾時) | Yes |
| 已接受工作階段、未完成工作階段內的訊息 (即使已鎖定)，且已關閉工作階段 | No |
| 已接受工作階段，完成了訊息，然後已明確關閉工作階段 | N/A (這是標準流程。這裡的訊息會從工作階段中移除) |
要求-回應模式
要求-回應模式是一種妥善建立的整合模式，可讓傳送者應用程式傳送要求，並提供一種方法讓接收者將回應正確地傳回給傳送者應用程式。 此模式通常需要一個短期佇列或主題，以供應用程式將回應傳送至其中。 在本案例中，工作階段會提供具有類似語義的簡單替代方案。
多個應用程式可將其要求傳送至單一要求佇列，並將特定的標頭參數設定為唯一識別傳送者應用程式。 接收者應用程式可處理傳入佇列中的要求，並在已啟用工作階段的佇列上傳送回覆，將工作階段識別碼設定為傳送者在要求訊息上傳送的唯一識別碼。 然後，傳送要求的應用程式即可接收有關特定工作階段識別碼的訊息，並正確地處理回覆。
注意
傳送初始要求的應用程式應該知道工作階段識別碼，並使用此識別碼來接受工作階段，以便鎖定其預期回應的工作階段。 使用可唯一識別應用程式執行個體的 GUID 作為工作階段識別碼是個好主意。不應有任何工作階段處理常式或逾時指定在佇列的工作階段接收者上，以確保回應可由特定接收者鎖定和處理。
排序與工作階段
序號本身可保證訊息的佇列順序和擷取順序，但不保證處理順序，其需要工作階段。
假如，佇列中有三則訊息，以及有兩個取用者。
- 取用者 1 挑選訊息 1。
- 取用者 2 挑選訊息 2。
- 取用者 2 完成處理訊息 2 並挑選訊息 3，而取用者 1 尚未完成處理訊息 1。
- 取用者 2 完成處理訊息 3，而取用者 1 仍未完成處理訊息 1。
- 最後，取用者 1 完成處理訊息 1。
因此，訊息會依此順序進行處理：訊息 2、訊息 3 和訊息 1。 如果您需要依序處理訊息 1、2 和 3，則必須使用工作階段。
如果訊息只需要依序擷取，就不需要使用工作階段。 如果需要依序處理訊息，請使用工作階段。 相同的工作階段識別碼應該在屬於同一組的訊息上設定，可能訊息 1、4 和 8 為一組，另一組則為訊息 2、3 和 6。
訊息到期
針對佇列或主題 (已啟用工作階段) 的訂用帳戶，訊息會在工作階段層級遭到鎖定。 如果任何訊息的存留時間 (TTL) 到期，則根據在實體的訊息到期設定上啟用的無效信件處理方式，與該工作階段相關的所有訊息都將遭到刪除或變成無效訊息。 換句話說，如果工作階段中有單一訊息超過了 TTL，則該工作階段中的所有訊息都視為到期。 僅在有使用中的接聽程式時，訊息才會到期。 如需詳細資訊，請參閱訊息到期。
下一步
您可以在使用 Azure 入口網站、PowerShell、CLI、Resource Manager 範本、.NET、Java、Python 和 JavaScript 來建立佇列時，啟用訊息工作階段。 如需詳細資訊，請參閱啟用訊息工作階段。
請以您所選擇的語言嘗試各式範例，以探索 Azure 服務匯流排的功能。
- .NET
- Java
- Python
- JavaScript