Depolama kuyrukları ve Service Bus kuyrukları-karşılaştırılan ve değişken maliyetliStorage queues and Service Bus queues - compared and contrasted

Bu makalede, bugün Microsoft Azure tarafından sunulan iki kuyruk türü arasındaki farklar ve benzerlikler analiz edilir: depolama kuyrukları ve Service Bus kuyrukları.This article analyzes the differences and similarities between the two types of queues offered by Microsoft Azure today: Storage queues and Service Bus queues. Bu bilgileri kullanarak ilgili teknolojileri karşılaştırabilir ve değiştirebilir ve gereksinimlerinizi en iyi şekilde karşılayan çözümü daha bilinçli bir karar verebilir.By using this information, you can compare and contrast the respective technologies and be able to make a more informed decision about which solution best meets your needs.

GirişIntroduction

Azure iki tür kuyruk mekanizmasını destekler: depolama kuyrukları ve Service Bus kuyrukları.Azure supports two types of queue mechanisms: Storage queues and Service Bus queues.

Azure depolama altyapısının bir parçası olan depolama kuyrukları, hizmetler içinde ve arasında güvenilir ve kalıcı mesajlaşma sağlayan basıt bir REST tabanlı Get/put/Peek arabirimi özelliği sunar.Storage queues, which are part of the Azure storage infrastructure, feature a simple REST-based GET/PUT/PEEK interface, providing reliable, persistent messaging within and between services.

Service Bus kuyruklar , kuyruğa almayı ve yayımlamayı/abone olmayı ve daha gelişmiş tümleştirme düzenlerini destekleyen, daha geniş bir Azure mesajlaşma altyapısının parçasıdır.Service Bus queues are part of a broader Azure messaging infrastructure that supports queuing as well as publish/subscribe, and more advanced integration patterns. Service Bus kuyrukları/konuları/abonelikleri hakkında daha fazla bilgi için bkz. Service Bus genel bakış.For more information about Service Bus queues/topics/subscriptions, see the overview of Service Bus.

Her iki sıraya alma teknolojisi de aynı anda mevcut olsa da, Azure depolama hizmetleri üzerinde oluşturulmuş adanmış bir sıra depolama mekanizması olarak depolama kuyrukları ilk sunulmuştur.While both queuing technologies exist concurrently, Storage queues were introduced first, as a dedicated queue storage mechanism built on top of Azure Storage services. Service Bus kuyrukları, birden fazla iletişim kuralını, veri sözleşmelerini, güven etki alanlarını ve/veya ağ ortamlarına yayılabilen uygulamaları veya uygulama bileşenlerini bütünleştirmek için tasarlanan daha geniş mesajlaşma altyapısının üzerine kurulmuştur.Service Bus queues are built on top of the broader messaging infrastructure designed to integrate applications or application components that may span multiple communication protocols, data contracts, trust domains, and/or network environments.

Teknoloji seçimi konularıTechnology selection considerations

Hem depolama kuyrukları hem de Service Bus kuyrukları, şu anda Microsoft Azure tarafından sunulan Message Queuing hizmetinin uygulamalarıdır.Both Storage queues and Service Bus queues are implementations of the message queuing service currently offered by Microsoft Azure. Her birinin biraz farklı bir özellik kümesi vardır. Bu, bir ya da diğerini seçebileceğiniz ya da çözmeyeceğiniz iş/teknik sorununuzun gereksinimlerine bağlı olarak her ikisini de kullanabilirsiniz.Each has a slightly different feature set, which means you can choose one or the other, or use both, depending on the needs of your particular solution or business/technical problem you are solving.

Belirli bir çözüm için hangi sıraya alma teknolojisinin amacına uygun olduğunu belirlerken, çözüm mimarları ve geliştiriciler bu önerileri göz önünde bulundurmalıdır.When determining which queuing technology fits the purpose for a given solution, solution architects and developers should consider these recommendations. Daha ayrıntılı bilgi için sonraki bölüme bakın.For more details, see the next section.

Çözüm mimarı/geliştiricisi olarak, şu durumlarda depolama kuyruklarını kullanmayı göz önünde bulundurmanız gerekir :As a solution architect/developer, you should consider using Storage queues when:

  • Uygulamanızın bir kuyrukta 80 GB 'den fazla ileti depolaması gerekir.Your application must store over 80 GB of messages in a queue.
  • Uygulamanız, sıranın içindeki bir iletiyi işlemeye yönelik ilerlemeyi izlemek istiyor.Your application wants to track progress for processing a message inside of the queue. Bu, bir iletinin kilitlenmesinin kilitlenmesi durumunda yararlıdır.This is useful if the worker processing a message crashes. Sonraki bir çalışan daha sonra bu bilgileri kullanarak önceki çalışan kaldığınız yerden devam edebilir.A subsequent worker can then use that information to continue from where the prior worker left off.
  • Kuyruklarınız için yürütülen tüm işlemlerin sunucu tarafında günlüklerine ihtiyacınız vardır.You require server side logs of all of the transactions executed against your queues.

Çözüm mimarı/geliştiricisi olarak, şu durumlarda Service Bus kuyrukları kullanmayı göz önünde bulundurmanız gerekir :As a solution architect/developer, you should consider using Service Bus queues when:

  • Çözümünüzün kuyruğu yoklamaya gerek kalmadan ileti alabilmesi gerekir.Your solution must be able to receive messages without having to poll the queue. Service Bus, bu, Service Bus desteklediği TCP tabanlı protokoller kullanılarak uzun yoklama alma işleminin kullanımı aracılığıyla elde edilebilir.With Service Bus, this can be achieved through the use of the long-polling receive operation using the TCP-based protocols that Service Bus supports.
  • Çözümünüz için kuyruğun, bir ilk ilk çıkar (FıFO) sıralı teslim sağlaması gerekir.Your solution requires the queue to provide a guaranteed first-in-first-out (FIFO) ordered delivery.
  • Çözümünüzün otomatik yinelenen saptamayı destekleyebilmesi gerekir.Your solution must be able to support automatic duplicate detection.
  • Uygulamanızın iletileri paralel uzun süreli akışlar olarak işlemesini istiyorsunuz (ileti, iletideki SessionID özelliği kullanılarak bir akışla ilişkilendirilir).You want your application to process messages as parallel long-running streams (messages are associated with a stream using the SessionId property on the message). Bu modelde, tüketim uygulamasındaki her düğüm, iletiler yerine akışlar için bir kullanıcı tarafından kabul edilebilir.In this model, each node in the consuming application competes for streams, as opposed to messages. Bir akış tüketen bir düğüme verildiğinde, düğüm işlemleri kullanarak uygulama akış durumunun durumunu inceleyebilir.When a stream is given to a consuming node, the node can examine the state of the application stream state using transactions.
  • Çözümünüz, bir kuyruktan birden çok ileti gönderirken veya alırken işlemsel davranış ve kararlılık gerektirir.Your solution requires transactional behavior and atomicity when sending or receiving multiple messages from a queue.
  • Uygulamanız 64 KB 'ı aşan iletileri işler, ancak 256 KB sınırına büyük olasılıkla yaklaşımlar.Your application handles messages that can exceed 64 KB but will not likely approach the 256 KB limit.
  • Sıralara rol tabanlı erişim modeli sağlamak ve Gönderenler ve alıcılar için farklı haklar/izinler sağlamak üzere bir gereksinimle uğraşmanız gerekir.You deal with a requirement to provide a role-based access model to the queues, and different rights/permissions for senders and receivers. Daha fazla bilgi için aşağıdaki makaleleri inceleyin:For more information, see the following articles:
  • Kuyruk boyutunuz 80 GB'ın üzerine çıkmayacaktır.Your queue size will not grow larger than 80 GB.
  • AMQP 1,0 standartları tabanlı mesajlaşma protokolünü kullanmak istiyorsunuz.You want to use the AMQP 1.0 standards-based messaging protocol. AMQP hakkında daha fazla bilgi için bkz. SERVICE Bus AMQP 'ye genel bakış.For more information about AMQP, see Service Bus AMQP Overview.
  • Sıra tabanlı noktadan noktaya iletişimden, her birinin, kuyruğa gönderilen bazı veya tüm iletilerin bağımsız kopyalarını aldığı ek alıcıların (aboneler) sorunsuz tümleştirmesini sağlayan bir ileti değişimi düzenine yönelik bir son geçiş yapabilirsiniz.You can envision an eventual migration from queue-based point-to-point communication to a message exchange pattern that enables seamless integration of additional receivers (subscribers), each of which receives independent copies of either some or all messages sent to the queue. İkincisi, Service Bus tarafından yerel olarak sağlanmış yayımla/abone olma özelliğine başvurur.The latter refers to the publish/subscribe capability natively provided by Service Bus.
  • Mesajlaşma çözümünüz, ek altyapı bileşenleri oluşturmanıza gerek kalmadan "en çok bir kez" teslim garantisi 'nı destekleyebilmelidir.Your messaging solution must be able to support the "At-Most-Once" delivery guarantee without the need for you to build the additional infrastructure components.
  • İletileri toplu halde yayımlayabilmek ve kullanabilmek istersiniz.You would like to be able to publish and consume batches of messages.

Depolama kuyruklarını ve Service Bus sıralarını karşılaştırmaComparing Storage queues and Service Bus queues

Aşağıdaki bölümlerde yer alarak bulunan tablolar, kuyruk özelliklerinin mantıksal bir gruplandırmasını sağlar ve her iki Azure depolama kuyruğunda ve Service Bus kuyruklarındaki özellikleri bir bakışta karşılaştırmanıza imkan tanır.The tables in the following sections provide a logical grouping of queue features and let you compare, at a glance, the capabilities available in both Azure Storage queues and Service Bus queues.

Temel alınan yeteneklerFoundational capabilities

Bu bölümde, depolama kuyrukları ve Service Bus kuyrukları tarafından sunulan bazı temel sıraya alma özellikleri karşılaştırılır.This section compares some of the fundamental queuing capabilities provided by Storage queues and Service Bus queues.

Karşılaştırma ölçütleriComparison Criteria Depolama kuyruklarıStorage queues Service Bus kuyruklarıService Bus queues
Sipariş garantisiOrdering guarantee HayırNo

Daha fazla bilgi için "ek bilgiler" bölümündeki ilk nota bakın.For more information, see the first note in the “Additional Information” section.
Evet-Ilk çıkar (FıFO)Yes - First-In-First-Out (FIFO)

(mesajlaşma oturumlarının kullanımı aracılığıyla)(through the use of messaging sessions)
Teslimat garantisiDelivery guarantee En az bir kezAt-Least-Once En az bir kez (PeekLock alma modunu kullanarak-bu varsayılandır)At-Least-Once (using PeekLock receive mode - this is the default)

En çok bir kez (ReceiveAndDelete alma modunu kullanarak)At-Most-Once (using ReceiveAndDelete receive mode)

Çeşitli alma modları hakkında daha fazla bilgi edininLearn more about various Receive modes
Atomik işlem desteğiAtomic operation support HayırNo EvetYes

Alma davranışıReceive behavior EngellenmeyenNon-blocking

(yeni bir ileti bulunmazsa hemen tamamlanır)(completes immediately if no new message is found)
Zaman aşımı ile/olmadan engellemeBlocking with/without timeout

(uzun yoklama sağlar veya "Comet tekniği")(offers long polling, or the "Comet technique")

EngellenmeyenNon-blocking

(yalnızca .NET yönetilen API kullanımı aracılığıyla)(through the use of .NET managed API only)
Gönderme stili API 'SIPush-style API HayırNo EvetYes

Queueclient. OnMessage ve messagesessionhandler. OnMessage Sessions .NET API 'si.QueueClient.OnMessage and MessageSessionHandler.OnMessage sessions .NET API.
Alma moduReceive mode & kiralamaya göz atınPeek & Lease & kilidine GözatPeek & Lock

& silme alReceive & Delete
Özel erişim moduExclusive access mode Kira tabanlıLease-based Kilit tabanlıLock-based
Kira/kilitleme süresiLease/Lock duration 30 saniye (varsayılan)30 seconds (default)

7 gün (maksimum) ( updatemessage API 'sini kullanarak bir ileti kiralamasını yenileyebilir veya serbest bırakabilirsiniz.)7 days (maximum) (You can renew or release a message lease using the UpdateMessage API.)
60 saniye (varsayılan)60 seconds (default)

Yenilenebilir kilit API 'sini kullanarak bir ileti kilidini yenileyebilirsiniz.You can renew a message lock using the RenewLock API.
Kira/kilit hassasiyetiLease/Lock precision İleti düzeyiMessage level

(her ileti farklı bir zaman aşımı değerine sahip olabilir ve bu, daha sonra iletiyi işlerken, updatemessage API 'sini kullanarak güncelleştirebilirsiniz)(each message can have a different timeout value, which you can then update as needed while processing the message, by using the UpdateMessage API)
Sıra düzeyiQueue level

(her kuyruğun tüm iletilerine uygulanan bir kilit duyarlığı vardır, ancak bu kilidi renewlock API 'sini kullanarak yenileyebilirsiniz.)(each queue has a lock precision applied to all of its messages, but you can renew the lock using the RenewLock API.)
Toplu almaBatched receive EvetYes

(iletileri alırken ileti sayısını açıkça belirtme, en fazla 32 ileti)(explicitly specifying message count when retrieving messages, up to a maximum of 32 messages)
EvetYes

(bir önceden getirme özelliğini örtülü olarak veya işlem kullanımı aracılığıyla açıkça etkinleştirme)(implicitly enabling a pre-fetch property or explicitly through the use of transactions)
Toplu gönderBatched send HayırNo EvetYes

(işlemler veya istemci tarafı toplu işlem kullanımı aracılığıyla)(through the use of transactions or client-side batching)

Ek bilgilerAdditional information

  • Depolama sıralarındaki iletiler genellikle ilk kez ilk çıkar, ancak bazen sıra dışı olabilir; Örneğin, bir iletinin görünürlük zaman aşımı süresi dolduğunda (örneğin, işleme sırasında kilitlenen bir istemci uygulaması sonucu olarak).Messages in Storage queues are typically first-in-first-out, but sometimes they can be out of order; for example, when a message's visibility timeout duration expires (for example, as a result of a client application crashing during processing). Görünürlük zaman aşımı süresi dolduğunda, ileti başka bir çalışanın onu kuyruğa almak için kuyrukta yeniden görünür hale gelir.When the visibility timeout expires, the message becomes visible again on the queue for another worker to dequeue it. Bu noktada, önceden sıraya alınmış bir iletiden sonra, yeni görünür ileti sıraya yerleştirilebilir (yeniden kuyruğa alınır).At that point, the newly visible message might be placed in the queue (to be dequeued again) after a message that was originally enqueued after it.
  • Service Bus kuyruklarındaki garantili FıFO deseninin mesajlaşma oturumlarının kullanılması gerekir.The guaranteed FIFO pattern in Service Bus queues requires the use of messaging sessions. Uygulamanın, Peek & kilit modunda alınan bir iletiyi işlerken çöktüğü durumda, bir kuyruk alıcısının bir ileti oturumunu kabul ettiği bir sonraki sefer, bu işlem, yaşam SÜRESI (TTL) süresi dolduktan sonra başarısız iletiyle başlar.In the event that the application crashes while processing a message received in the Peek & Lock mode, the next time a queue receiver accepts a messaging session, it will start with the failed message after its time-to-live (TTL) period expires.
  • Depolama kuyrukları, hatalara yönelik ölçeklenebilirlik ve toleransı artırmak, yük dengeleme ve işlem iş akışları oluşturmak için uygulama bileşenlerini ayırma gibi standart sıraya alma senaryolarını desteklemek üzere tasarlanmıştır.Storage queues are designed to support standard queuing scenarios, such as decoupling application components to increase scalability and tolerance for failures, load leveling, and building process workflows.
  • Service Bus oturumlarının bağlamında ileti işleme ile ilgili tutarsızlıklar, oturum durumu kullanılarak, oturumun ileti sırasını işleme ilerleme durumu ile ilgili olarak uygulamanın durumunu depolamak için ve alınan iletileri kapatma ve oturum durumunu güncelleştirme işlemleri aracılığıyla kaçınılabilir.Inconsistencies with regard to message handling in the context of Service Bus sessions can be avoided by using session state to store the application's state relative to the progress of handling the session's message sequence, and by using transactions around settling received messages and updating the session state. Bu tür bir tutarlılık özelliği bazen diğer satıcının ürünlerinde tam olarak bir kez Işlem olarak etiketlidir, ancak işlem sorunları, iletilerin yeniden gönderilmesine neden olur ve bu nedenle terim tam olarak yeterli değildir.This kind of consistency feature is sometimes labeled Exactly-Once Processing in other vendor's products, but transaction failures will obviously cause messages to be redelivered and therefore the term is not exactly adequate.
  • Depolama kuyrukları, hem geliştiriciler hem de işlem takımları için kuyruklar, tablolar ve Bloblar genelinde Tekdüzen ve tutarlı bir programlama modeli sağlar.Storage queues provide a uniform and consistent programming model across queues, tables, and BLOBs – both for developers and for operations teams.
  • Service Bus kuyrukları, tek bir sıra bağlamında yerel işlemler için destek sağlar.Service Bus queues provide support for local transactions in the context of a single queue.
  • Service Bus tarafından desteklenen alma ve silme modu, düşürülen teslim güvencesi için Exchange 'teki mesajlaşma işlem sayısını (ve ilişkili maliyeti) azaltma yeteneği sağlar.The Receive and Delete mode supported by Service Bus provides the ability to reduce the messaging operation count (and associated cost) in exchange for lowered delivery assurance.
  • Depolama kuyrukları, iletiler için kiraları genişletme olanağı sunan kiralamalar sağlar.Storage queues provide leases with the ability to extend the leases for messages. Bu, çalışanların iletilerde kısa kiralamalar bulundurmasını sağlar.This allows the workers to maintain short leases on messages. Bu nedenle, bir çalışan kilitlenirse, ileti başka bir çalışan tarafından hızlı bir şekilde yeniden işlenebilir.Thus, if a worker crashes, the message can be quickly processed again by another worker. Ayrıca, bir çalışan bir ileti üzerinde kirayı, geçerli kira süresinden daha uzun süre işlemesi gerekiyorsa genişletebilir.In addition, a worker can extend the lease on a message if it needs to process it longer than the current lease time.
  • Depolama kuyrukları, bir iletinin sıraya alınması veya kuyruğa çıkarılması üzerinde ayarlayabileceğiniz bir görünürlük zaman aşımı sağlar.Storage queues offer a visibility timeout that you can set upon the enqueuing or dequeuing of a message. Ayrıca, çalışma zamanında farklı kira değerleriyle bir ileti güncelleştirebilir ve aynı kuyruktaki iletilerde farklı değerleri güncelleştirebilirsiniz.In addition, you can update a message with different lease values at run-time, and update different values across messages in the same queue. Service Bus kilit zaman aşımları sıra meta verilerinde tanımlanmıştır; Ancak, yenilenebilir kilit yöntemini çağırarak kilidi yenileyebilirsiniz.Service Bus lock timeouts are defined in the queue metadata; however, you can renew the lock by calling the RenewLock method.
  • Service Bus kuyruklarındaki engelleme alma işlemi için maksimum zaman aşımı 24 gündür.The maximum timeout for a blocking receive operation in Service Bus queues is 24 days. Ancak, REST tabanlı zaman aşımları 55 saniyelik en büyük değere sahiptir.However, REST-based timeouts have a maximum value of 55 seconds.
  • Service Bus tarafından sunulan istemci tarafı toplu işleme, bir kuyruk istemcisinin birden çok iletiyi tek bir gönderme işleminde toplu olarak oluşturmasını sağlar.Client-side batching provided by Service Bus enables a queue client to batch multiple messages into a single send operation. Toplu işleme yalnızca zaman uyumsuz gönderme işlemleri için kullanılabilir.Batching is only available for asynchronous send operations.
  • 200 TB 'lık depolama sıralarının üst sınırı (hesapları sanallaştırdığınızda daha fazla) ve sınırsız kuyruk, SaaS sağlayıcıları için ideal bir platform haline getirir.Features such as the 200 TB ceiling of Storage queues (more when you virtualize accounts) and unlimited queues make it an ideal platform for SaaS providers.
  • Depolama kuyrukları, esnek ve performansa sahip bir erişim denetimi mekanizması sağlar.Storage queues provide a flexible and performant delegated access control mechanism.

Gelişmiş yeteneklerAdvanced capabilities

Bu bölümde, depolama kuyrukları ve Service Bus kuyrukları tarafından sunulan gelişmiş yetenekler karşılaştırılır.This section compares advanced capabilities provided by Storage queues and Service Bus queues.

Karşılaştırma ölçütleriComparison Criteria Depolama kuyruklarıStorage queues Service Bus kuyruklarıService Bus queues
Zamanlanmış teslimScheduled delivery EvetYes EvetYes
Otomatik olarak atılacakAutomatic dead lettering HayırNo EvetYes
Sıra yaşam süresi değerini artırmaIncreasing queue time-to-live value EvetYes

(görünürlük zaman aşımı ile yerinde güncelleştirme aracılığıyla)(via in-place update of visibility timeout)
EvetYes

(özel bir API işlevi ile sunulmaktadır)(provided via a dedicated API function)
Zarar iletisi desteğiPoison message support EvetYes EvetYes
Yerinde güncelleştirmeIn-place update EvetYes EvetYes
Sunucu tarafı işlem günlüğüServer-side transaction log EvetYes HayırNo
Depolama ölçümleriStorage metrics EvetYes

Dakikalık ölçümler: kullanılabilirlik, TPS, API çağrı sayısı, hata sayısı ve daha fazlası için gerçek zamanlı ölçümler sağlar. her şeyi gerçek zamanlı olarak (dakikada toplanan ve birkaç dakika içinde raporlanır.Minute Metrics: provides real-time metrics for availability, TPS, API call counts, error counts, and more, all in real time (aggregated per minute and reported within a few minutes from what just happened in production. Daha fazla bilgi için bkz. depolama Analizi ölçümleri hakkında.For more information, see About Storage Analytics Metrics.
EvetYes

( Getqueuesçağırarak toplu sorgular)(bulk queries by calling GetQueues)
Durum yönetimiState management HayırNo EvetYes

Microsoft. ServiceBus. Messaging. EntityStatus. ACTIVE, Microsoft. ServiceBus. Messaging. EntityStatus. DISABLED, Microsoft. ServiceBus. Messaging. EntityStatus. Senddisabled, Microsoft. ServiceBus. Messaging. EntityStatus. receivedisabledMicrosoft.ServiceBus.Messaging.EntityStatus.Active, Microsoft.ServiceBus.Messaging.EntityStatus.Disabled, Microsoft.ServiceBus.Messaging.EntityStatus.SendDisabled, Microsoft.ServiceBus.Messaging.EntityStatus.ReceiveDisabled
İleti otomatik iletmeMessage auto-forwarding HayırNo EvetYes
Temizleme kuyruğu işleviPurge queue function EvetYes HayırNo
İleti gruplarıMessage groups HayırNo EvetYes

(mesajlaşma oturumlarının kullanımı aracılığıyla)(through the use of messaging sessions)
İleti grubu başına uygulama durumuApplication state per message group HayırNo EvetYes
Yineleme algılamaDuplicate detection HayırNo EvetYes

(Gönderen tarafında yapılandırılabilir)(configurable on the sender side)
İleti gruplarına göz atmaBrowsing message groups HayırNo EvetYes
KIMLIĞE göre ileti oturumları getiriliyorFetching message sessions by ID HayırNo EvetYes

Ek bilgilerAdditional information

  • Her iki sıraya alma teknolojisi de bir iletinin daha sonra teslim edilmek üzere zamanlanmasını sağlar.Both queuing technologies enable a message to be scheduled for delivery at a later time.
  • Kuyruk otomatik iletme, binlerce sıranın iletileri, alıcı uygulamanın iletiyi tükettiği tek bir sıraya otomatik olarak iletmesini sağlar.Queue auto-forwarding enables thousands of queues to auto-forward their messages to a single queue, from which the receiving application consumes the message. Bu mekanizmayı, güvenlik ve denetim akışı sağlamak ve her bir ileti yayımcısı arasında depolamayı yalıtmak için kullanabilirsiniz.You can use this mechanism to achieve security, control flow, and isolate storage between each message publisher.
  • Depolama kuyrukları ileti içeriğini güncelleştirmek için destek sağlar.Storage queues provide support for updating message content. Bu işlevi, kalıcı durum bilgileri ve artımlı ilerleme güncellemeleri için, sıfırdan başlamak yerine, bilinen son denetim noktasından işlenebilmesi için kullanabilirsiniz.You can use this functionality for persisting state information and incremental progress updates into the message so that it can be processed from the last known checkpoint, instead of starting from scratch. Service Bus kuyruklarında, ileti oturumlarının kullanımı aracılığıyla aynı senaryoyu etkinleştirebilirsiniz.With Service Bus queues, you can enable the same scenario through the use of message sessions. Oturumlar, uygulama işleme durumunu kaydetmenizi ve almanızı sağlar ( SetState ve GetStatekullanarak).Sessions enable you to save and retrieve the application processing state (by using SetState and GetState).
  • Yalnızca Service Bus kuyrukları tarafından desteklenen yok sayılma, alıcı uygulama tarafından başarıyla işlenemeyen iletileri yalıtmak veya süresi dolan yaşam SÜRESI (TTL) özelliği nedeniyle iletiler hedefe ulaşamadığınızda yararlı olabilir.Dead lettering, which is only supported by Service Bus queues, can be useful for isolating messages that cannot be processed successfully by the receiving application or when messages cannot reach their destination due to an expired time-to-live (TTL) property. TTL değeri, bir iletinin kuyrukta ne kadar süreyle kalacağını belirtir.The TTL value specifies how long a message remains in the queue. Service Bus, bu ileti TTL süresi sona erdiğinde $DeadLetterQueue adlı özel bir kuyruğa taşınır.With Service Bus, the message will be moved to a special queue called $DeadLetterQueue when the TTL period expires.
  • Depolama sıralarında "Poison" iletileri bulmak için, bir iletiyi sıradan kaldırdığınızda, uygulamanın Dequeuecount özelliğini inceler.To find "poison" messages in Storage queues, when dequeuing a message the application examines the DequeueCount property of the message. Dequeuecount verilen eşikten büyükse, uygulama iletiyi uygulama tanımlı "atılacak mektup" kuyruğuna taşımalıdır.If DequeueCount is greater than a given threshold, the application moves the message to an application-defined "dead letter" queue.
  • Depolama kuyrukları, sıraya göre yürütülen tüm işlemlerin yanı sıra toplanan ölçümler elde etmeniz için ayrıntılı bir günlük sağlar.Storage queues enable you to obtain a detailed log of all of the transactions executed against the queue, as well as aggregated metrics. Bu seçeneklerin her ikisi de hata ayıklama ve uygulamanızın depolama kuyruklarını nasıl kullandığını anlamak için yararlıdır.Both of these options are useful for debugging and understanding how your application uses Storage queues. Ayrıca, uygulamanızı performans ayarlaması ve kuyrukları kullanmanın maliyetlerini azaltma için de kullanışlıdır.They are also useful for performance-tuning your application and reducing the costs of using queues.
  • Service Bus tarafından desteklenen "ileti oturumları" kavramı, belirli bir mantıksal gruba ait olan iletilerin belirli bir alıcı ile ilişkilendirilmesini sağlar ve bu da iletiler ve ilgili alıcılar arasında oturum benzeri bir benzeşim oluşturur.The concept of "message sessions" supported by Service Bus enables messages that belong to a certain logical group to be associated with a given receiver, which in turn creates a session-like affinity between messages and their respective receivers. Bir iletideki SessionID özelliğini ayarlayarak Service Bus bu gelişmiş işlevselliği etkinleştirebilirsiniz.You can enable this advanced functionality in Service Bus by setting the SessionID property on a message. Alıcılar daha sonra belirli bir oturum KIMLIĞI üzerinde dinleme yapabilir ve belirtilen oturum tanımlayıcısını paylaşan iletiler alabilir.Receivers can then listen on a specific session ID and receive messages that share the specified session identifier.
  • Service Bus kuyrukları tarafından desteklenen çoğaltma algılama işlevselliği, MessageID özelliğinin değerine bağlı olarak bir kuyruğa veya konuya gönderilen yinelenen iletileri otomatik olarak kaldırır.The duplication detection functionality supported by Service Bus queues automatically removes duplicate messages sent to a queue or topic, based on the value of the MessageId property.

Kapasite ve KotalarCapacity and quotas

Bu bölümde, depolama kuyrukları ve Service Bus kuyrukları, uygulayabilen Kapasite ve Kotalar açısından karşılaştırılır.This section compares Storage queues and Service Bus queues from the perspective of capacity and quotas that may apply.

Karşılaştırma ölçütleriComparison Criteria Depolama kuyruklarıStorage queues Service Bus kuyruklarıService Bus queues
En büyük sıra boyutuMaximum queue size 500 TB500 TB

( tek bir depolama hesabı kapasitesinesınırlı)(limited to a single storage account capacity)
1 GB ila 80 GB1 GB to 80 GB

(bir kuyruk oluşturulduktan ve bölümleme etkinleştirildikten sonra tanımlanır), "ek bilgi" bölümüne bakın(defined upon creation of a queue and enabling partitioning – see the “Additional Information” section)
En büyük ileti boyutuMaximum message size 64 KB64 KB

( Base64 kodlaması KULLANıLıRKEN 48 KB)(48 KB when using Base64 encoding)

Azure, kuyrukları ve Blobları birleştirerek büyük iletileri destekler – bu noktada tek bir öğe için 200 GB 'a kadar sıraya alabilirsiniz.Azure supports large messages by combining queues and blobs – at which point you can enqueue up to 200 GB for a single item.
256 KB veya 1 MB256 KB or 1 MB

(başlık ve gövde dahil, en büyük üst bilgi boyutu: 64 KB).(including both header and body, maximum header size: 64 KB).

Hizmet katmanınabağlıdır.Depends on the service tier.
En fazla ileti TTLMaximum message TTL Sonsuz (apı sürümü 2017-07-27 itibariyle)Infinite (as of api-version 2017-07-27) TimeSpan. MaxTimeSpan.Max
En fazla sıra sayısıMaximum number of queues SınırsızUnlimited 10.00010,000

(hizmet ad alanı başına)(per service namespace)
En fazla eş zamanlı istemci sayısıMaximum number of concurrent clients SınırsızUnlimited SınırsızUnlimited

(100 eşzamanlı bağlantı sınırı yalnızca TCP protokolü tabanlı iletişim için geçerlidir)(100 concurrent connection limit only applies to TCP protocol-based communication)

Ek bilgilerAdditional information

  • Service Bus kuyruk boyutu sınırlarını zorlar.Service Bus enforces queue size limits. Sıra boyutu üst sınırı, sıranın oluşturulması üzerine belirtilir ve 1 ile 80 GB arasında bir değere sahip olabilir.The maximum queue size is specified upon creation of the queue and can have a value between 1 and 80 GB. Sıra oluşturma sırasında ayarlanan sıra boyutu değerine ulaşıldığında, ek gelen iletiler reddedilir ve çağıran kod tarafından bir özel durum alınır.If the queue size value set on creation of the queue is reached, additional incoming messages will be rejected and an exception will be received by the calling code. Service Bus kotaları hakkında daha fazla bilgi için bkz. Service Bus kotalar.For more information about quotas in Service Bus, see Service Bus Quotas.
  • Premium katmandabölümlendirme desteklenmez.Partitioning is not supported in the Premium tier. Standart katmanda, 1, 2, 3, 4 veya 5 GB boyutunda Service Bus kuyrukları oluşturabilirsiniz (varsayılan değer 1 GB 'tır).In the Standard tier, you can create Service Bus queues in 1, 2, 3, 4, or 5 GB sizes (the default is 1 GB). Standart katmanda bölümlendirme etkin (varsayılan), Service Bus belirttiğiniz her GB için 16 bölüm oluşturur.In Standard tier, with partitioning enabled (which is the default), Service Bus creates 16 partitions for each GB you specify. Bu nedenle, boyutu 5 GB olan bir kuyruk oluşturursanız, 16 bölümlü en büyük sıra boyutu (5 * 16) = 80 GB olur.As such, if you create a queue that is 5 GB in size, with 16 partitions the maximum queue size becomes (5 * 16) = 80 GB. Bölümlenmiş kuyruğunuzun veya konusunun en büyük boyutunu Azure Portalgirişine bakarak görebilirsiniz.You can see the maximum size of your partitioned queue or topic by looking at its entry on the Azure portal.
  • Depolama kuyrukları ile, iletinin içeriği XML güvenli değilse, Base64 kodlamalı olmalıdır.With Storage queues, if the content of the message is not XML-safe, then it must be Base64 encoded. İletiyi Base64olarak kodlarsanız, kullanıcı yükü 64 kb yerıne 48 KB 'ye kadar olabilir.If you Base64-encode the message, the user payload can be up to 48 KB, instead of 64 KB.
  • Service Bus kuyruklarında, bir sırada depolanan her ileti iki bölümden oluşur: başlık ve gövde.With Service Bus queues, each message stored in a queue is composed of two parts: a header and a body. İletinin toplam boyutu hizmet katmanının desteklediği en büyük ileti boyutunu aşamaz.The total size of the message cannot exceed the maximum message size supported by the service tier.
  • İstemciler TCP protokolü üzerinden Service Bus kuyruklarında iletişim kurduğunda, tek bir Service Bus kuyruğuna en fazla eşzamanlı bağlantı sayısı 100 ile sınırlıdır.When clients communicate with Service Bus queues over the TCP protocol, the maximum number of concurrent connections to a single Service Bus queue is limited to 100. Bu sayı, Gönderenler ve alıcılar arasında paylaşılır.This number is shared between senders and receivers. Bu kotaya ulaşıldığında, daha sonra ek bağlantı istekleri reddedilir ve çağıran kod tarafından bir özel durum alınır.If this quota is reached, subsequent requests for additional connections will be rejected and an exception will be received by the calling code. Bu sınır, REST tabanlı API kullanılarak kuyruklara bağlanan istemcilere uygulanmaz.This limit is not imposed on clients connecting to the queues using REST-based API.
  • Tek bir Service Bus ad alanında 10.000 ' den fazla kuyruk gerekiyorsa, Azure destek ekibine başvurarak bir artış isteyebilirsiniz.If you require more than 10,000 queues in a single Service Bus namespace, you can contact the Azure support team and request an increase. 10.000 kuyruklarının ötesinde Service Bus ölçeklendirmek için Azure Portalkullanarak ek ad alanları da oluşturabilirsiniz.To scale beyond 10,000 queues with Service Bus, you can also create additional namespaces using the Azure portal.

Yönetim ve işlemlerManagement and operations

Bu bölümde, depolama kuyrukları ve Service Bus kuyrukları tarafından sunulan yönetim özellikleri karşılaştırılır.This section compares the management features provided by Storage queues and Service Bus queues.

Karşılaştırma ölçütleriComparison Criteria Depolama kuyruklarıStorage queues Service Bus kuyruklarıService Bus queues
Yönetim ProtokolüManagement protocol HTTP/HTTPS üzerinden RESTREST over HTTP/HTTPS HTTPS üzerinden GERI dönREST over HTTPS
Çalışma zamanı ProtokolüRuntime protocol HTTP/HTTPS üzerinden RESTREST over HTTP/HTTPS HTTPS üzerinden GERI dönREST over HTTPS

AMQP 1,0 standart (TLS ile TCP)AMQP 1.0 Standard (TCP with TLS)
.NET API’si.NET API EvetYes

(.NET Storage Istemci API 'SI)(.NET Storage Client API)
EvetYes

(.NET Service Bus API)(.NET Service Bus API)
Yerel C++Native C++ EvetYes EvetYes
Java API’siJava API EvetYes EvetYes
PHP APı 'SIPHP API EvetYes EvetYes
Node.js API’siNode.js API EvetYes EvetYes
Rastgele meta veri desteğiArbitrary metadata support EvetYes HayırNo
Kuyruk adlandırma kurallarıQueue naming rules En fazla 63 karakter uzunluğundaUp to 63 characters long

(Bir kuyruk adındaki harfler küçük harfle yazılmalıdır.)(Letters in a queue name must be lowercase.)
En fazla 260 karakter uzunluğundaUp to 260 characters long

(Kuyruk yolları ve adları büyük/küçük harfe duyarlıdır.)(Queue paths and names are case-insensitive.)
Sıra uzunluğu alma işleviGet queue length function EvetYes

(İletilerin silinmeksizin TTL 'nin ötesinde yaklaşık değer.)(Approximate value if messages expire beyond the TTL without being deleted.)
EvetYes

(Tam, zaman içinde nokta değeri.)(Exact, point-in-time value.)
Peek işleviPeek function EvetYes EvetYes

Ek bilgilerAdditional information

  • Depolama kuyrukları, ad/değer çiftleri biçiminde kuyruk açıklamasına uygulanabilen rastgele öznitelikler için destek sağlar.Storage queues provide support for arbitrary attributes that can be applied to the queue description, in the form of name/value pairs.
  • Her iki kuyruk teknolojisi de bir iletiyi kilitlemeye gerek kalmadan, bir kuyruk Gezgini/tarayıcı aracı uygularken yararlı olabilecek bir iletiye göz atma özelliği sunar.Both queue technologies offer the ability to peek a message without having to lock it, which can be useful when implementing a queue explorer/browser tool.
  • Service Bus .NET Aracılı mesajlaşma API 'Leri, HTTP üzerinden REST ile karşılaştırıldığında gelişmiş performans için tam çift yönlü TCP bağlantılarını kullanır ve AMQP 1,0 standart protokolünü destekler.The Service Bus .NET brokered messaging APIs leverage full-duplex TCP connections for improved performance when compared to REST over HTTP, and they support the AMQP 1.0 standard protocol.
  • Depolama sıralarının adları 3-63 karakter uzunluğunda olabilir, küçük harf, sayı ve kısa çizgi içerebilir.Names of Storage queues can be 3-63 characters long, can contain lowercase letters, numbers, and hyphens. Daha fazla bilgi için bkz. ad kuyrukları ve meta verileri.For more information, see Naming Queues and Metadata.
  • Service Bus kuyruk adları en fazla 260 karakter uzunluğunda olabilir ve daha az kısıtlayıcı adlandırma kuralına sahip olabilir.Service Bus queue names can be up to 260 characters long and have less restrictive naming rules. Service Bus kuyruk adları harf, sayı, nokta, kısa çizgi ve alt çizgi içerebilir.Service Bus queue names can contain letters, numbers, periods, hyphens, and underscores.

Kimlik doğrulaması ve yetkilendirmeAuthentication and authorization

Bu bölümde, depolama kuyrukları ve Service Bus kuyrukları tarafından desteklenen kimlik doğrulama ve yetkilendirme özellikleri açıklanmaktadır.This section discusses the authentication and authorization features supported by Storage queues and Service Bus queues.

Karşılaştırma ölçütleriComparison Criteria Depolama kuyruklarıStorage queues Service Bus kuyruklarıService Bus queues
Kimlik DoğrulamasıAuthentication Simetrik anahtarSymmetric key Simetrik anahtarSymmetric key
Güvenlik modeliSecurity model SAS belirteçleri aracılığıyla erişim temsilcisi.Delegated access via SAS tokens. 'LARıNıNSAS
Kimlik sağlayıcısı FederasyonuIdentity provider federation HayırNo EvetYes

Ek bilgilerAdditional information

  • Sıraya alma teknolojilerinin her birine yönelik her bir isteğin kimliğinin doğrulanması gerekir.Every request to either of the queuing technologies must be authenticated. Anonim erişimi olan genel kuyruklar desteklenmez.Public queues with anonymous access are not supported. SASkullanarak, bu senaryoya yalnızca bir salt yazılır SAS, salt okunurdur ve hatta tam erişimli SAS yayımlayarak erişebilirsiniz.Using SAS, you can address this scenario by publishing a write-only SAS, read-only SAS, or even a full-access SAS.
  • Depolama kuyrukları tarafından sunulan kimlik doğrulama düzeni, SHA-256 algoritması ile hesaplanan ve Base64 dizesi olarak kodlanan, karma tabanlı İLETI KIMLIK doğrulama kodu (HMAC) olan simetrik anahtar kullanımını içerir.The authentication scheme provided by Storage queues involves the use of a symmetric key, which is a hash-based Message Authentication Code (HMAC), computed with the SHA-256 algorithm and encoded as a Base64 string. İlgili protokol hakkında daha fazla bilgi için bkz. Azure depolama hizmetleri Için kimlik doğrulama.For more information about the respective protocol, see Authentication for the Azure Storage Services. Service Bus kuyrukları, simetrik anahtarlar kullanan benzer bir modeli destekler.Service Bus queues support a similar model using symmetric keys. Daha fazla bilgi için bkz. Service Bus Ile paylaşılan erişim Imzası kimlik doğrulaması.For more information, see Shared Access Signature Authentication with Service Bus.

SonuçConclusion

İki teknolojiyi daha ayrıntılı bir şekilde öğrenerek hangi kuyruk teknolojisinin kullanılacağı ve ne zaman daha bilinçli bir karar elde edersiniz.By gaining a deeper understanding of the two technologies, you will be able to make a more informed decision on which queue technology to use, and when. Depolama sıralarının veya Service Bus sıralarının ne zaman kullanılacağı kararı, bir dizi etkene bağlıdır.The decision on when to use Storage queues or Service Bus queues clearly depends on a number of factors. Bu faktörler, uygulamanızın ve mimarinin mimarisine göre büyük ölçüde değişebilir.These factors may depend heavily on the individual needs of your application and its architecture. Uygulamanız Microsoft Azure temel yeteneklerini zaten kullanıyorsa, özellikle hizmetler arasında temel iletişim ve mesajlaşma istiyorsanız veya boyut 80 GB 'tan daha büyük olabilecek kuyruklara ihtiyaç duyuyorsanız, depolama kuyrukları ' nı seçebilirsiniz.If your application already uses the core capabilities of Microsoft Azure, you may prefer to choose Storage queues, especially if you require basic communication and messaging between services or need queues that can be larger than 80 GB in size.

Service Bus kuyrukları, oturumlar, işlemler, yinelenen algılama, otomatik olarak atılacak ve dayanıklı yayımlama/abone olma gibi çeşitli gelişmiş özellikler sağladığından, karma uygulama oluşturuyorsanız veya uygulamanız bu özellikleri gerektiriyorsa tercih edilen bir seçenek olabilir.Because Service Bus queues provide a number of advanced features, such as sessions, transactions, duplicate detection, automatic dead-lettering, and durable publish/subscribe capabilities, they may be a preferred choice if you are building a hybrid application or if your application otherwise requires these features.

Sonraki adımlarNext steps

Aşağıdaki makalelerde, depolama kuyruklarını veya Service Bus kuyruklarını kullanma hakkında daha fazla rehberlik ve bilgi sağlanmaktadır.The following articles provide more guidance and information about using Storage queues or Service Bus queues.