Fronty, témata a odběry služby Service BusService Bus queues, topics, and subscriptions

Microsoft Azure Service Bus podporuje sady založené na cloudu, objektově orientovaný middleware technologií, jako jsou služby Řízení front zpráv spolehlivého a trvalý publikování/odběr zpráv.Microsoft Azure Service Bus supports a set of cloud-based, message-oriented middleware technologies including reliable message queuing and durable publish/subscribe messaging. Tyto "zprostředkovaného" přenosu zpráv můžete představit jako odpojené funkce zasílání zpráv, které podporu publikování a odběru, časové oddělení a scénářům pomocí úlohy pro zasílání zpráv služby Service Bus pro vyrovnávání zatížení.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. Oddělená komunikace má mnoho výhod – klienti a servery se například můžou spojit podle potřeby a provádět své operace asynchronním způsobem.Decoupled communication has many advantages; for example, clients and servers can connect as needed and perform their operations in an asynchronous fashion.

Entity zasílání zpráv, které tvoří jádro možnosti zasílání zpráv ve službě Service Bus jsou fronty, témata a odběry a pravidla a akce.The messaging entities that form the core of the messaging capabilities in Service Bus are queues, topics and subscriptions, and rules/actions.

FrontyQueues

Fronty nabízejí First In, Out první doručování zpráv (metodou FIFO) na jeden nebo několik konkurenčních spotřebitelů.Queues offer First In, First Out (FIFO) message delivery to one or more competing consumers. To znamená, že příjemci obvykle příjem a zpracování zpráv v pořadí, ve kterém byly přidány do fronty, a jenom jeden spotřebitel zprávy obdrží a zpracuje každou zprávu.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. Klíčovou výhodou použití front je dosáhnout "časové oddělení" komponent aplikace.A key benefit of using queues is to achieve "temporal decoupling" of application components. Jinými slovy producenti (odesílatelé) a spotřebitelé (příjemci) nemají k odesílání a přijímání zpráv ve stejnou dobu, protože zprávy se ukládají odolným způsobem ve frontě.In other words, the producers (senders) and consumers (receivers) do not have to be sending and receiving messages at the same time, because messages are stored durably in the queue. Producent navíc není nutné čekat na odpověď od příjemce, aby bylo možné pokračovat se zpracováním a odesláním zprávy.Furthermore, the producer does not have to wait for a reply from the consumer in order to continue to process and send messages.

Výhodou je, "vyrovnávání zátěže," umožňující odesílatelům a spotřebitelům umožňuje odesílat a přijímat zprávy různými rychlostmi.A related benefit is "load leveling," which enables producers and consumers to send and receive messages at different rates. V mnoha aplikacích zatížení systému může postupně měnit; Nicméně zpracování čas potřebný pro každou jednotku práce je obvykle stálá.In many applications, the system load varies over time; however, the processing time required for each unit of work is typically constant. Propojovací producenti a spotřebitelé zpráv s frontou znamená, že spotřebitelskou aplikací pouze musí být zřízená být schopná zpracovat průměrné zatížení namísto zátěž ve špičce.Intermediating message producers and consumers with a queue means that the consuming application only has to be provisioned to be able to handle average load instead of peak load. S měnící se příchozí zátěží se mění hloubka fronty.The depth of the queue grows and contracts as the incoming load varies. Tato možnost znamená přímou úsporu nákladů s ohledem na velikost infrastruktury nutné pro zvládání zatížení aplikace.This capability directly saves money with regard to the amount of infrastructure required to service the application load. Při rostoucí zátěži, lze přidat další pracovní procesy pro čtení z fronty.As the load increases, more worker processes can be added to read from the queue. Každou zprávu zpracovává jen jeden pracovní proces.Each message is processed by only one of the worker processes. Kromě toho tato Vyrovnávání zatížení založené na operaci pull umožňuje optimální využívání pracovních počítačů i v případě, že jde o výpočetní výkon se liší pracovní počítače podle jejich vlastní maximální rychlostí o přijetí změn zprávy.Furthermore, this pull-based load balancing allows for optimum use of the worker computers even if the worker computers differ with regard to processing power, as they pull messages at their own maximum rate. Tento model se často označovány jako vzor "soutěžit příjemce".This pattern is often termed the "competing consumer" pattern.

Použití front pro zprostředkující mezi producenti a spotřebitelé zpráv poskytuje vlastní volné párování mezi komponentami.Using queues to intermediate between message producers and consumers provides an inherent loose coupling between the components. Protože producenti a spotřebitelé nemají mezi sebou, je možné upgradovat příjemce bez nutnosti žádný vliv na výrobce.Because producers and consumers are not aware of each other, a consumer can be upgraded without having any effect on the producer.

Vytvoření frontyCreate queues

Vytvoření fronty pomocí webu Azure portal, PowerShell, rozhraní příkazového řádku, nebo šablon Resource Manageru.You create queues using the Azure portal, PowerShell, CLI, or Resource Manager templates. Potom odesílat a přijímat zprávy pomocí QueueClient objektu.You then send and receive messages using a QueueClient object.

Rychle se naučíte, jak vytvořit frontu, pak odesílání a příjem zpráv z fronty a, najdete v článku rychlých startů pro jednotlivé metody.To quickly learn how to create a queue, then send and receive messages to and from the queue, see the quickstarts for each method. Více podrobný kurz o tom, jak používat fronty, naleznete v tématu Začínáme s frontami služby Service Bus.For a more in-depth tutorial on how to use queues, see Get started with Service Bus queues.

Pracovní ukázku najdete v tématu BasicSendReceiveUsingQueueClient ukázka na Githubu.For a working sample, see the BasicSendReceiveUsingQueueClient sample on GitHub.

Zobrazí režimyReceive modes

Můžete zadat dva různé režimy, ve kterých Service Bus přijme zprávy: ReceiveAndDelete nebo PeekLock.You can specify two different modes in which Service Bus receives messages: ReceiveAndDelete or PeekLock. V ReceiveAndDelete režimu operace receive je jednorázová; to znamená, když Service Bus přijme požadavek, označí zprávu jako spotřebovávanou a vrátí ji do aplikace.In the ReceiveAndDelete mode, the receive operation is single-shot; that is, when Service Bus receives the request, it marks the message as being consumed and returns it to the application. ReceiveAndDelete režimu je nejjednodušší model a funguje nejlépe pro scénáře, ve kterých aplikace může tolerovat možnost, není zpracovává zprávu, pokud dojde k chybě.ReceiveAndDelete mode is the simplest model and works best for scenarios in which the application can tolerate not processing a message if a failure occurs. Informace o tom tento scénář, vezměte v úvahu scénář, ve kterém spotřebitel požadavek na přijetí a poté dojde k chybě před její zpracování.To understand this scenario, consider a scenario in which the consumer issues the receive request and then crashes before processing it. Vzhledem k tomu, že Service Bus, označí zprávu jako spotřebovávanou, když se aplikace restartuje a začne znovu přijímat zprávy, ji budou pravděpodobně nenalezlo zprávu, která se spotřebovala před pádem vynechá.Because Service Bus marks the message as being consumed, when the application restarts and begins consuming messages again, it will have missed the message that was consumed prior to the crash.

V PeekLock režimu operace obdržení stane dvoufázová, takže je možné to podporuje aplikace, které nemůžou tolerovat vynechání zpráv.In PeekLock mode, the receive operation becomes two-stage, which makes it possible to support applications that cannot tolerate missing messages. Když Service Bus přijme požadavek, najde zprávu, který se má používat, uzamkne ji ostatní uživatelé z dešifrujete proti a vrátí ji do aplikace.When Service Bus receives the request, it finds the next message to be consumed, locks it to prevent other consumers from receiving it, and then returns it to the application. Poté, co aplikace dokončí zpracování zprávy (nebo spolehlivě uloží pro pozdější zpracování), dokončení druhé fáze přijetí voláním CompleteAsync na přijatou zprávu.After the application finishes processing the message (or stores it reliably for future processing), it completes the second stage of the receive process by calling CompleteAsync on the received message. Když Service Bus uvidí CompleteAsync volání, označí zprávu jako spotřebovávanou.When Service Bus sees the CompleteAsync call, it marks the message as being consumed.

Pokud aplikace nedokáže zpracovat zprávu z nějakého důvodu, může zavolat AbandonAsync metoda na přijatou zprávu (místo CompleteAsync).If the application is unable to process the message for some reason, it can call the AbandonAsync method on the received message (instead of CompleteAsync). Tato metoda umožňuje využívat služby Service Bus zprávu odemkne a zpřístupní ji pro další přijetí, stejný příjemce nebo jiných konkurenčních spotřebitelů.This method enables Service Bus to unlock the message and make it available to be received again, either by the same consumer or by another competing consumer. Za druhé časový limit přidružené k uzamčení a pokud se aplikaci nepodaří zprávu zpracovat před zámku vyprší časový limit (například pokud aplikace spadne), pak služby Service Bus zprávu odemkne a zpřístupňuje je k dispozici bude přijetí) v podstatě provádění AbandonAsync operace ve výchozím nastavení).Secondly, there is a timeout associated with the lock and if the application fails to process the message before the lock timeout expires (for example, if the application crashes), then Service Bus unlocks the message and makes it available to be received again (essentially performing an AbandonAsync operation by default).

V případě, že aplikace spadne po zpracování zprávy, ale předtím, než CompleteAsync požadavku, zprávu je víckrát do aplikace při restartování.In the event that the application crashes after processing the message, but before the CompleteAsync request is issued, the message is redelivered to the application when it restarts. Tento proces se často nazývá nejméně jednou zpracování; to znamená, že každá zpráva se zpracuje alespoň jednou.This process is often called At Least Once processing; that is, each message is processed at least once. Ale v určitých situacích může doručit víckrát.However, in certain situations the same message may be redelivered. Pokud scénář nejde tolerovat duplicitní zpracování, pak se vyžaduje další logiku v aplikaci duplicity, které lze dosáhnout na základě MessageId vlastnosti zprávy, která zůstává konstantní napříč pokusy o doručení.If the scenario cannot tolerate duplicate processing, then additional logic is required in the application to detect duplicates, which can be achieved based upon the MessageId property of the message, which remains constant across delivery attempts. Tato funkce se označuje jako právě jednou zpracování.This feature is known as Exactly Once processing.

Témata a předplatnáTopics and subscriptions

Na rozdíl od front, ve kterých každou zprávu zpracuje jeden spotřebitel, témata a předplatná zadat jeden mnoho forma komunikace, publikování/odběr vzor.In contrast to queues, in which each message is processed by a single consumer, topics and subscriptions provide a one-to-many form of communication, in a publish/subscribe pattern. Užitečné pro škálování na velký počet příjemců, každá publikovaná zpráva je k dispozici všem odběrům registrovaným pro příslušné téma.Useful for scaling to large numbers of recipients, each published message is made available to each subscription registered with the topic. Zprávy odeslané do tématu a doručí do jednoho nebo více přidružených předplatných, v závislosti na pravidel filtrů, které lze nastavit na základě za předplatné.Messages are sent to a topic and delivered to one or more associated subscriptions, depending on filter rules that can be set on a per-subscription basis. Předplatná můžete použít další filtry pro omezení, které chtějí dostávat zprávy.The subscriptions can use additional filters to restrict the messages that they want to receive. Se odesílají zprávy do tématu stejným způsobem jsou odeslána do fronty, ale nejsou přijaty zprávy z tématu přímo.Messages are sent to a topic in the same way they are sent to a queue, but messages are not received from the topic directly. Místo toho byly přijaty z předplatných.Instead, they are received from subscriptions. Předplatné tématu se podobá virtuální frontě, která obdrží kopii zprávy odeslané do tématu.A topic subscription resembles a virtual queue that receives copies of the messages that are sent to the topic. Dostávají zprávy z odběru identicky způsobu, jakým dostali z fronty.Messages are received from a subscription identically to the way they are received from a queue.

Mimo jiné porovnání funkce zasílání zpráv pro fronty mapuje přímo na téma a jeho funkce přijímají zprávy se mapuje na předplatné.By way of comparison, the message-sending functionality of a queue maps directly to a topic and its message-receiving functionality maps to a subscription. Tato funkce mimo jiné znamená, že předplatné podporovat stejné vzorce popsané dříve v této části s ohledem na front: konkurence, časové oddělení, Vyrovnávání zatížení a vyrovnávání zatížení.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.

Vytvoření témat a odběrůCreate topics and subscriptions

Vytvoření tématu je podobné jako vytvoření fronty, jak je popsáno v předchozí části.Creating a topic is similar to creating a queue, as described in the previous section. Potom odesílání zpráv s použitím TopicClient třídy.You then send messages using the TopicClient class. Pokud chcete přijímat zprávy, můžete vytvořit jeden nebo více odběrů na téma.To receive messages, you create one or more subscriptions to the topic. Podobně jako u front, jsou zprávy přijímány pomocí předplatného SubscriptionClient místo objektu QueueClient objektu.Similar to queues, messages are received from a subscription using a SubscriptionClient object instead of a QueueClient object. Vytvoření klienta předplatného, předejte název tématu, název předplatného a (volitelně) režim receive jako parametry.Create the subscription client, passing the name of the topic, the name of the subscription, and (optionally) the receive mode as parameters.

Pro úplný práce příkladu najdete v článku BasicSendReceiveUsingTopicSubscriptionClient ukázka na Githubu.For a full working example, see the BasicSendReceiveUsingTopicSubscriptionClient sample on GitHub.

Pravidla a akceRules and actions

V mnoha případech je nutné zpracovat zprávy, které mají určité charakteristiky různými způsoby.In many scenarios, messages that have specific characteristics must be processed in different ways. Pokud chcete povolit toto zpracování, můžete nakonfigurovat odběry najít zprávy, které mají požadované vlastnosti a pak provést některé změny na tyto vlastnosti.To enable this processing, you can configure subscriptions to find messages that have desired properties and then perform certain modifications to those properties. Zatímco odběry služby Service Bus zobrazit všechny zprávy odeslané do tématu, kopírovat můžete pouze podmnožinu těchto zpráv do fronty virtuální odběru.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. Toto filtrování se provádí pomocí filtry předplatných.This filtering is accomplished using subscription filters. Tyto změny se nazývají akce filtru.Such modifications are called filter actions. Když se předplatné, můžete zadat výraz filtru, který funguje ve vlastnostech zprávy systému vlastnosti (například popisek) a vlastní aplikace (například StoreName.) V tomto případě; je volitelný výraz filtru SQL bez výraz filtru SQL se provede u všech zpráv pro dané předplatné libovolný filtr akce definované v rámci předplatného.When a subscription is created, you can supply a filter expression that operates on the properties of the message, both the system properties (for example, Label) and custom application properties (for example, StoreName.) The SQL filter expression is optional in this case; without a SQL filter expression, any filter action defined on a subscription will be performed on all the messages for that subscription.

Pro úplný práce příkladu najdete v článku TopicSubscriptionWithRuleOperationsSample ukázka na Githubu.For a full working example, see the TopicSubscriptionWithRuleOperationsSample sample on GitHub.

Další informace o hodnotách filtru je to možné, naleznete v dokumentaci pro SqlFilter a SqlRuleAction třídy.For more information about possible filter values, see the documentation for the SqlFilter and SqlRuleAction classes.

Další postupNext steps

Další informace a příklady použití zasílání zpráv Service Bus najdete v následujících Pokročilá témata:For more information and examples of using Service Bus messaging, see the following advanced topics: