Service Bus kuyrukları, konu başlıkları ve abonelikleriService Bus queues, topics, and subscriptions

Microsoft Azure Service Bus, güvenilir ileti sıraya alma gibi bulut tabanlı, iletiye yönelik ara yazılım teknolojilerini ve dayanıklı Yayımla/abone olma Mesajlaşma, bir kümesini destekler.Microsoft Azure Service Bus supports a set of cloud-based, message-oriented middleware technologies including reliable message queuing and durable publish/subscribe messaging. Bu "aracılı" Mesajlaşma işlevleri, ardından destek Yayımla-abone ol Mesajlaşma özelliklerini, zamana bağlı ayırma ve Yük Dengeleme senaryolarıyla Service Bus Mesajlaşma iş yükünü kullanarak ayrılmış olarak düşünülebilir.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. Ayrılmış iletişim birçok avantaj sunar. Örneğin, sunucular ve istemciler gerektiğinde bağlantı kurabilir ve kendi işlemlerini zaman uyumsuz olarak gerçekleştirebilir.Decoupled communication has many advantages; for example, clients and servers can connect as needed and perform their operations in an asynchronous fashion.

Service Bus Mesajlaşma özelliklerini temel oluşturan ileti kuyrukları, konular ve abonelikler ve kurallar/eylemlerden varlıklardır.The messaging entities that form the core of the messaging capabilities in Service Bus are queues, topics and subscriptions, and rules/actions.

KuyruklarQueues

Kuyrukları ilk giren, ilk kullanıma (FIFO) bir veya birden çok rakip tüketiciye ileti teslimi.Queues offer First In, First Out (FIFO) message delivery to one or more competing consumers. Diğer bir deyişle, alıcılar genellikle iletileri almak ve hangi kuyruğa eklenmiş olan ve yalnızca bir ileti tüketicisi alır ve her iletiyi işleyen sırada işlemek.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. Kuyrukları kullanmanın önemli bir avantajı, uygulama bileşenlerinin "zamana bağlı ayırma"'i elde etmektir.A key benefit of using queues is to achieve "temporal decoupling" of application components. İletileri arızaya kuyrukta depolandığından diğer bir deyişle, üreticiler (göndericiler) ve tüketicilerin (Alıcılar) aynı anda ileti alma ve gönderme gerekmez.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. Ayrıca, işlemek ve ileti göndermek devam etmek için bir yanıt için beklemek üretici yok.Furthermore, the producer does not have to wait for a reply from the consumer in order to continue to process and send messages.

", Üreticilerin ve tüketicilerin iletileri farklı hızlarda gönderip sağlayan Yük Dengeleme" bir avantaj ise.A related benefit is "load leveling," which enables producers and consumers to send and receive messages at different rates. Birçok uygulamada, sistem yükü, zaman içinde değişir; Ancak, her bir birimi, iş için gereken işleme süresi genellikle sabittir.In many applications, the system load varies over time; however, the processing time required for each unit of work is typically constant. Arasında bağlantı kurmak ileti üreticileri ve tüketicileri bir kuyruk aracılığıyla, kullanıcı uygulamanın yalnızca ortalama yük yoğun yük yerine işleyebilmesi için hazırlanması olduğunu anlamına gelir.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. Gelen yük hacmi değiştikçe kuyruğun derinliği artar ve daralır.The depth of the queue grows and contracts as the incoming load varies. Bu özellik uygulama yükünü sunmak için gerekli altyapı miktarını ilgili money doğrudan kaydeder.This capability directly saves money with regard to the amount of infrastructure required to service the application load. Yük arttıkça kuyruktan okunmak üzere daha fazla çalışan işlemi eklenebilir.As the load increases, more worker processes can be added to read from the queue. Her ileti yalnızca bir çalışan işlemi tarafından işlenir.Each message is processed by only one of the worker processes. Ayrıca, işleme gücü ile ilgili olarak çalışan bilgisayarlar farklılık gösterse bile, iletileri kendi maksimum hızında çekme olarak çalışan bilgisayarlar için en iyi kullanımı bu çekme tabanlı yük dengeleme sağlar.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. Bu düzen, genellikle "tüketici rakip" düzeni olarak adlandırılır.This pattern is often termed the "competing consumer" pattern.

Kuyruğa ileti üreticileri ve tüketicileri arasında ara kullanarak devredilen gevşek bağ modelini bileşenleri arasındaki sağlar.Using queues to intermediate between message producers and consumers provides an inherent loose coupling between the components. Üreticiler ve tüketiciler birbirinden farkında olmadığından, bir tüketici üretici herhangi bir etkisi olmadan yükseltilebilir.Because producers and consumers are not aware of each other, a consumer can be upgraded without having any effect on the producer.

Kuyruk oluşturmaCreate queues

Kuyrukları kullanarak oluşturduğunuz Azure portalında, PowerShell, CLI, veya Resource Manager şablonları.You create queues using the Azure portal, PowerShell, CLI, or Resource Manager templates. Daha sonra gönderebilir ve kullanarak ileti alma bir QueueClient nesne.You then send and receive messages using a QueueClient object.

Hızlıca bir kuyruk oluşturun, sonra göndermek ve ve kuyruktan ileti almak nasıl öğrenmek için bkz. hızlı başlangıçlar her yöntem için.To quickly learn how to create a queue, then send and receive messages to and from the queue, see the quickstarts for each method. Kuyrukları kullanma hakkında daha ayrıntılı bir öğretici için bkz: Service Bus kuyrukları ile çalışmaya başlama.For a more in-depth tutorial on how to use queues, see Get started with Service Bus queues.

Çalışma örnek için bkz: BasicSendReceiveUsingQueueClient örnek GitHub üzerinde.For a working sample, see the BasicSendReceiveUsingQueueClient sample on GitHub.

Modları almaReceive modes

Service Bus iletileri aldığı iki farklı mod belirtebilirsiniz: ReceiveAndDelete veya PeekLock.You can specify two different modes in which Service Bus receives messages: ReceiveAndDelete or PeekLock. İçinde ReceiveAndDelete modu alma işlemi tek; diğer bir deyişle, Service Bus bir istek aldığında, iletiyi kullanılıyor olarak işaretler ve uygulamaya döndürür.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 modu en basit modeldir ve içinde uygulama tolere edebilen bir hata oluşursa bir iletiyi işlememeye izin senaryolarda en iyi şekilde çalışır.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. Bu senaryo anlamak için hangi tüketici alma isteği bildirdiğini ve ardından işlenmeden önce kilitleniyor bir senaryo düşünün.To understand this scenario, consider a scenario in which the consumer issues the receive request and then crashes before processing it. Service Bus iletisi, uygulama yeniden başlatılıp iletileri tekrar kullanmaya başladığında, Tüketilmekte olan olarak işaretlendikleri çökmenin öncesinde kullanılan iletiyi atlamış olur.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.

İçinde PeekLock modu alma işlemi olur iki aşamalı hangi, atlanan iletilere veremeyen uygulamaları desteklemenin mümkün kılar.In PeekLock mode, the receive operation becomes two-stage, which makes it possible to support applications that cannot tolerate missing messages. Service Bus bir istek aldığında, kullanılacak sonraki iletiyi bulur, diğer tüketicilerin iletiyi almasını engellemek için kilitler ve ardından uygulamaya döndürür.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. Uygulama iletiyi işlemeyi tamamladıktan sonra (veya güvenilir bir şekilde işlemek üzere depolar sonra) çağırarak alma işleminin ikinci aşamasını tamamlar CompleteAsync alınan iletide.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. Service Bus gördüğünde CompleteAsync çağrı, iletiyi kullanılıyor olarak işaretler.When Service Bus sees the CompleteAsync call, it marks the message as being consumed.

Uygulama herhangi bir nedenden dolayı iletiyi işleyemiyor ise çağırabilirsiniz AbandonAsync yöntemi alınan iletide (yerine 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). Bu yöntem, Service Bus'ın iletinin kilidini açmasına ve iletiyi aynı tüketici veya başka bir Yarışan tüketici tarafından tekrar alınabilir hale sağlar.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. İkincisi, kilit ile ilişkili bir zaman aşımı ve (örneğin, uygulama çökerse) Service Bus iletinin kilidini açar ve alınabilmesini halinde kilit zaman aşımı dolmadan önce iletiyi işlemek uygulama başarısız olursa kullanılabilir olması yeniden alınan) temelde gerçekleştiren bir AbandonAsync işlemi varsayılan olarak).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).

Uygulama ileti, ancak önce çökmesi durumunda, CompleteAsync isteği bildirilmeden, yeniden başlatıldığında ileti uygulamaya yeniden teslim.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. Bu işlem genellikle çağrılırken en az bir kez işleme; diğer bir deyişle, her ileti en az bir kez işlenir.This process is often called At Least Once processing; that is, each message is processed at least once. Ancak belirli durumlarda aynı ileti yeniden teslim edilebilir.However, in certain situations the same message may be redelivered. Yinelemeleri algılamak için uygulamanın ek mantık Required yinelenen işleme, senaryo kaldıramıyorsa, ulaşılabilecek temel MessageID arasında sabit mi kaldığını ileti özelliği teslim denemesi.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. Bu özellik olarak da bilinen tam bir kez işleniyor.This feature is known as Exactly Once processing.

Konular ve aboneliklerTopics and subscriptions

Kuyruklar, her ileti tek bir tüketici tarafından işlenir aksine konuları ve abonelikleri bir-çok form iletişim, sağladığınız bir Yayımlama/abonelik deseni.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. Ölçekleme alıcı çok sayıda kullanışlı, yayınlanan tüm iletilerin konuya kaydedilen her abonelik için kullanılabilir.Useful for scaling to large numbers of recipients, each published message is made available to each subscription registered with the topic. İletiler konu başlığına gönderilen ve bir veya daha fazla ilişkili Abonelikleri, abonelik başına temelinde ayarlanabilir filtre kuralları bağlı olarak teslim edilir.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. Abonelikler, almak istediğiniz iletileri kısıtlamak için ek filtreler kullanabilirsiniz.The subscriptions can use additional filters to restrict the messages that they want to receive. Gönderilen iletileri bir konuya aynı şekilde, bir kuyruğa gönderilir ancak iletilerin değil alındığı konu başlığından doğrudan.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. Bunun yerine, bunlar aboneliklerden alınır.Instead, they are received from subscriptions. Konu aboneliği konu başlığına gönderilen iletilerin kopyaların alan sanal kuyruğa benzer.A topic subscription resembles a virtual queue that receives copies of the messages that are sent to the topic. İletiler bir abonelikten bir kuyruktan alınan olduğu gibi aynı şekilde alınır.Messages are received from a subscription identically to the way they are received from a queue.

Karşılaştırma, yoluyla doğrudan bir konuya bir kuyruğa ileti gönderme işlevlerini eşler ve bir abonelik için ileti alma işlevselliğini eşler.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. Abonelikleri kuyruklar ile ilgili bu bölümde daha önce açıklanan aynı desenleri desteklemesini yanı sıra, bu özellik anlamına gelir: Yarışan tüketici, zamana bağlı ayırma, Yük Dengeleme ve Yük Dengeleme.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.

Konu başlıklarını ve abonelikleri oluşturmaCreate topics and subscriptions

Bir konu oluşturmak önceki bölümde açıklandığı gibi bir kuyruk oluşturma işlemiyle benzerdir.Creating a topic is similar to creating a queue, as described in the previous section. Ardından kullanarak ileti gönderme TopicClient sınıfı.You then send messages using the TopicClient class. İleti almak için konuya bir veya daha fazla abonelik oluşturun.To receive messages, you create one or more subscriptions to the topic. Benzer şekilde, kuyruklar, ileti kullanarak bir abonelik alındığında bir SubscriptionClient yerine Nesne bir QueueClient nesne.Similar to queues, messages are received from a subscription using a SubscriptionClient object instead of a QueueClient object. Konu adı, abonelik ve (isteğe bağlı) alma modu adını parametre olarak geçirmeyi abonelik istemcisi oluşturmak.Create the subscription client, passing the name of the topic, the name of the subscription, and (optionally) the receive mode as parameters.

Bir tam örnek, çalışıp BasicSendReceiveUsingTopicSubscriptionClient örnek GitHub üzerinde.For a full working example, see the BasicSendReceiveUsingTopicSubscriptionClient sample on GitHub.

Kurallar ve eylemlerRules and actions

Birçok senaryoda belirli özelliklere sahip iletileri farklı yollarla işlenmesi gerekir.In many scenarios, messages that have specific characteristics must be processed in different ways. Bu işlemeyi etkinleştirmek için istenen özellikleri ve sonra da bu özellikler için bazı değişiklikleri gerçekleştirin iletilerini bulmak için abonelik yapılandırabilirsiniz.To enable this processing, you can configure subscriptions to find messages that have desired properties and then perform certain modifications to those properties. Service Bus abonelikleri konu başlığına gönderilen tüm iletilerin görmenize rağmen bir alt kümesini iletiler aboneliğin sanal kuyruğuna yalnızca kopyalayabilirsiniz.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. Bu filtre, abonelik filtreleri kullanılarak gerçekleştirilir.This filtering is accomplished using subscription filters. Bu tür değişiklikler adlı filtre eylemlerini.Such modifications are called filter actions. Bir abonelik oluşturulurken, hem Sistem özellikleri iletinin özellikleri çalışır bir filtre ifadesi sağlayabilirsiniz (örneğin, etiket) ve özel uygulama özelliklerini (örneğin, StoreName.) SQL filtre ifadesini, bu durumda isteğe bağlıdır; bir SQL filtresi ifadesi, bu abonelik için tüm iletiler bir abonelikte tanımlanan herhangi bir filtre işlem gerçekleştirilir.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.

Bir tam örnek, çalışıp TopicSubscriptionWithRuleOperationsSample örnek GitHub üzerinde.For a full working example, see the TopicSubscriptionWithRuleOperationsSample sample on GitHub.

Olası filtre değerleri hakkında daha fazla bilgi için belgelere bakın SqlFilter ve SqlRuleAction sınıfları.For more information about possible filter values, see the documentation for the SqlFilter and SqlRuleAction classes.

Sonraki adımlarNext steps

Daha fazla bilgi ve Service Bus mesajlaşmasını kullanma örnekleri için aşağıdaki konulara bakın:For more information and examples of using Service Bus messaging, see the following advanced topics: