訊息排序和時間戳記
排序和時間戳記是隨時可以在所有服務匯流排實體上啟用的兩項功能，且會經由接收或瀏覽訊息的 SequenceNumber 和 EnqueuedTimeUtc 屬性呈現。
在重視訊息絕對順序和/或客戶需要值得信賴之訊息唯一識別碼的情況下，訊息代理程式會為訊息加上與佇列或主題相關的連貫遞增序號。 對於分割的實體，發行的序號與分割區相關。
序號
SequenceNumber 值是指派給訊息的唯一 64 位元整數，會由訊息代理程式和函式所接收並儲存，以作為內部識別碼。 對於分割的實體，最前面的 16 位元會反映分割區識別碼。 當 64 位元或 48 位元 (不包括磁碟分割識別碼的 16 位元) 範圍用盡時，序號會變換為零。
序號由中央和中立的授權單位指派 (而非用戶端)，因此可以如唯一識別碼般值得信賴。 其也代表真正的抵達順序，而且在當作順序準則時還比時間戳記來得精準。因為在極端訊息速率的情況下，時間戳記的解析度可能會不夠精確，另外當訊息代理程式擁有權在節點間轉換時，時間戳記可能會受到時鐘誤差的影響 (雖然影響很微小)。
在諸如商品數量有限，先買先贏、賣完為止的商務案例中，絕對抵達順序至關重要。演唱會門票的銷售即是一例。
時間戳記
時間戳記功能可成為中性、值得信賴的依據，其精準地記錄訊息抵達時的 UTC 時間，並反映在 EnqueuedTimeUtc 屬性中。 這個值對於仰賴截止日期的商務案例來說很實用，例如工作項目已在某天的午夜之前提交，不過處理進度卻遠遠落後佇列的待處理項目。
注意
序號本身可保證訊息的佇列順序和擷取器順序，但不包含處理順序，處理順序需要工作階段。
例如，佇列中有 5 則訊息和 2 個取用者。 取用者 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。
如需詳細資訊，請參閱服務匯流排訊息工作階段。
排定的訊息
您可以將訊息提交到佇列或主題，以利延遲處理。例如，排定作業讓系統在某個時間處理。 這項功能實現可靠的分散式時間型排程器。
排定的訊息在定義的加入佇列時間到來之前，不會在佇列中具體化。 在時間到來之前，您可以取消排定的訊息。 取消即是刪除訊息。
您可以使用下列兩種方式，使用任何用戶端來排程訊息：
- 使用一般傳送 API，但在傳送之前先在訊息上設定
ScheduledEnqueueTimeUtc屬性。 - 使用排程訊息 API，同時傳遞一般訊息和排程的時間。 API 將傳回排定訊息的
SequenceNumber，稍後若有需要，您可以用來取消排定的訊息。
您也可以使用訊息瀏覽來探索排定的訊息與其序號。
排定之訊息的 SequenceNumber 唯有在訊息仍處於該排程狀態時有效。 當訊息轉換成作用中狀態時，系統會將訊息附加到佇列中，如同在當下立刻加入佇列，其中包括指派新的 SequenceNumber。
由於該功能會錨定在個別訊息上，而訊息只能加入佇列一次，因此服務匯流排不支援訊息的週期性排程。
注意
- 訊息加入佇列的時間，並不代表訊息會同時傳送。 訊息會加入佇列，但實際的傳送時間取決於佇列的工作負載及其狀態。
- 由於效能考量，排程訊息的啟用和取消是獨立的作業，不需要相互鎖定。 如果在啟動的同時取消訊息，則啟用程序不會撤銷，而且訊息仍會啟動。 此外，這可能會導致排程訊息的計數為負值。 若要盡可能避免此競爭條件，建議您避免將啟用和取消安排為連續作業。
搭配工作流程使用排定訊息
一般常會看到具有明確時間組成部分、執行時間較長的商務工作流程，例如雙因素身份驗證的 5 分鐘逾時、使用者確認電子郵件地址的一小時逾時，以及銀行和保險等領域的多天、週或月的長期組成部分。
這些工作流程通常是透過處理某些訊息來啟動，然後儲存一些狀態，接著排定訊息在稍後的時間繼續該程序。 NServiceBus 和 MassTransit 等架構可以更輕鬆地將所有這些元素整合在一起。
相關內容
若要深入了解服務匯流排傳訊，請參閱下列主題：