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

Bu makalede, Microsoft Azure tarafından sunulan iki kuyruk türü arasındaki farklar ve benzerlikler analiz Depolama kuyruklar ve Service Bus vardır. Bu bilgileri kullanarak, hangi çözümün ihtiyaçlarınıza en uygun olduğu konusunda daha bilinçli bir karar veebilirsiniz.

Giriş

Azure iki tür kuyruk mekanizmasını destekler: Depolama ve kuyrukları Service Bus destekler.

Depolama kuyrukları Azure depolama altyapısının Depolama vardır. Çok sayıda ileti depolamaya 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 iletisi boyutu en fazla 64 KB olabilir. Kuyrukta, bir depolama hesabının toplam kapasite sınırına kadar milyonlarca ileti olabilir. Kuyruklar genellikle zaman uyumsuz olarak iş için bir iş biriktirme listesi 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 bir parçası. Birden çok iletişim protokolüne, veri sözleşmelerine, güven etki alanlarına veya ağ ortamlarına yayma durumlarını kapsayan uygulamaları veya uygulama bileşenlerini tümleştirin. Kuyruklar/Service Bus/abonelikler hakkında daha fazla bilgi için, Service Bus, konu başlıkları ve abonelikler için bkz..

Teknoloji seçiminde dikkat edilmesi gerekenler

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

Hangi kuyruğa alma teknolojisinin belirli bir çözümün amacına uygun olduğunu belirlerken, çözüm mimarlarının ve geliştiricilerin bu önerileri dikkate almaları gerekir.

Kuyrukları Depolama düşünün

Çözüm mimarı/geliştiricisi olarak, aşağıdakiler olduğunda Depolama kullanmayı göz önünde bulundurarak:

  • Uygulamanın bir kuyrukta 80 gigabayttan fazla ileti depolaması gerekir.
  • Uygulamanız kuyrukta bir iletiyi işleme ilerlemesini izlemek istiyor. İletiyi işen ç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 üzerinde yürütülen tüm işlemlerin sunucu tarafı günlüklerini gerektirirsiniz.

Kuyrukları Service Bus düşünün

Çözüm mimarı/geliştiricisi olarak, aşağıdakiler olduğunda Service Bus kullanmayı göz önünde bulundurarak:

  • Çözümünüz, kuyruğu yoklamadan iletileri almak zorunda. Bu Service Bus, uzun yoklama alma işlemi kullanarak, bu işlemi destekleyen TCP tabanlı protokolleri kullanarak Service Bus elde edin.
  • Çözümünüz, kuyruğun garantili ilk çıkar (FIFO) siparişli teslimini sağlamayı gerektirir.
  • Çözümünüz, otomatik yinelenenleri algılamayı desteklemeli.
  • Uygulamanın iletileri paralel uzun süre çalışan akışlar olarak işlemesi gerekir (iletiler iletideki oturum kimliği özelliği kullanılarak bir akışla ilişkilendirilmiştir). Bu modelde, iletilerin aksine, tüketen uygulamanın her düğümü akışlar için rekabettedir. Tüketen düğüme bir akış verlendiğinde düğüm, işlemleri kullanarak uygulama akış durumunu inceler.
  • Çö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'yi aşan ancak büyük olasılıkla 256 KB sınırına yaklaşmayan iletileri işlemektedir.
  • Kuyruklara rol tabanlı bir erişim modeli ve gönderenler ve alıcılar için farklı haklar/izinler sağlama gereksinimiyle uğraşabilirsiniz. Daha fazla bilgi için aşağıdaki makaleleri inceleyin:
  • Kuyruk boyutunuz 80 GB'den büyük olmayacaktır.
  • AMQP 1.0 standartları tabanlı mesajlaşma protokolünü kullanmak istediğiniz. 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 bir geçiş hayal ediyor olabilirsiniz. Bu düzen, ek alıcıların (aboneler) tümleştirmeye olanak sağlar. Her alıcı, kuyruğa gönderilen bazı veya tüm iletilerin bağımsız kopyalarını alır.
  • Mesajlaşma çözümünüz, ek altyapı bileşenleri derlemenize gerek kalmadan "En Çok Bir Kez" teslim garantisini desteklemesi gerekir.
  • Çözümde toplu ileti yayımlaması ve tüketmesi gerekiyor.

Kuyrukları Depolama kuyrukları Service Bus karşılaştırma

Aşağıdaki bölümlerde yer alan tablolar, kuyruk özelliklerinin mantıksal bir gruplama sağlar. Hem Azure kuyruklarında hem de kuyruklarda kullanılabilen özellikleri bir bakışta Depolama karşılaştırma Service Bus sağlar.

Temel özellikler

Bu bölümde, kuyruklar ve kuyruklar tarafından sağlanan temel Depolama bazı Service Bus karşılaştırabilirsiniz.

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

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

(ileti oturumlarını kullanarak)
Teslim garantisi En Az Bir Kez En Az Bir Kez (PeekLock alma modunu kullanarak). Varsayılan değerdir)

En Çok Bir Kez (ReceiveAndDelete alma modunu kullanarak)

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

Alma davranışı Engelleyici olmayan

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

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

Engelleyici olmayan

(yalnızca .NET yönetilen API kullanarak)
Itme stili API'si Hayır Evet

.NET, Java, JavaScript ve Go API'lerimiz anında yükleme stili API'ler sağlar.
Alma modu Peek & Lease Peek & Lock

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

7 gün (en fazla) (UpdateMessage API'sini kullanarak ileti kiralamasını yeniler veya serbest abilirsiniz.)
30 saniye (varsayılan)

İleti kilidini her el ile aynı kilit süresi boyunca yenileyebilirsiniz veya istemcinin kilit yenilemeyi sizin için yönett olduğu otomatik kilit yenileme özelliğini kullanabilirsiniz.
Kira/Kilitleme duyarlığı İleti düzeyi

Her ileti farklı bir zaman aşımı değerine sahip olabilir ve bu değeri updateMessage API'sini kullanarak iletiyi işlerken gereken şekilde güncelleştirebilirsiniz.
Kuyruk düzeyi

(her kuyruğun tüm iletilerine uygulanan bir kilit duyarlığı vardır, ancak kilit önceki satırda açıklandığı şekilde yenilenebilir)
Toplu alma Evet

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

(bir önceden getirme özelliğini örtülü olarak veya işlemler kullanılarak açıkça etkinleştirme)
Toplu gönder Hayır Evet

(işlemler veya istemci tarafı toplu işlem kullanarak)

Ek bilgiler

  • 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 bir istemci uygulama bir iletiyi işlerken çökirken. 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. Bu noktada, yeni görünür ileti sıraya alınmış olarak yeniden kuyruğa alınır.
  • Service Bus kuyruklarındaki garantili fıfo deseninin mesajlaşma oturumlarının kullanılması gerekir. Uygulama, Peek & kilit modunda alınan bir iletiyi işlerken kilitlenirse, bir kuyruk alıcısı bir ileti oturumu kabul ettiğinde, iletinin yaşam SÜRESI (TTL) döneminin süresi dolduktan sonra başarısız iletisiyle başlar.
  • Depolama kuyrukları, aşağıdakiler gibi standart sıraya alma senaryolarını destekleyecek şekilde tasarlanmıştır:
    • Hatalara karşı ölçeklenebilirlik ve toleransı artırmak için uygulama bileşenlerini Ayrıştır
    • Yük Dengeleme
    • İşlem iş akışları oluşturuluyor.
  • Service Bus oturumlarının bağlamındaki ileti işleme ile ilgili tutarsızlıklar, oturum durumu kullanılarak, oturumun ileti sırasını işleme ilerleme durumuyla ilgili olarak uygulamanın durumunu depolamak için ve alınan iletilerin ve oturum durumunu güncelleştiren işlemler kullanılarak kaçınılabilir. Bu tür bir tutarlılık özelliği bazen diğer satıcının ürünlerinde işleme olarak bir kez etiketlidir. Tüm işlem sorunları, iletilerin yeniden gönderilmesine neden olur ve bu nedenle terim tam olarak yeterli değildir.
  • Depolama kuyruklar, hem geliştiriciler hem de operations ekipleri için kuyruklar, tablolar ve bloblar genelinde tekdüzen ve tutarlı bir programlama modeli sağlar.
  • Service Bus kuyrukları, tek bir sıra bağlamında yerel işlemler için destek sağlar.
  • 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.
  • Depolama kuyruklar, iletiler için kiraları genişletme olanağı sunan kiralamalar sağlar. Bu özellik, çalışan işlemlerinin iletilerde kısa kiraları korumasına olanak tanır. Bu nedenle, bir çalışan kilitlenirse, ileti başka bir çalışan tarafından hızla yeniden işlenebilir. Ayrıca, bir çalışan bir ileti üzerinde kirayı, geçerli kira süresinden daha uzun süre işlemesi gerekiyorsa genişletebilir.
  • Depolama kuyruklar, bir iletinin ensıraya alınması veya sıradan çıkarılması üzerinde ayarlayabileceğiniz bir görünürlük zaman aşımı sağlar. Ayrıca, çalışma zamanında farklı kira değerleriyle bir ileti güncelleştirebilir ve aynı kuyruktaki iletiler arasında farklı değerleri güncelleştirebilirsiniz. Service Bus kilit zaman aşımları sıra meta verilerinde tanımlanmıştır. Ancak, önceden tanımlı kilit süresi için ileti kilitlemeyi el ile yenileyebilir veya istemcinin kilit yenilemesini sizin için yönettiği otomatik kilit yenileme özelliğini kullanabilirsiniz.
  • Service Bus kuyruklarındaki engelleme alma işlemi için maksimum zaman aşımı 24 gündür. Ancak, REST tabanlı zaman aşımları 55 saniyelik en büyük değere sahiptir.
  • 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. Toplu işleme yalnızca zaman uyumsuz gönderme işlemleri için kullanılabilir.
  • Depolama kuyruklarının 200 TB 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 haline getirir.
  • Depolama kuyruklar, esnek ve yüksek performanslı bir erişim denetimi mekanizması sağlar.

Gelişmiş yetenekler

bu bölümde Depolama kuyrukları ve Service Bus kuyrukları tarafından sunulan gelişmiş yetenekler karşılaştırılır.

Karşılaştırma ölçütleri Depolama kuyrukları Service Bus kuyrukları
Zamanlanmış teslim Evet Evet
Otomatik olarak atılacak Hayır Evet
Sıra yaşam süresi değerini artırma Evet

(görünürlük zaman aşımı ile yerinde güncelleştirme aracılığıyla)
Evet

(özel bir API işlevi ile sunulmaktadır)
Zarar iletisi desteği Evet Evet
Yerinde güncelleştirme Evet Evet
Sunucu tarafı işlem günlüğü Evet Hayır
Depolama ölçümleri Evet

Dakikalık ölçümler kullanılabilirlik, TPS, API çağrı sayıları, hata sayıları ve daha fazlası için gerçek zamanlı ölçümler sağlar. Bunlar gerçek zamanlı olarak, dakikada toplanan ve birkaç dakika içinde, üretimde gerçekleşen süreden itibaren raporlanır. daha fazla bilgi için bkz. Depolama Analizi ölçümleri hakkında.
Evet

Azure Service Bus tarafından desteklenen ölçümler hakkında daha fazla bilgi için bkz. ileti ölçümleri.
Durum yönetimi Hayır Evet (etkin, devre dışı, Senddisabled, receivedisabled. Bu durumlarıyla ilgili ayrıntılar için, bkz. sıra durumu)
İletiyi oto iletme Hayır Evet
Temizleme kuyruğu işlevi Evet Hayır
İleti grupları Hayır Evet

(mesajlaşma oturumlarını kullanarak)
İleti grubu başına uygulama durumu Hayır Evet
Yineleme algılama Hayır Evet

(Gönderen tarafında yapılandırılabilir)
İleti gruplarına göz atma Hayır Evet
KIMLIĞE göre ileti oturumları getiriliyor Hayır Evet

Ek bilgiler

  • Her iki sıraya alma teknolojisi de bir iletinin daha sonra teslim edilmek üzere zamanlanmasını sağlar.
  • Sıra oto iletme, binlerce sıranın iletileri, alıcı uygulamanın iletiyi tükettiği tek bir kuyruğa iletmesini sağlar. Bu mekanizmayı, güvenlik ve denetim akışı sağlamak ve her bir ileti yayımcısı arasında depolamayı yalıtmak için kullanabilirsiniz.
  • Depolama kuyrukları ileti içeriğini güncelleştirmek için destek sağlar. 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. Service Bus kuyruklarında, ileti oturumlarını kullanarak aynı senaryoya izin verebilirsiniz. Daha fazla bilgi için bkz. ileti oturumu durumu.
  • Service Bus kuyrukları, atılacakaraçları destekler. Aşağıdaki ölçütlere uyan iletileri yalıtmak yararlı olabilir:
    • İletiler, alıcı uygulama tarafından başarıyla işlenemiyor
    • Süresi biten yaşam süresi (TTL) özelliği nedeniyle iletiler hedefine ulaşamamanıza izin vermez. TTL değeri, bir iletinin kuyrukta ne kadar süreyle kalacağını belirtir. Service Bus, bu ileti TTL süresi sona erdiğinde $DeadLetterQueue adlı özel bir kuyruğa taşınır.
  • Depolama kuyruklarındaki "poison" iletilerini bulmak için, bir iletiyi sıradan kaldırdığınızda, uygulamanın dequeuecount özelliğini inceler. Dequeuecount verilen eşikten büyükse, uygulama iletiyi uygulama tanımlı "atılacak mektup" kuyruğuna taşımalıdır.
  • Depolama kuyruklar, sıraya göre yürütülen tüm işlemlerin ayrıntılı bir günlüğünü elde etmeniz ve toplu ölçümler elde etmeniz sağlar. bu seçeneklerin her ikisi de hata ayıklama ve uygulamanızın Depolama kuyrukları nasıl kullandığını anlamak için yararlıdır. Ayrıca, uygulamanızı performans ayarlaması ve kuyrukları kullanmanın maliyetlerini azaltma için de kullanışlıdır.
  • Service Bus tarafından desteklenen ileti oturumları bir mantıksal gruba ait olan iletileri bir alıcı ile ilişkilendirilecek şekilde etkinleştirir. İletiler ve ilgili alıcılar arasında oturum benzeri bir benzeşim oluşturur. ileti üzerinde oturum kimliği özelliğini ayarlayarak Service Bus bu gelişmiş işlevselliği etkinleştirebilirsiniz. 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.
  • Service Bus kuyruklarının çoğaltma algılaması ö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ümde, Depolama kuyrukları ve Service Bus kuyrukları, uygulayabilen kapasite ve kotalar açısından karşılaştırılır.

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

( tek bir depolama hesabı kapasitesinesınırlı)
1 GB ila 80 GB

(bir kuyruk oluşturulduktan ve bölümleme etkinleştirildikten sonra tanımlanır), "ek bilgi" bölümüne bakın
En büyük ileti boyutu 64 KB

( Base64 kodlaması KULLANıLıRKEN 48 KB)

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.
256 KB veya 1 MB

(başlık ve gövde dahil, en büyük üst bilgi boyutu: 64 KB).

Hizmet katmanınabağlıdır.
En fazla ileti TTL Sonsuz (API-sürüm 2017-07-27 veya üzeri) TimeSpan. Max
En fazla sıra sayısı Sınırsız 10.000

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

Ek bilgiler

  • Service Bus kuyruk boyutu sınırlarını zorlar. Kuyruk oluşturulurken en büyük sıra boyutu belirtilir. 1 GB ile 80 GB arasında olabilir. Kuyruğun boyutu bu sınıra ulaşırsa, ek gelen iletiler reddedilir ve çağıran bir özel durum alır. Service Bus kotaları hakkında daha fazla bilgi için bkz. Service Bus kotalar.
  • Premium katmanındabölümlendirme desteklenmez. standart mesajlaşma katmanında, 1 (varsayılan), 2, 3, 4 veya 5 GB boyutunda Service Bus kuyruklar ve konular oluşturabilirsiniz. bölümlendirme etkinken, Service Bus aynı boyuttaki her biri varlığın 16 kopyasını (16 bölüm) oluşturur. Bu nedenle, boyutu 5 GB olan ve 16 bölümlü bir sıra oluşturursanız, en büyük sıra boyutu (5 * 16) = 80 GB olur. Azure Portalbölümlenmiş kuyruğun veya konusunun en büyük boyutunu görebilirsiniz.
  • Depolama kuyruklarında, iletinin içeriği XML-safe değilse, Base64 kodlamalı olmalıdır. İletiyi Base64 olarak kodlarsanız, kullanıcı yükü 64 kb yerıne 48 KB 'ye kadar olabilir.
  • Service Bus kuyruklarında, bir sırada depolanan her ileti iki bölümden oluşur: başlık ve gövde. İletinin toplam boyutu hizmet katmanının desteklediği en büyük ileti boyutunu aşamaz.
  • istemciler 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. Bu sayı, Gönderenler ve alıcılar arasında paylaşılır. Bu kotaya ulaşıldığında, ek bağlantı istekleri reddedilir ve çağıran kod tarafından bir özel durum alınır. Bu sınır, REST tabanlı API kullanılarak kuyruklara bağlanan istemcilere uygulanmaz.
  • tek bir Service Bus ad alanında 10.000 ' den fazla kuyruk gerekiyorsa, Azure destek ekibine başvurarak bir artış isteyebilirsiniz. 10.000 kuyruklarının ötesinde Service Bus ölçeklendirmek için Azure portalkullanarak ek ad alanları da oluşturabilirsiniz.

Yönetim ve işlemler

bu bölümde Depolama kuyrukları ve Service Bus kuyrukları tarafından sunulan yönetim özellikleri karşılaştırılır.

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

AMQP 1,0 standart (TLS ile TCP)
.NET API’si Evet

(.net Depolama istemci apı 'si)
Evet

(.net Service Bus apı)
Yerel C++ Evet Evet
Java API’si Evet Evet
PHP APı '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 adlarında harfler küçük harf olmalıdır.)
En fazla 260 karakter uzunluğunda

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

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

(Tam, zaman içinde nokta değeri.)
Peek işlevi Evet Evet

Ek bilgiler

  • Depolama, kuyruk açıklamasına ad/değer çiftleri şeklinde uygulanacak rastgele öznitelikler için destek sağlar.
  • Her iki kuyruk teknolojisi de bir iletiyi kilitlemek zorunda kalmadan göz atma özelliği sunar. Bu, kuyruk gezgini/tarayıcı aracı uygulanırken yararlı olabilir.
  • .NET Service Bus aracılı mesajlaşma API'leri, HTTP üzerinden REST'e kıyasla daha iyi performans için tam çift yönlü TCP bağlantıları kullanır ve AMQP 1.0 standart protokolünü destekler.
  • Kuyrukların Depolama 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 adları en fazla 260 karakter uzunluğunda olabilir ve daha az kısıtlayıcı adlandırma kurallarına sahip olabilir. Service Bus adları harf, sayı, nokta, kısa çizgi ve alt çizgi içerebilir.

Kimlik doğrulaması ve yetkilendirme

Bu bölümde, kuyruklar ve kuyruklar tarafından desteklenen kimlik Depolama yetkilendirme Service Bus ele almaktadır.

Karşılaştırma Ölçütleri Depolama kuyrukları Service Bus kuyrukları
Kimlik Doğrulaması Simetrik anahtar Simetrik anahtar
Güvenlik modeli SAS belirteçleri aracılığıyla temsilci erişimi. SAS
Kimlik sağlayıcısı federasyonu Evet Evet

Ek bilgiler

  • Kuyruğa alma teknolojilerden herhangi biri için yapılan her isteğin kimliği doğrulanmış olması gerekir. Anonim erişimi olan genel kuyruklar desteklenmiyor. SAS kullanarak,salt yazma SAS, salt okunur SAS ve hatta tam erişimli BIR SAS yayımlarsanız bu senaryoyu ele aabilirsiniz.
  • Farklı kuyruklar tarafından Depolama kimlik doğrulama düzeni, simetrik anahtar kullanımını içerir. Bu anahtar, SHA-256 İleti Kimlik Doğrulama Kodu hesaplanan ve Base64 dizesi olarak kodlanmış karma tabanlı bir İleti Kimlik Doğrulama Kodu (HMAC) anahtarıdır. İlgili protokol hakkında daha fazla bilgi için bkz. Azure Depolama Hizmetleri için kimlik doğrulaması. Service Bus kuyrukları simetrik anahtarlar kullanılarak benzer bir modeli destekler. Daha fazla bilgi için bkz. Service Bus ile Paylaşılan Erişim İmzası Kimlik Doğrulaması.

Sonuç

İki teknoloji hakkında daha derin bir anlayışa sahip olarak, hangi kuyruk teknolojisinin ne zaman ve ne zaman kullanabileceğine ilişkin daha bilinçli bir karar ve ardından. Kuyrukları veya kuyrukları Depolama kullanma kararı Service Bus birçok faktöre bağlıdır. Bu faktörler, uygulamanın ve mimarisinin tek tek ihtiyaçlarına büyük ölçüde bağımlı olabilir.

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

  • Uygulamanız zaten temel özellikleri kullanıyorsa Microsoft Azure
  • Hizmetler arasında temel iletişim ve mesajlaşmaya ihtiyaç ediyorsanız
  • Boyutu 80 GB'den büyük olan kuyruklar gerekiyor

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

Sonraki adımlar

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