共用方式為

服務匯流排佇列、主題和訂用帳戶

  • 發行項

Azure 服務匯流排支援可靠的訊息佇列和持久的發佈/訂閱傳訊。 構成「服務匯流排」中傳訊功能核心的傳訊實體包含佇列、主題與訂閱。

重要

如果您不熟悉 Azure 服務匯流排，請先閱讀什麼是 Azure 服務匯流排？，再瀏覽本文。

佇列

佇列會採取先進先出 (FIFO) 機制，將訊息傳遞給一或多個競爭取用者。 也就是說，接收者一般會按照訊息新增至佇列的順序，接收和處理訊息。 而且只有一個訊息取用者會收到並處理每個訊息。

影像，其中顯示服務佇列的運作方式。

使用佇列的主要優點是達成應用程式元件的暫時解耦。 換句話說，產生者 (傳送者) 和取用者 (接收者) 不必同時傳送和接收訊息，因為訊息會長期儲存在佇列中。 此外，產生者不必等待取用者的回覆，即可繼續處理及傳送訊息。

相關優點是負載調節，讓產生者和取用者可以用不同速率傳送和接收訊息。 在許多應用程式中，系統負載會隨著時間而有所不同。 但每個工作單位所需的處理時間一般固定不變。 使用佇列來作為訊息生產者與取用者的中繼，表示取用端應用程式只需要能處理平均負載，而不需處理尖峰負載。 佇列的深度會隨著連入負載的改變而增加和縮短。 就處理應用程式負載所需的基礎結構數量而言，這個功能可直接節省費用。 當負載增加時，可以新增更多的背景工作角色程序來讀取佇列中的訊息。 每個訊息僅由其中一個背景工作程序處理。 此外，這個提取型負載平衡機制可讓背景工作電腦獲得最佳利用，即使具備處理能力的背景工作電腦會以自己的最大速率提取訊息也一樣。 此模式通常稱為「競爭取用者」模式。

使用佇列作為訊息生產者和消費者之間的媒介，可提供元件之間固有的鬆散耦合。 因為產生者和取用者不知道彼此的存在，所以取用者可以升級，而不會對產生者造成任何影響。

建立佇列

您可以使用下列其中一個選項來建立佇列：

然後，使用以包括下列程式設計語言在內的各種程式設計語言所撰寫的用戶端來傳送和接收訊息：

接收模式

您可以指定兩種不同的模式，讓取用者可以從服務匯流排接收訊息。

  • 接收及刪除。 在此模式中，當服務匯流排收到取用者的要求時，它會將訊息標示為正在用，並將其傳回給取用者應用程式。 此模式是最簡單的模型。 最適合應用程式可容許在發生失敗時不處理訊息的情節。 若要了解此案例，請考慮取用者發出接收要求，接著系統在處理此要求之前當機的案例。 服務匯流排將訊息標示為已取用時，應用程式會在重新啟動時開始取用訊息。 這會遺漏損毀前取用的訊息。 這種流程通常稱為最多一次處理。
  • 瞄核鎖定。 在此模式中，接收作業變成兩個階段，因而有可能支援不容許遺失訊息的應用程式。

    1. 尋找下一個要取用的訊息、將其鎖定以防止其他取用者接收此訊息，然後將此訊息傳回應用程式。

    2. 應用程式處理完訊息之後，會要求服務匯流排服務完成接收流程的第二個階段。 該服務接著會將訊息標示為已取用。

      如果應用程式因為某些原因而無法處理訊息，可以要求服務匯流排服務放棄該訊息。 服務匯流排會將訊息解除鎖定，並使其可供相同的取用者或其他競爭取用者再度接收。 其次，有與鎖定相關聯的逾時。 如果應用程式無法在鎖定逾時到期之前處理訊息，則服務匯流排會解除鎖定訊息，並讓系統可以重新接收訊息。

      如果應用程式在處理訊息之後當機，來不及要求服務匯流排服務完成訊息，則服務匯流排會在重新啟動時將訊息重新傳遞至應用程式。 這種流程通常稱為至少處理一次。 也就是說，每個訊息至少會處理一次。 不過，但在特定狀況下，可能會重新傳遞相同訊息。 如果您的案例無法容許重複處理，請在應用程式中新增額外的邏輯來偵測重複項目。 如需詳細資訊，請參閱重複偵測，這稱為正好一次處理。

      注意

      如需這兩種模式的詳細資訊，請參閱《設定接收作業》。

主題和訂閱

佇列允許單一取用者處理訊息。 相較於佇列，主題和訂閱會使用發佈/訂閱模式來提供一對多的通訊形式。 調整為大量收件者時很實用。 每個發行的訊息都可供每個向主題註冊的訂用帳戶使用。 發行者會將訊息傳送至主題，而一或多個訂閱者會收到訊息的複本。

影像，其中顯示包含三個訂用帳戶的服務匯流排主題。

訂用帳戶可以使用更多的篩選來限制要接收的訊息。 發行者會以與將訊息傳送至佇列相同的方式，將訊息傳送至主題。 但取用者不會直接從主題接收訊息。 取用者會改為從主題的訂用帳戶接收訊息。 主題訂閱類似虛擬佇列，可接收要傳送至該主題的訊息複本。 取用者從訂用帳戶接收訊息的方式，與從佇列接收訊息的方式相同。

佇列的訊息傳送功能會直接對應至主題，而其訊息接收功能會對應至訂閱。 除此之外，這個功能表示訂閱支援本節前面所述有關佇列的相同模式︰競爭取用者、暫時解耦、負載調節和負載平衡。

建立主題和訂用帳戶

如前一節所述，建立主題與建立佇列相類。 您可以使用下列其中一個選項來建立主題和訂閱：

然後，使用以包括下列程式設計語言在內的各種程式設計語言所撰寫的用戶端，來傳送訊息給主題以及從訂閱接收訊息：

規則與動作

在許多案例中，必須以不同的方法處理具有特定特性的訊息。 若要實現這種處理方式，您可以設定訂閱尋找具有所需屬性的訊息，然後對這些屬性執行某些修改。 雖然服務匯流排訂閱可看見所有傳送至主題的訊息，但您只可能將部分的訊息複製到虛擬訂閱佇列。 使用訂閱篩選即可完成此篩選。 這類修改稱之為篩選動作。 建立訂用帳戶後，您可以提供以訊息屬性運算的篩選條件運算式。 屬性可以同時為系統屬性 (如 Label) 和自訂應用程式屬性 (如 StoreName)。在此案例中，SQL 篩選條件運算式為選用。 若沒有 SQL 篩選條件運算式，則會對訂閱的所有訊息執行在訂閱上定義的所有篩選動作。

如需完整的工作範例，請參閱 GitHub 上的 TopicFilter 範例。 如需篩選條件的詳細資訊，請參閱《主題篩選和動作》。

Java 訊息服務 (JMS) 2.0 實體

下列實體可透過 JAVA 訊息服務 (JMS) 2.0 API 存取。

  • 暫時性佇列
  • 暫時性主題
  • 共用永久性訂閱
  • 非共用永久性訂閱
  • 共用非永久性訂閱
  • 非共用非永久性訂閱

深入了解 JMS 2.0 實體，以及如何使用這些實體。

快速實體

已針對高輸送量和降低延遲案例建立快速實體。 使用快速實體時，如果將訊息傳送至佇列或主題，則不會立即儲存在訊息存放區中。 相反地，一開始便會在記憶體中快取此訊息。 在延遲之後，保留在實體中的訊息會寫入訊息存放區，此時這些訊息會受到保護，避免因中斷而遺失。

在一般實體中，任何執行階段作業 (例如傳送、完成、放棄、無效化) 會先保存至存放區，而且才向用戶端認可為成功。 在快速實體中，執行階段作業會先向用戶端認可為成功，稍後才延遲保存至存放區。 因此，如果機器重新啟動或發生硬體問題，某些認可的執行階段間作業可能完全無法保存。 這表示用戶端會透過快速實體取得較低的延遲和更高的輸送量，代價是潛在的資料遺失和/或重新傳遞訊息。

此外，經過一段時間後，服務匯流排內已執行許多最佳化，這表示快速實體的輸送量和延遲優勢目前已降到最低。 此外，服務匯流排的進階層不支援快速實體。 因此，目前不建議使用此功能。

下一步

請嘗試所選語言的範例：

如需使用舊版 .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 的官方支援和更新。 如需詳細資訊，請參閱支援淘汰公告。