服務匯流排佇列、主題和訂用帳戶Service Bus queues, topics, and subscriptions

Azure 服務匯流排支援一套以雲端為基礎、訊息導向的中介軟體技術,包括可靠的訊息佇列和持久的發佈/訂閱訊息。Azure Service Bus supports a set of cloud-based, message-oriented middleware technologies including reliable message queuing and durable publish/subscribe messaging. 這些代理訊息功能可以視為低耦合訊息功能,這些功能可支援使用服務匯流排訊息工作負載的發佈-訂閱、時態性分離和負載平衡案例。These brokered messaging capabilities can be thought of as decoupled messaging features that support publish-subscribe, temporal decoupling, and load-balancing scenarios using the Service Bus messaging workload. 分離通訊有許多優點。Decoupled communication has many advantages. 例如,用戶端和伺服器可以視需要連接,並以非同步方式進行作業。For example, clients and servers can connect as needed and do their operations in an asynchronous fashion.

在服務匯流排中形成訊息功能核心的訊息實體是 佇列主題和訂閱,以及規則/動作。The messaging entities that form the core of the messaging capabilities in Service Bus are queues, topics and subscriptions, and rules/actions.

佇列Queues

如果有一或多個競爭取用者,佇列會採取「先進先出」(FIFO) 訊息傳遞機制。Queues offer First In, First Out (FIFO) message delivery to one or more competing consumers. 也就是說,接收者通常會依將訊息新增至佇列的順序來接收和處理訊息。That is, receivers typically receive and process messages in the order in which they were added to the queue. 而且,只有一個訊息取用者會接收和處理每個訊息。And, only one message consumer receives and processes each message. 使用佇列的主要優點是達成 應用程式元件的時態性分離A key benefit of using queues is to achieve temporal decoupling of application components. 換句話說,生產者 (傳送者) 和取用者 (接收者) 不需要同時傳送和接收訊息。In other words, the producers (senders) and consumers (receivers) don't have to send and receive messages at the same time. 這是因為訊息會永久儲存在佇列中。That's because messages are stored durably in the queue. 此外,生產者不需要等待取用者的回復,即可繼續處理及傳送訊息。Furthermore, the producer doesn't have to wait for a reply from the consumer to continue to process and send messages.

相關的優點是 負載平衡,可讓生產者和取用者以不同的速率傳送和接收訊息。A related benefit is load-leveling, which enables producers and consumers to send and receive messages at different rates. 在許多應用程式中,系統負載會隨時間而改變。In many applications, the system load varies over time. 不過,每個工作單位所需的處理時間通常是常數。However, the processing time required for each unit of work is typically constant. 使用佇列作為訊息產生者和取用者表示取用應用程式只需要能夠處理平均負載,而不是尖峰負載。Intermediating message producers and consumers with a queue means that the consuming application only has to be able to handle average load instead of peak load. 佇列的深度會隨著連入負載的改變而增加和縮短。The depth of the queue grows and contracts as the incoming load varies. 就處理應用程式負載所需的基礎結構數量而言,這個功能可直接節省金錢。This capability directly saves money with regard to the amount of infrastructure required to service the application load. 當負載增加時,可以新增更多的背景工作角色程序來讀取佇列中的訊息。As the load increases, more worker processes can be added to read from the queue. 每個訊息僅由其中一個背景工作程序處理。Each message is processed by only one of the worker processes. 此外,這個提取型負載平衡可讓背景工作電腦獲得最佳使用,即使以自己的最大速率處理 power pull 訊息的工作者電腦也是一樣。Furthermore, this pull-based load balancing allows for best use of the worker computers even if the worker computers with processing power pull messages at their own maximum rate. 此模式通常稱為 競爭消費者 模式。This pattern is often termed the competing consumer pattern.

使用佇列在訊息產生者與取用者之間居中協調,可提供元件之間的固有鬆散結合。Using queues to intermediate between message producers and consumers provides an inherent loose coupling between the components. 因為生產者和取用者不知道彼此,所以可以升級取用者,而不會對生產者產生任何影響。Because producers and consumers aren't aware of each other, a consumer can be upgraded without having any effect on the producer.

建立佇列Create queues

您可以使用 Azure 入口網站PowerShellCLIResource Manager 範本來建立佇列。You can create queues using the Azure portal, PowerShell, CLI, or Resource Manager templates. 然後,使用以 c #JAVAPythonJavaScriptPHPRuby撰寫的用戶端來傳送和接收訊息。Then, send and receive messages using clients written in C#, Java, Python, JavaScript, PHP, and Ruby.

接收模式Receive modes

您可以指定兩種不同的模式,讓服務匯流排接收訊息。You can specify two different modes in which Service Bus receives messages.

  • 接收和刪除Receive and delete. 在此模式中,當服務匯流排收到來自取用者的要求時,它會將訊息標示為已取用,並將其傳回給取用者應用程式。In this mode, when Service Bus receives the request from the consumer, it marks the message as being consumed and returns it to the consumer application. 此模式是最簡單的模型。This mode is the simplest model. 它最適合用於應用程式在發生失敗時可容忍不處理訊息的案例。It works best for scenarios in which the application can tolerate not processing a message if a failure occurs. 若要了解此案例,請考慮取用者發出接收要求,接著系統在處理此要求之前當機的案例。To understand this scenario, consider a scenario in which the consumer issues the receive request and then crashes before processing it. 當服務匯流排將訊息標示為已使用時,應用程式會在重新開機時開始取用訊息。As Service Bus marks the message as being consumed, the application begins consuming messages upon restart. 它會遺漏在損毀之前所耗用的訊息。It will miss the message that it consumed before the crash.
  • 查看鎖定Peek lock. 在此模式中,接收作業會變成兩階段,因此可以支援無法容許遺漏訊息的應用程式。In this mode, the receive operation becomes two-stage, which makes it possible to support applications that can't tolerate missing messages.
    1. 尋找要使用的下一個訊息、將其 鎖定 以防止其他取用者接收此訊息,然後將訊息傳回給應用程式。Finds the next message to be consumed, locks it to prevent other consumers from receiving it, and then, return the message to the application.

    2. 在應用程式完成處理訊息之後,它會要求服務匯流排服務完成接收進程的第二個階段。After the application finishes processing the message, it requests the Service Bus service to complete the second stage of the receive process. 然後,服務會將 訊息標示為 已取用。Then, the service marks the message as being consumed.

      如果應用程式因某個原因而無法處理訊息,它可以要求服務匯流排服務 放棄 訊息。If the application is unable to process the message for some reason, it can request the Service Bus service to abandon the message. 服務匯流排會將訊息 解除鎖定 ,並使其可由相同的取用者或其他競爭取用者再次接收。Service Bus unlocks the message and makes it available to be received again, either by the same consumer or by another competing consumer. 其次,有一個與鎖定相關聯的 超時時間Secondly, there's a timeout associated with the lock. 如果應用程式無法在鎖定超時到期之前處理訊息,服務匯流排會將訊息解除鎖定,並使其可供再次接收。If the application fails to process the message before the lock timeout expires, Service Bus unlocks the message and makes it available to be received again.

      如果應用程式在處理訊息之後損毀,但在要求服務匯流排服務完成訊息之前,服務匯流排會在應用程式重新開機時重新傳遞該訊息。If the application crashes after it processes the message, but before it requests the Service Bus service to complete the message, Service Bus redelivers the message to the application when it restarts. 此程式通常至少會被呼叫 一次 處理。This process is often called at-least once processing. 也就是說,每個訊息至少會被處理一次。That is, each message is processed at least once. 不過,但在特定狀況下,可能會重新傳遞相同訊息。However, in certain situations the same message may be redelivered. 如果您的案例無法容許重複處理,請在您的應用程式中加入其他邏輯,以偵測重複項。If your scenario can't tolerate duplicate processing, add additional logic in your application to detect duplicates. 如需詳細資訊,請參閱重複偵測For more information, see Duplicate detection. 這項功能只稱為 一次 處理。This feature is known as exactly once processing.

      注意

      For more information about these two modes, see Settling receive operations.For more information about these two modes, see Settling receive operations.

主題和訂用帳戶Topics and subscriptions

佇列允許單一取用者處理訊息。A queue allows processing of a message by a single consumer. 相對於佇列、主題和訂用帳戶會在 發佈和訂閱 模式中提供一對多的通訊形式。In contrast to queues, topics and subscriptions provide a one-to-many form of communication in a publish and subscribe pattern. 它適合用來調整為大量的收件者。It's useful for scaling to large numbers of recipients. 每個已發佈的訊息都會提供給每個已註冊主題的訂用帳戶。Each published message is made available to each subscription registered with the topic. 發行者會將訊息傳送至主題,而一或多個訂閱者會收到訊息的複本,這取決於這些訂用帳戶上設定的篩選規則。Publisher sends a message to a topic and one or more subscribers receive a copy of the message, depending on filter rules set on these subscriptions. 訂用帳戶可以使用其他篩選器來限制他們想要接收的訊息。The subscriptions can use additional filters to restrict the messages that they want to receive. 發行者會以傳送訊息至佇列的相同方式,將訊息傳送至主題。Publishers send messages to a topic in the same way that they send messages to a queue. 但取用者不會直接從主題接收訊息。But, consumers don't receive messages directly from the topic. 相反地,取用者會從主題的訂用帳戶接收訊息。Instead, consumers receive messages from subscriptions of the topic. 主題訂用帳戶類似於虛擬佇列,同樣可接收已傳送到主題的訊息複本。A topic subscription resembles a virtual queue that receives copies of the messages that are sent to the topic. 取用者從訂用帳戶接收訊息的方式,與從佇列接收訊息的方式相同。Consumers receive messages from a subscription identically to the way they receive messages from a queue.

佇列的訊息傳送功能會直接對應至主題,而其訊息接收功能會對應至訂用帳戶。The message-sending functionality of a queue maps directly to a topic and its message-receiving functionality maps to a subscription. 除此之外,這個功能表示訂用帳戶支援本節前面所述有關佇列的相同模式︰競爭取用者、暫時分離、負載調節和負載平衡。Among other things, this feature means that subscriptions support the same patterns described earlier in this section with regard to queues: competing consumer, temporal decoupling, load leveling, and load balancing.

建立主題和訂用帳戶Create topics and subscriptions

按照上一節所述,建立主題類似於建立佇列。Creating a topic is similar to creating a queue, as described in the previous section. 您可以使用 Azure 入口網站PowerShellCLIResource Manager 範本來建立主題和訂用帳戶。You can create topics and subscriptions using the Azure portal, PowerShell, CLI, or Resource Manager templates. 然後,將訊息傳送至主題,並使用以 c #JAVAPythonJavaScriptPHPRuby撰寫的用戶端,從訂用帳戶接收訊息。Then, send messages to a topic and receive messages from subscriptions using clients written in C#, Java, Python, JavaScript, PHP, and Ruby.

執行和動作Rules and actions

在許多情況下,必須以不同的方式處理具有特定特性的訊息。In many scenarios, messages that have specific characteristics must be processed in different ways. 若要啟用這項處理,您可以設定訂用帳戶以尋找具有所需屬性的訊息,然後對這些屬性進行一些修改。To enable this processing, you can configure subscriptions to find messages that have desired properties and then perform certain modifications to those properties. 雖然服務匯流排訂用帳戶可看見所有傳送至主題的訊息,但您只可以將部分的訊息複製到虛擬訂用帳戶佇列。While Service Bus subscriptions see all messages sent to the topic, you can only copy a subset of those messages to the virtual subscription queue. 使用訂用帳戶篩選器即可完成這個篩選。This filtering is accomplished using subscription filters. 這類修改稱之為「篩選器動作」。Such modifications are called filter actions. 建立訂閱時,您可以提供可在訊息屬性上運作的篩選運算式。When a subscription is created, you can supply a filter expression that operates on the properties of the message. 這些屬性可以是系統屬性 (例如 標籤) 和自訂應用程式 (屬性(例如, StoreName)。在此情況下,) SQL 篩選運算式是選擇性的。The properties can be both the system properties (for example, Label) and custom application properties (for example, StoreName.) The SQL filter expression is optional in this case. 如果沒有 SQL 篩選運算式,就會在訂閱上定義的所有訊息上執行任何篩選動作。Without a SQL filter expression, any filter action defined on a subscription will be done on all the messages for that subscription.

如需完整的實用範例,請參閱 GitHub 上的 TopicSubscriptionWithRuleOperationsSample 範例For a full working example, see the TopicSubscriptionWithRuleOperationsSample sample on GitHub.

如需篩選的詳細資訊,請參閱 主題篩選和動作For more information about filters, see Topic filters and actions.

JAVA 訊息服務 (JMS) 2.0 實體Java message service (JMS) 2.0 entities

下列實體可透過 JAVA 訊息服務存取 (JMS) 2.0 API。The following entities are accessible through the Java message service (JMS) 2.0 API.

  • 暫存佇列Temporary queues
  • 暫存主題Temporary topics
  • 共用持久訂閱Shared durable subscriptions
  • 未共用的持久訂閱Unshared durable subscriptions
  • 共用的非持久訂閱Shared non-durable subscriptions
  • 未共用的非持久訂閱Unshared non-durable subscriptions

深入瞭解 JMS 2.0 實體 ,以及如何 使用它們Learn more about the JMS 2.0 entities and about how to use them.

下一步Next steps

如需使用服務匯流排傳訊的詳細資訊和範例,請參閱下列進階主題:For more information and examples of using Service Bus messaging, see the following advanced topics: