訊息排序和時間戳記
排序和時間戳是所有 服務匯流排 實體上一律啟用的兩項功能，並透過SequenceNumber已接收或瀏覽訊息的 和 EnqueuedTimeUtc 屬性浮出水面。
對於訊息的絕對順序很重要和/或取用者需要訊息的可信任唯一標識符的情況下，訊息代理程式會戳記具有無間距、相對於佇列或主題的序號增加的訊息。 對於數據分割實體，序號會相對於數據分割發出。
序號
SequenceNumber 值是指派給訊息的唯一 64 位整數，因為訊息代理程式接受並儲存為其內部識別符。 對於分割實體，最上層的16位會反映分割區標識碼。 當 48/64 位範圍用盡時，序號會變換為零。
序號可以信任為唯一標識符，因為它是由中央和中性授權單位所指派，而不是由用戶端指派。 它也代表抵達的真正順序，而且比時間戳更精確為訂單準則，因為時間戳在極端訊息速率下可能沒有足夠的解析度，而且在節點之間轉換訊息代理程式擁有權時，可能會受限於（但最小）時鐘誤差。
例如，絕對抵達訂單很重要，例如，在供應最後，供應量有限的供應商品數量有限時，會以先到先得的方式提供服務：音樂會門票銷售是範例。
時間戳記
時間戳功能可作為中性且值得信任的授權單位，可準確擷取訊息抵達的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。
由於此功能錨定於個別訊息，且訊息只能加入佇列一次，因此 服務匯流排 不支援訊息的週期性排程。
注意
訊息加入佇列時間並不表示訊息會同時傳送。 它會加入佇列，但實際的傳送時間取決於佇列的工作負載及其狀態。
注意
由於效能考慮，排程訊息的啟用和取消是獨立的作業，不需要相互鎖定。 如果訊息正在啟動且同時取消，則不會反轉啟用程式，而且訊息仍會啟動。 此外，這可能會導致排程訊息的負計數。 若要將此競爭條件降到最低，建議您避免排程啟動和取消作業， 並連續進行排程。
搭配工作流程使用排程的訊息
常見情況下，查看運行時間較長的商務工作流程，其具有明確的時間元件，例如 2 因素驗證的 5 分鐘逾時、使用者確認其電子郵件地址的時長逾時，以及銀行和保險等網域中的多天、周或月長時間元件。
這些工作流程通常會由處理某些訊息開始，然後儲存一些狀態，然後排程訊息以在稍後繼續處理。 NServiceBus 和 MassTransit 等架構可讓您更輕鬆地將所有這些元素整合在一起。
下一步
若要深入了解服務匯流排傳訊，請參閱下列主題：