Depolama kuyrukları ve Service Bus kuyrukları - karşılaştırmalı ve karşıt

Bu makalede, Microsoft Azure tarafından sunulan iki kuyruk türü arasındaki farklar ve benzerlikler analiz edilir: Depolama kuyrukları ve Service Bus kuyrukları. Bu bilgileri kullanarak, hangi çözümün ihtiyaçlarınızı en iyi şekilde karşıladığı konusunda daha bilinçli bir karar vekleyebilirsiniz.

Giriş

Azure desteği iki tür kuyruk mekanizması vardır: Depolama kuyrukları ve Service Bus kuyrukları.

Depolama kuyrukları Azure Depolama altyapısının bir parçasıdır. Çok sayıda iletiyi depolamanıza olanak sağlar. HTTP veya HTTPS kullanarak kimliği doğrulanmış çağrılar aracılığıyla dünyanın herhangi bir yerinden iletilere erişebilirsiniz. Kuyruk iletisinin boyutu en fazla 64 KB olabilir. Kuyruk, depolama hesabının toplam kapasite sınırına kadar milyonlarca ileti içerebilir. Kuyruklar genellikle zaman uyumsuz olarak işlenmek üzere bir iş kapsamı oluşturmak için kullanılır. Daha fazla bilgi için bkz. Azure Depolama kuyrukları nedir?

Service Bus kuyrukları , kuyruğa alma, yayımlama/abone olma ve daha gelişmiş tümleştirme desenlerini destekleyen daha geniş bir Azure mesajlaşma altyapısının parçasıdır. Birden çok iletişim protokolüne, veri sözleşmelerine, güven etki alanlarına veya ağ ortamlarına yayabilecek uygulamaları veya uygulama bileşenlerini tümleştirmek için tasarlanmıştır. Service Bus kuyrukları/konuları/abonelikleri hakkında daha fazla bilgi için bkz . Service Bus kuyrukları, konuları ve abonelikleri.

Teknoloji seçimiyle ilgili dikkat edilmesi gerekenler

Depolama kuyrukları ve Service Bus kuyrukları biraz farklı bir özellik kümesine sahiptir. Kendi çözümünüzün gereksinimlerine bağlı olarak birini veya her ikisini de seçebilirsiniz.

Belirli bir çözümün amacına hangi kuyruğa alma teknolojisinin uygun olduğunu belirlerken, çözüm mimarları ve geliştiriciler bu önerileri dikkate almalıdır.

Depolama kuyrukları kullanmayı göz önünde bulundurun

Çözüm mimarı/geliştirici olarak aşağıdaki durumlarda Depolama kuyrukları kullanmayı düşünmelisiniz:

  • Uygulamanızın kuyrukta 80 gigabayttan fazla ileti depolaması gerekir.
  • Uygulamanız kuyruktaki bir iletiyi işlemek için ilerleme durumunu izlemek istiyor. bir iletiyi işleyen çalışan kilitleniyorsa yararlıdır. Daha sonra başka bir çalışan, önceki çalışanın bıraktığı yerden devam etmek için bu bilgileri kullanabilir.
  • Kuyruklarınızda yürütülen tüm işlemlerin sunucu tarafı günlüklerine ihtiyacınız vardır.

Service Bus kuyruklarını kullanmayı göz önünde bulundurun

Çözüm mimarı/geliştirici olarak aşağıdaki durumlarda Service Bus kuyruklarını kullanmayı düşünmelisiniz:

  • Çözümünüzün kuyruğu yoklamadan ileti alması gerekir. Service Bus ile, Service Bus'ın desteklediği TCP tabanlı protokolleri kullanarak uzun yoklama alma işlemi kullanarak bunu başarabilirsiniz.
  • Çözümünüz için kuyruğun garantili ilk çıkar (FIFO) sıralı teslim sağlaması gerekir.
  • Çözümünüz otomatik yinelenen algılamayı desteklemeli.
  • Uygulamanızın uzun süre çalışan paralel akışlar olarak iletileri işlemesini istiyorsunuz (iletiler iletideki oturum kimliği özelliği kullanılarak bir akışla ilişkilendirilir). Bu modelde, tüketen uygulamadaki her düğüm, iletiler yerine akışlar için rekabet eder. Tüketen bir düğüme akış verildiğinde, düğüm işlemleri kullanarak uygulama akışı durumunu inceleyebilir.
  • Çözümünüz bir kuyruktan birden çok ileti gönderirken veya alırken işlemsel davranış ve bölünmezlik gerektirir.
  • Uygulamanız, 64 KB'ı geçebilecek iletileri işler ancak seçilen hizmet katmanına bağlı olarak 256 KB veya 1 MB sınırına yaklaşamaz (Service Bus kuyrukları 100 MB'a kadar olan iletileri işleyebilir).
  • Kuyruklara rol tabanlı erişim modeli ve gönderenler ve alıcılar için farklı haklar/izinler sağlama gereksinimiyle ilgilenirsiniz. Daha fazla bilgi için aşağıdaki makalelere bakın:
  • Kuyruk boyutunuz 80 GB'tan büyük olmayacaktır.
  • AMQP 1.0 standartlarına dayalı mesajlaşma protokollerini kullanmak istiyorsunuz. AMQP hakkında daha fazla bilgi için bkz . Service Bus AMQP'ye Genel Bakış.
  • Kuyruk tabanlı noktadan noktaya iletişimden yayımla-abone ol mesajlaşma düzenine nihai geçiş olmasını öngörürsunuz. Bu düzen ek alıcıların (aboneler) tümleştirilmesini sağlar. Her alıcı, kuyruğa gönderilen iletilerin bazılarının veya tümünün bağımsız kopyalarını alır.
  • Mesajlaşma çözümünüzün ek altyapı bileşenlerini oluşturmanıza gerek kalmadan "En Çok Bir Kez" ve "En Az Bir Kez" teslim garantilerini desteklemesi gerekir.
  • Çözümünüzün toplu iletileri yayımlaması ve kullanması gerekir.

Depolama kuyruklarını ve Service Bus kuyruklarını karşılaştırma

Aşağıdaki bölümlerde yer alan tablolar kuyruk özelliklerinin mantıksal gruplandırmalarını sağlar. Hem Azure Depolama kuyruklarında hem de Service Bus kuyruklarında kullanılabilen özellikleri bir bakışta karşılaştırmanıza olanak sağlar.

Temel özellikler

Bu bölüm, Depolama kuyrukları ve Service Bus kuyrukları tarafından sağlanan temel kuyruğa alma özelliklerinden bazılarını karşılaştırır.

Karşılaştırma Ölçütleri Depolama kuyrukları Service Bus kuyrukları
Sipariş garantisi No

Daha fazla bilgi için Ek Bilgiler bölümündeki ilk nota bakın.
Evet - İlk Çıkan İlk Çıkar (FIFO)

(ileti oturumlarını kullanarak)
Teslimat garantisi En Az Bir Kez En Az Bir Kez (PeekLock alma modunu kullanarak). Varsayılandır)

En Çok Bir Kez (ReceiveAndDelete alma modunu kullanarak)

Çeşitli Alma modları hakkında daha fazla bilgi edinin
Atomik işlem desteği Hayır Evet

Alma davranışı Engelleyici değil

(yeni ileti bulunmazsa hemen tamamlanır)
Zaman aşımıyla veya zaman aşımı olmadan engelleme

(uzun yoklama veya "Kuyrukluyot tekniği" sunar)

Engelleyici değil

(yalnızca .NET yönetilen API kullanarak)
Gönderme stili API Hayır Evet

.NET, Java, JavaScript ve Go SDK'larımız gönderme stili API sağlar.
Alma modu Göz Atma ve Kiralama Göz Atma ve Kilitleme

Alma ve Silme
Özel erişim modu Kira tabanlı Kilit tabanlı
Kiralama/Kilitleme süresi 30 saniye (varsayılan)

7 gün (en fazla) (UpdateMessage API'sini kullanarak bir ileti kirasını yenileyebilir veya serbest bırakabilirsiniz.)
30 saniye (varsayılan)

İleti kilidini her seferinde el ile aynı kilit süresiyle yenileyebilir veya istemcinin sizin için kilit yenilemeyi yönettiği otomatik kilit yenileme özelliğini kullanabilirsiniz.
Kira/Kilit duyarlığı İleti düzeyi

Her iletinin farklı bir zaman aşımı değeri olabilir. Daha sonra UpdateMessage API'sini kullanarak iletiyi işlerken gerektiğinde güncelleştirebilirsiniz.
Kuyruk düzeyi

(Her kuyruğun tüm iletilerine bir kilit duyarlığı uygulanır, ancak kilit önceki satırda açıklandığı gibi yenilenebilir)
Toplu alma Evet

(en fazla 32 ileti olmak üzere iletileri alırken ileti sayısını açıkça belirtme)
Evet

(bir ön getirme özelliğini örtük olarak etkinleştirme veya işlemleri kullanarak açıkça etkinleştirme)
Toplu gönderme Hayır Evet

(işlemleri veya istemci tarafı toplu işlemini kullanarak)

Ek bilgi

  • Depolama kuyruklarındaki iletiler genellikle ilk önce çıkarılır, ancak bazen sıra dışı olabilir. Örneğin, bir ileti işlenirken istemci uygulaması kilitlendiğinden iletinin görünürlük zaman aşımı süresi dolduğunda. Görünürlük zaman aşımı süresi dolduğunda, başka bir çalışanın kuyruğa alma işlemi için ileti kuyrukta yeniden görünür hale gelir. Bu noktada, yeni görünen ileti yeniden sıralanacak kuyruğa yerleştirilebilir.
  • Service Bus kuyruklarındaki garantili FIFO deseni, mesajlaşma oturumlarının kullanılmasını gerektirir. Uygulama, Göz Atma ve Kilitleme modunda alınan bir iletiyi işlerken kilitleniyorsa, bir sonraki sefer kuyruk alıcısı bir mesajlaşma oturumunu kabul ederse, oturumun kilit süresi dolduktan sonra başarısız iletiyle başlar.
  • Depolama kuyrukları, aşağıdakiler gibi standart kuyruğa alma senaryolarını destekleyecek şekilde tasarlanmıştır:
    • Hataların ölçeklenebilirliğini ve toleransını artırmak için uygulama bileşenlerini ayırma
    • Yük dengeleme
    • İşlem iş akışları oluşturma.
  • Service Bus oturumları bağlamında ileti işlemeyle ilgili tutarsızlıklar, oturumun ileti sırasını işlemenin ilerleme durumuna göre uygulamanın durumunu depolamak için oturum durumu kullanılarak ve alınan iletilerin ayarlanması ve oturum durumunun güncelleştirilmesiyle ilgili işlemler kullanılarak önlenebilir. Bu tür bir tutarlılık özelliği bazen diğer satıcının ürünlerinde tam olarak bir kez işlendiğinde etiketlenmiştir. Herhangi bir işlem hatası iletilerin yeniden teslim edilmesine neden olur ve bu nedenle terim tam olarak yeterli değildir.
  • Depolama kuyrukları hem geliştiriciler hem de operasyon ekipleri için kuyruklar, tablolar ve BLOB'lar arasında tekdüzen ve tutarlı bir programlama modeli sağlar.
  • Service Bus kuyrukları, tek bir kuyruk bağlamında yerel işlemler için destek sağlar.
  • Service Bus tarafından desteklenen Alma ve Silme modu, daha düşük teslim güvencesi karşılığında mesajlaşma işlemi sayısını (ve ilişkili maliyeti) azaltma olanağı sağlar.
  • Depolama kuyrukları, kiraları ileti kiralarını genişletme olanağı sağlar. Bu özellik, çalışan işlemlerinin iletilerde kısa kiralamalar yapmasını sağlar. Bu nedenle, bir çalışan kilitlenirse ileti başka bir çalışan tarafından hızla yeniden işlenebilir. Ayrıca bir çalışan, geçerli kiralama süresinden daha uzun süre işlemesi gerekiyorsa iletideki kira süresini uzatabilir.
  • Depolama kuyrukları, bir iletinin sıralanması veya sıralanması sırasında ayarlayabileceğiniz bir görünürlük zaman aşımı sunar. Ayrıca, çalışma zamanında farklı kira değerlerine sahip bir iletiyi güncelleştirebilir ve aynı kuyruktaki iletiler arasında farklı değerleri güncelleştirebilirsiniz. Service Bus kilit zaman aşımları kuyruk meta verilerinde tanımlanır. Ancak, önceden tanımlanmış kilit süresi için ileti kilidini el ile yenileyebilir veya istemcinin sizin için kilit yenilemeyi yönettiği otomatik kilit yenileme özelliğini kullanabilirsiniz.
  • Service Bus kuyruklarında engelleme alma işlemi için en fazla zaman aşımı 24 gündür. Ancak REST tabanlı zaman aşımları en fazla 55 saniyelik bir değere sahiptir.
  • Service Bus tarafından sağlanan istemci tarafı toplu işlemi, bir kuyruk istemcisinin birden çok iletiyi tek bir gönderme işlemi halinde toplu işlemesine olanak tanır. Toplu işlem yalnızca zaman uyumsuz gönderme işlemleri için kullanılabilir.
  • Depolama kuyruklarının 200 TB'lık tavanı (hesapları sanallaştırdığınızda daha fazla) ve sınırsız kuyruk gibi özellikler, saas sağlayıcıları için ideal bir platform olmasını sağlar.
  • Depolama kuyrukları esnek ve performanslı bir temsilcili erişim denetimi mekanizması sağlar.

Gelişmiş özellikler

Bu bölüm, Depolama kuyrukları ve Service Bus kuyrukları tarafından sağlanan gelişmiş özellikleri karşılaştırır.

Karşılaştırma Ölçütleri Depolama kuyrukları Service Bus kuyrukları
Zamanlanmış teslim Evet Evet
Otomatik ölü harfleme Hayır Evet
Kuyruk yaşam süresi değerini artırma Evet

(görünürlük zaman aşımının yerinde güncelleştirilerek)
Evet

(ayrılmış BIR API işlevi aracılığıyla sağlanır)
Zehirli ileti desteği Evet Evet
Yerinde güncelleştirme Evet Evet
Sunucu tarafı işlem günlüğü Evet Hayır
Depolama ölçümleri Evet

Dakika Ölçümleri kullanılabilirlik, TPS, API çağrı sayıları, hata sayıları ve daha fazlası için gerçek zamanlı ölçümler sağlar. Hepsi gerçek zamanlıdır, dakika başına toplanır ve üretimde olanlardan birkaç dakika içinde bildirilir. Daha fazla bilgi için bkz. Depolama Analytics Ölçümleri Hakkında.
Evet

Azure Service Bus tarafından desteklenen ölçümler hakkında bilgi için bkz . İleti ölçümleri.
Durum yönetimi No Evet (Etkin, Devre Dışı, SendDisabled, ReceiveDisabled. Bu durumlarla ilgili ayrıntılar için bkz. Kuyruk durumu)
İletiyi otomatik olarak zorlama Hayır Evet
Kuyruk temizleme işlevi Evet Hayır
İleti grupları Hayır Evet

(mesajlaşma oturumlarını kullanarak)
İleti grubu başına uygulama durumu Hayır Evet
Yinelenen öğe algılaması Hayır Evet

(gönderen tarafında yapılandırılabilir)
İleti gruplarına göz atma Hayır Evet
İleti oturumlarını kimliğine göre getirme Hayır Evet

Ek bilgi

  • Her iki kuyruğa alma teknolojisi de iletinin daha sonra teslim için zamanlanması sağlar.
  • Kuyruk otomatik zorlama, binlerce kuyruğun iletilerini otomatik olarak tek bir kuyruğa göndermesini sağlar ve bu kuyrukta alıcı uygulama iletiyi tüketir. Her ileti yayımcısı arasında güvenlik, denetim akışı ve yalıtma elde etmek için bu mekanizmayı kullanabilirsiniz.
  • Depolama kuyrukları, ileti içeriğini güncelleştirme desteği sağlar. Bu işlevi, durum bilgilerini ve artımlı ilerleme güncelleştirmelerini iletide kalıcı hale getirerek sıfırdan başlamak yerine bilinen son denetim noktasından işlenebilmesini sağlayabilirsiniz. Service Bus kuyruklarıyla, ileti oturumlarını kullanarak aynı senaryoyu etkinleştirebilirsiniz. Daha fazla bilgi için bkz . İleti oturumu durumu.
  • Service Bus kuyrukları, teslim edilemeyen bildirimleri destekler. Aşağıdaki ölçütlere uyan iletileri yalıtmada yararlı olabilir:
    • İletiler alıcı uygulama tarafından başarıyla işlenemiyor
    • Süresi dolan yaşam süresi (TTL) özelliği nedeniyle iletiler hedeflerine ulaşamıyor. TTL değeri, bir iletinin kuyrukta ne kadar süre kaldığını belirtir. Service Bus ile, TTL dönemi sona erdiğinde ileti $DeadLetterQueue adlı özel bir kuyruğa taşınır.
  • Depolama kuyruklarında "zehirli" iletileri bulmak için, bir iletiyi sıralarken uygulama iletinin DequeueCount özelliğini inceler. DequeueCount belirli bir eşikten büyükse, uygulama iletiyi uygulama tanımlı bir "teslim edilemedi" kuyruğuna taşır.
  • Depolama kuyrukları, kuyrukta yürütülen tüm işlemlerin ve toplanan ölçümlerin ayrıntılı bir günlüğünü almanıza olanak tanır. Bu seçeneklerin her ikisi de hata ayıklama ve uygulamanızın Depolama kuyruklarını nasıl kullandığını anlamak için kullanışlıdır. Ayrıca uygulamanızın performansını ayarlamak ve kuyrukları kullanma maliyetlerini azaltmak için de kullanışlıdır.
  • Service Bus tarafından desteklenen ileti oturumları , bir mantıksal gruba ait iletilerin bir alıcıyla ilişkilendirilmesine olanak tanır. İletiler ve ilgili alıcıları arasında oturum benzeri bir benzite oluşturur. Bir iletide oturum kimliği özelliğini ayarlayarak Bu gelişmiş işlevselliği Service Bus'ta etkinleştirebilirsiniz. Alıcılar daha sonra belirli bir oturum kimliğini dinleyebilir ve belirtilen oturum tanımlayıcısını paylaşan iletileri alabilir.
  • Service Bus kuyruklarının yineleme algılama özelliği, ileti kimliği özelliğinin değerine bağlı olarak bir kuyruğa veya konuya gönderilen yinelenen iletileri otomatik olarak kaldırır.

Kapasite ve kotalar

Bu bölüm, Depolama kuyruklarını ve Service Bus kuyruklarını, geçerli olabilecek kapasite ve kotalar açısından karşılaştırır.

Karşılaştırma Ölçütleri Depolama kuyrukları Service Bus kuyrukları
En büyük kuyruk boyutu 500 TB

(tek bir depolama hesabı kapasitesiyle sınırlıdır)
1 GB ile 80 GB

(bir kuyruğun oluşturulması ve bölümlemenin etkinleştirilmesi üzerine tanımlanır – "Ek Bilgiler" bölümüne bakın)
İleti boyutu üst sınırı 64 KB

(Temel 64 kodlama kullanılırken 48 KB)

Azure desteği kuyrukları ve blobları birleştirerek büyük iletileri Azure desteği; bu noktada tek bir öğe için en fazla 200 GB sıraya alabilirsiniz.
256 KB veya 100 MB

(hem üst bilgi hem de gövde dahil, üst bilgi boyutu üst bilgi boyutu: 64 KB).

Hizmet katmanına bağlıdır.
En fazla ileti TTL'si Sonsuz (api-version 2017-07-27 veya üzeri) TimeSpan.MaxValue
En fazla kuyruk sayısı Sınırsız Kategori 10,000

(hizmet ad alanı başına)
En fazla eşzamanlı istemci sayısı Sınırsız 5.000

Ek bilgi

  • Service Bus, kuyruk boyutu sınırlarını zorlar. Kuyruk oluşturulurken en büyük kuyruk boyutu belirtilir. 1 GB ile 80 GB arasında olabilir. Kuyruğun boyutu bu sınıra ulaşırsa, ek gelen iletiler reddedilir ve arayan bir özel durum alır. Service Bus'taki kotalar hakkında daha fazla bilgi için bkz . Service Bus Kotaları.
  • Standart mesajlaşma katmanında 1 (varsayılan), 2, 3, 4 veya 5 GB boyutunda Service Bus kuyrukları ve konuları oluşturabilirsiniz. Standart katmanda bölümleme etkinleştirilirken Service Bus, varlığın her biri aynı boyutta belirtilen 16 kopyasını (16 bölüm) oluşturur. Bu nedenle, boyutu 5 GB olan bir kuyruk oluşturursanız, 16 bölümle en fazla kuyruk boyutu (5 * 16) = 80 GB olur. Bölümlenmiş kuyruğunuzun veya konu başlığınızın en büyük boyutunu Azure portalında görebilirsiniz.
  • Depolama kuyruklarında, iletinin içeriği XML açısından güvenli değilse Base64 kodlanmış olmalıdır. İletiyi Base64 ile kodlarsanız, kullanıcı yükü 64 KB yerine en fazla 48 KB olabilir.
  • Service Bus kuyruklarında, kuyrukta depolanan her ileti iki bölümden oluşur: üst bilgi ve gövde. İletinin toplam boyutu, hizmet katmanı tarafından desteklenen ileti boyutu üst sınırını aşamaz.
  • İstemciler TCP protokolü üzerinden Service Bus kuyruklarıyla iletişim kurarken, tek bir Service Bus kuyruğuna eş zamanlı bağlantı sayısı üst sınırı 100 ile sınırlıdır. Bu numara gönderenler ve alıcılar arasında paylaşılır. Bu kotaya ulaşılırsa, ek bağlantı istekleri reddedilir ve çağrı kodu tarafından bir özel durum alınır. Bu sınır, REST tabanlı API kullanarak kuyruklara bağlanan istemcilere uygulanmaz.
  • Tek bir Service Bus ad alanında 10.000'den fazla kuyruk gerekiyorsa, Azure desteği ekibine başvurabilir ve bir artış isteyebilirsiniz. Service Bus ile 10.000 kuyruğun ötesine ölçeklendirmek için Azure portalını kullanarak ek ad alanları da oluşturabilirsiniz.

Yönetim ve işlemler

Bu bölüm, Depolama kuyrukları ve Service Bus kuyrukları tarafından sağlanan yönetim özelliklerini karşılaştırır.

Karşılaştırma Ölçütleri Depolama kuyrukları Service Bus kuyrukları
Yönetim protokolü HTTP/HTTPS üzerinden REST HTTPS üzerinden REST
Çalışma zamanı protokolü HTTP/HTTPS üzerinden REST HTTPS üzerinden REST

AMQP 1.0 Standard (TLS ile TCP)
.NET API’si Evet

(.NET Depolama İstemci API'si)
Evet

(.NET Service Bus API'si)
Yerel C++ Evet Evet
Java API’si Evet Evet
PHP API'si Evet Evet
Node.js API’si Evet Evet
Rastgele meta veri desteği Evet Hayır
Kuyruk adlandırma kuralları En fazla 63 karakter uzunluğunda

(Kuyruk adındaki harfler küçük harf olmalıdır.)
En fazla 260 karakter uzunluğunda

(Kuyruk yolları ve adları büyük/küçük harfe duyarlı değildir.)
Kuyruk uzunluğu işlevini alma Evet

(İletilerin süresi silinmeden TTL'nin ötesinde dolarsa yaklaşık değer.)
Evet

(Tam, belirli bir noktaya değer.)
Peek işlevi Evet Evet

Ek bilgi

  • Depolama kuyrukları, ad/değer çiftleri biçiminde kuyruk açıklamasına uygulanabilen rastgele öznitelikler için destek sağlar.
  • Her iki kuyruk teknolojisi de iletiyi kilitlemek zorunda kalmadan göz atma olanağı sunar. Bu, kuyruk gezgini/tarayıcı aracı uygulanırken yararlı olabilir.
  • Service Bus .NET aracılı mesajlaşma API'leri, HTTP üzerinden REST ile karşılaştırıldığında iyileştirilmiş performans için tam çift yönlü TCP bağlantıları kullanır ve AMQP 1.0 standart protokollerini destekler.
  • Depolama kuyruklarının adları 3-63 karakter uzunluğunda olabilir, küçük harf, sayı ve kısa çizgi içerebilir. Daha fazla bilgi için bkz . Kuyrukları ve Meta Verileri Adlandırma.
  • Service Bus kuyruğu adları en fazla 260 karakter uzunluğunda olabilir ve daha az kısıtlayıcı adlandırma kurallarına sahip olabilir. Service Bus kuyruğu adları harf, sayı, nokta, kısa çizgi ve alt çizgi içerebilir.

Kimlik doğrulaması ve yetkilendirme

Bu bölümde, Depolama kuyrukları ve Service Bus kuyrukları tarafından desteklenen kimlik doğrulaması ve yetkilendirme özellikleri ele alınmaktadır.

Karşılaştırma Ölçütleri Depolama kuyrukları Service Bus kuyrukları
Kimlik Doğrulaması Simetrik anahtar ve Rol tabanlı erişim denetimi (RBAC) Simetrik anahtar ve Rol tabanlı erişim denetimi (RBAC)
Kimlik sağlayıcısı federasyonu Evet Evet

Ek bilgi

  • Kuyruğa alma teknolojilerinden herhangi biri için yapılan her isteğin kimliği doğrulanmalıdır. Anonim erişime sahip genel kuyruklar desteklenmez.
  • Paylaşılan erişim imzası (SAS) kimlik doğrulamasını kullanarak, kullanıcılara salt yazma, salt okunur veya tam erişim verebilen bir kuyrukta paylaşılan erişim yetkilendirme kuralı oluşturabilirsiniz. Daha fazla bilgi için bkz. Azure Depolama - SAS kimlik doğrulaması ve Azure Service Bus - SAS kimlik doğrulaması.
  • Her iki kuyruk da Microsoft Entra Id kullanarak erişimi yetkilendirmeyi destekler. Microsoft Entra ID tarafından döndürülen OAuth 2.0 belirtecini kullanarak kullanıcıları veya uygulamaları yetkilendirmek, paylaşılan erişim imzaları (SAS) üzerinden üstün güvenlik ve kullanım kolaylığı sağlar. Microsoft Entra Id ile belirteçleri kodunuzda depolamanıza ve olası güvenlik açıklarını riske atmaya gerek yoktur. Daha fazla bilgi için bkz. Azure Depolama - Microsoft Entra kimlik doğrulaması ve Azure Service Bus - Microsoft Entra kimlik doğrulaması.

Sonuç

İki teknoloji hakkında daha ayrıntılı bilgi edinerek, hangi kuyruk teknolojisinin ne zaman kullanılacağı konusunda daha bilinçli bir karar vekleyebilirsiniz. Depolama kuyruklarının veya Service Bus kuyruklarının ne zaman kullanılacağına ilişkin karar birçok faktöre bağlıdır. Bu faktörler, uygulamanızın ve mimarinizin bireysel ihtiyaçlarına büyük ölçüde bağlıdır.

Aşağıdakiler gibi nedenlerle Depolama kuyrukları seçmeyi tercih edebilirsiniz:

  • Uygulamanız zaten Microsoft Azure'ın temel özelliklerini kullanıyorsa
  • Hizmetler arasında temel iletişim ve mesajlaşma gerekiyorsa
  • Boyutu 80 GB'tan büyük olabilecek kuyruklar gerekiyor

Service Bus kuyrukları aşağıdakiler gibi birçok gelişmiş özellik sağlar. Bu nedenle, karma bir uygulama oluşturuyorsanız veya uygulamanız bu özellikleri gerektiriyorsa tercih edilen bir seçenek olabilir.

Sonraki adımlar

Aşağıdaki makaleler, Depolama kuyruklarını veya Service Bus kuyruklarını kullanma hakkında daha fazla rehberlik ve bilgi sağlar.