共用方式為

訊息延遲

  • 發行項

當佇列或訂用帳戶用戶端接收到其願意處理的訊息，但目前因為特殊情況而無法進行處理時，該實體可以選擇將訊息的擷取延遲至後續時段。 訊息仍位於佇列或訂用帳戶，但會先擱置。

注意

延後訊息不會過期，而且會在用戶端應用程式嘗試使用 API 和序號接收訊息之前自動移至寄不出的信件佇列。 這是依照設計的行為。 當客戶端嘗試擷取延遲的訊息時，會檢查 是否有過期的條件 ，並在已過期時移至寄不出的信件佇列。 只有在實體 （佇列或訂用帳戶） 啟用寄不出的信件功能時，才會將過期的訊息移至寄不出的子佇列。

範例案例

延遲是專為工作流程處理案例而建立的功能。 工作流程架構可能需要以特定順序處理特定作業。 他們可能必須延後處理一些已接收的訊息，直到其他訊息通知的指定工作完成為止。

訂單處理順序就是一個簡單的說明範例，其中來自外部付款提供者的付款通知會在系統將相符採購單從店面傳播到履行系統之前，便出現在系統中。 在此情況下，履行系統可能會延遲處理付款通知，直到沒有與其相關聯的訂單為止。 在交集案例中，來自不同來源的訊息會向前驅動工作流程，實時執行順序可能確實正確，但反映結果的訊息可能會順序錯亂。

總而言之，延遲有助於將訊息從送達順序重新排序為可處理它們的順序，同時又能將那些需要延後處理的訊息安全地保留在訊息存放區中。

如果訊息因為用於處理該訊息的特殊資源暫時無法使用而無法處理，但不應立即暫止訊息處理，則用來將該訊息放在一邊數分鐘的方法是，記住要在數分鐘內發佈已排程的訊息中的序號，並在已排程的訊息送達時，重新擷取延遲的訊息。 如果訊息處理常式倚賴資料庫來進行所有作業，而該資料庫暫時無法提供服務，則就不應該使用延遲，而是應該完全暫停接收訊息，直到資料庫再次可供使用為止。

擷取延遲的訊息

延遲的訊息會和所有其他作用中的訊息一起保留在主要佇列中 (與存留於子佇列中的無效信件訊息不同)，但您無法再使用一般的接收作業來接收訊息。 如果應用程式無法追蹤，則可以透過 訊息瀏覽或查看 來探索延遲的訊息。

若要擷取延後訊息，其擁有者會負責在延遲時記住 序號 。 任何知道延遲訊息序號的接收者都可以使用將序號視為參數的接收方法接收訊息。 如需序號的詳細資訊，請參閱訊息排序和時間戳記。

下一步

請以您所選擇的語言嘗試各式範例，以探索 Azure 服務匯流排的功能。

請在此處查看舊版 .NET 和 Java 用戶端程式庫的範例：

在 2026 年 9 月 30 日，我們將淘汰不符合 Azure SDK 準則的 Azure 服務匯流排 SDK 程式庫 WindowsAzure.ServiceBus、Microsoft.Azure.ServiceBus 和 com.microsoft.azure.servicebus。 我們也將結束 SBMP 通訊協定的支援，因此您將無法在 2026 年 9 月 30 日之後再使用此通訊協定。 請在該日期之前移轉至最新的 Azure SDK 程式庫，該程式庫提供重要的安全性更新和改進的功能。

雖然較舊的程式庫仍可在 2026 年 9 月 30 日之後使用，但它們將不再收到 Microsoft 的官方支援和更新。 如需詳細資訊，請參閱支援淘汰公告。