探索服務匯流排佇列、主題和訂用帳戶
構成服務匯流排中傳訊功能核心的傳訊實體，是佇列、主題與訂用帳戶，以及規則/動作。
佇列
佇列會採取先進先出 (FIFO) 機制，將訊息傳遞給一或多個競爭取用者。 也就是說，接收者一般會按照訊息新增至佇列的順序，接收和處理訊息。 而且只有一個訊息取用者會收到並處理每個訊息。 因為訊息會長期儲存在佇列中，產生者 (傳送者) 和取用者 (接收者) 不需要同時處理訊息。
相關優點是負載調節，讓產生者和取用者可以用不同速率傳送和接收訊息。 在許多應用程式中，系統負載會隨著時間而有所不同。 但每個工作單位所需的處理時間一般固定不變。 使用佇列來作為訊息生產者與取用者的中繼，表示取用端應用程式只需要能處理平均負載，而不需處理尖峰負載。
使用佇列作為訊息生產者和消費者之間的媒介，可提供元件之間固有的鬆散耦合。 因為生產者和取用者不知道彼此的存在，所以取用者升級不會影響到生產者。
您可以使用 Azure 入口網站、PowerShell、CLI 或Resource Manager 範本，建立佇列。 接著使用以 C#、JAVA、Python 和 JavaScript 撰寫的用戶端，傳送和接收訊息。
接收模式
您可以指定兩種不同的服務匯流排接收訊息模式：接收和刪除或查看鎖定。
接收和刪除
在此模式中，當服務匯流排收到取用者的要求時，其會將訊息標示為已取用，並將其傳回給取用者應用程式。 此模式是最簡單的模型。 最適合應用程式可容許在發生失敗時不處理訊息的情節。 例如，倘若消費者發出接收要求後，還來不及處理即告損毀。 服務匯流排將訊息標示為已取用時，應用程式會在重新啟動時開始取用訊息。 這會遺漏損毀前取用的訊息。
預覽鎖定
在此模式中，接收作業變成兩個階段，因而有可能支援不容許遺失訊息的應用程式。
尋找下一個要取用的訊息、將其鎖定以防止其他取用者接收此訊息，然後將此訊息傳回應用程式。
應用程式處理完訊息之後，會要求服務匯流排服務完成接收流程的第二個階段。 該服務接著會將訊息標示為已取用。
如果應用程式因為某些原因而無法處理訊息，可以要求服務匯流排服務放棄該訊息。 服務匯流排會將訊息解除鎖定，並使其可供相同的取用者或其他競爭取用者再度接收。 其次，有與鎖定相關聯的逾時。 如果應用程式無法在鎖定逾時到期之前處理訊息，則服務匯流排會解除鎖定訊息，並讓系統可以重新接收訊息。
主題和訂閱
佇列允許單一取用者處理訊息。 相較於佇列，主題和訂閱會使用發佈/訂閱模式來提供一對多的通訊形式。 調整為大量收件者時很實用。 每個發行的訊息都可供每個向主題註冊的訂用帳戶使用。 發行者會將訊息傳送至主題，而一或多個訂閱者會收到訊息的複本。
訂用帳戶可以使用更多的篩選來限制要接收的訊息。 發行者會以與將訊息傳送至佇列相同的方式，將訊息傳送至主題。 但取用者不會直接從主題接收訊息。 取用者會改為從主題的訂用帳戶接收訊息。 主題訂閱類似虛擬佇列，可接收要傳送至該主題的訊息複本。 取用者從訂用帳戶接收訊息的方式，與從佇列接收訊息的方式相同。
佇列的訊息傳送功能會直接對應至主題，而其訊息接收功能會對應至訂閱。 除此之外，這個功能表示訂閱支援本節前面所述有關佇列的相同模式︰競爭取用者、暫時解耦、負載調節和負載平衡。
規則與動作
在許多案例中，必須以不同的方法處理具有特定特性的訊息。 若要實現這種處理方式，您可以設定訂閱尋找具有所需屬性的訊息，然後對這些屬性執行某些修改。 雖然服務匯流排訂閱可看見所有傳送至主題的訊息，但您只能將部分的訊息複製到虛擬訂閱佇列。 使用訂閱篩選即可完成此篩選。 這類修改稱之為篩選動作。 建立訂用帳戶後，您可以提供以訊息屬性運算的篩選條件運算式。 屬性可以同時為系統屬性 (如 Label) 和自訂應用程式屬性 (如 StoreName)。在此案例中，SQL 篩選條件運算式為選用。 若沒有 SQL 篩選條件運算式，則會對訂用帳戶的所有訊息，執行在該訂用帳戶上定義的所有篩選動作。