Azure 服務總線會話允許聯合和排序處理未系結的相關訊息序列。 會話可在 先出先出 （FIFO） 和 要求回應 模式中使用。 本文說明如何在使用服務總線時，使用會話來實作這些模式。
備註
基本層的服務匯流排並不支援工作階段。 標準和進階層支援會話。 如需這些階層之間的差異，請參閱服務匯流排定價。
先入、先出（FIFO） 模式
若要在處理來自服務總線佇列或訂用帳戶的訊息時達成 FIFO 處理，請使用會話。 服務總線對於訊息之間關聯性的本質並不具規範性，也不會定義用來判斷訊息序列開始或結束位置的特定模型。
傳送者可以在將訊息提交至主題或佇列時起始會話，方法是將 會話標識碼 屬性設定為應用程式所定義的唯一標識符。 在 AMQP 1.0 通訊協定層級，此值會對應至 group-id 屬性。
在會話感知佇列或訂用帳戶上，至少有一個訊息具有會話標識符時，會話就會存在。 一旦會話存在，就沒有明確的時間或 API 指定會話什麼時候會到期或消失。 理論上，今天可以收到會話的訊息，一年後收到下一則訊息，只要會話 ID 相符，從服務總線的角度來看，這些會話就是相同的。
不過，應用程式通常會定義一組相關訊息開始和結束的位置。 服務總線不會強加任何特定規則。 例如，您的應用程式可以將第一則訊息的 Label 屬性設定為 start、中繼訊息為內容，以及最後一則訊息結束。 內容訊息的相對位置可以計算為目前訊息 SequenceNumber 與開始訊息 SequenceNumber 的差異。
這很重要
當佇列或訂用帳戶上啟用會話時，用戶端應用程式 就無法再 傳送/接收一般訊息。 用戶端必須先設定會話標識碼，然後接受會話，才能作為會話的一部分來傳送和接收訊息。 用戶端仍可能會查看已啟用會話的佇列或訂用帳戶。 請參閱 訊息流覽。
會話的 API 存在於佇列和訂用帳戶用戶端上。 有兩種方式可以接收會話和訊息：命令式模型、手動控制接收訊息的時機和方式，以及處理程式型模型，可透過自動管理訊息循環和處理來簡化專案。
針對範例，請使用 範例 一節中的連結。
會話功能
會話提供交錯訊息數據流的並行解構，同時保留和保證已排序的傳遞。
用戶端會建立會話接收者以接受會話。 當用戶端接受並保持會話時，用戶端會對於佇列或訂閱中具有該會話的 會話識別碼 的所有訊息持有獨佔鎖定。 它對所有稍後抵達並具備 會話標識碼 的訊息保留獨佔鎖定。
當您在接收者上呼叫 close 方法或鎖定到期時，即會釋放鎖定。 接收裝置上也有更新鎖定的方法。 與其如此，您可以使用自動鎖續期功能，並指定您想要持續更新鎖定的期限。 會話鎖應該被視為檔案的獨佔鎖，這意味著應用程式應該一旦不再需要會話或不期望接收任何進一步的訊息時立即關閉會話。
當多個並行接收者從佇列提取時，就會將屬於特殊工作階段的訊息分派給目前保有該工作階段之鎖定的特定接收者。 透過該作業，一個佇列或訂閱中的交錯訊息串流會被完整地解多工給不同的接收者，且這些接收者也可以在不同的用戶端電腦上運行，因為鎖定管理是在服務總線的服務端進行的。
上圖顯示三個並行會話接收者。 一個具有 SessionId = 4 的會話沒有作用中、擁有的用戶端，這表示不會從這個特定會話傳遞任何訊息。 會話在許多方面的運作方式類似於子佇列。
會話接收者持有的會話鎖定是一種包含訊息鎖定的傘，這些訊息鎖定用於預覽鎖定結算模式。 只有一個接收者可以鎖定會話。 接收者可能會有許多正在傳輸的訊息，但這些訊息會按順序接收。 將訊息放棄後，會在下一次接收作業中再次提供相同的訊息。
訊息會話狀態
在大規模、高可用性的雲端系統中處理工作流程時，與特定會話相關聯的工作流程處理程式必須能夠從非預期的失敗中復原，而且可以在工作開始的不同進程或計算機上繼續部分完成的工作。
工作階段狀態設備可在訊息代理程式內啟用訊息工作階段的應用程式定義批注，以便在新處理器取得會話時，與該工作階段相關的記錄處理狀態立即可供使用。
從服務總線的觀點來看，訊息會話狀態是一個不透明的二進位物件，可保存一個訊息大小的數據，服務總線標準為 256 KB，服務總線進階為 100 MB。 相對於會話的處理狀態可以保留在會話狀態內，或會話狀態可以指向保存這類資訊的一些儲存位置或資料庫記錄。
您可以在工作階段接收者物件上找到用於管理工作階段狀態的方法SetState和GetState。 先前沒有狀態的會話會傳回 GetState 的 Null 參考。 先前設定的工作階段狀態可以藉由將 null 傳遞到接收者的 SetState 方法來清除。
只要未清除（返回null），會話狀態即使在會話中的所有訊息都被消耗後仍然保持。
佇列中或訂用帳戶中保留的會話狀態會計入該實體的記憶體配額。 當應用程式結束會話時，建議清除其保留的狀態，以減少外部管理成本。
傳遞次數的影響
會話內容中每個訊息的傳遞計數定義會與缺少會話時的定義稍有不同。 以下是傳遞計數遞增時的數據表摘要。
| 情境 | 訊息的傳遞次數是否已增加 |
|---|---|
| 會話已被接受，但會話鎖定已過期（因為超時） | 是的 |
| 會話已被接受，會話中的訊息尚未完成（即使它們已鎖定），且會話已關閉。 | 否 |
| 會話被接受、訊息已完成，然後會話被明確關閉。 | 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 服務匯流排的功能。
- 。網
- 爪哇島
- 蟒
- JavaScript