Service Bus kuyrukları, konu başlıkları ve abonelikleri

Azure Service Bus, güvenilir ileti kuyruğa alma ve dayanıklı yayınlama/abonelik mesajlaşmasını destekler. Service Bus'taki mesajlaşma özelliklerinin temelini oluşturan mesajlaşma varlıkları kuyruklar, konular ve aboneliklerdir.

Bu makalede bu temel mesajlaşma varlıkları, bunların avantajları ve uygulama mimarinizde her birinin ne zaman kullanılacağı açıklanmaktadır.

Önemli

Azure Service Bus'ı yeni kullanıyorsanız bu makaleyi gözden geçirmeden önce Azure Service Bus'a giriş makalesini okuyun.

Kuyruklar ve konular arasında seçim yapma

Aşağıdaki tabloda, senaryonuz için doğru mesajlaşma varlığını seçmenize yardımcı olmak için kuyruklar ve konular arasındaki temel farklar özetlenir.

Özellik Kuyruklar Konular ve abonelikler
İletişim düzeni Noktadan noktaya Yayınla/abone (birden çoğa)
İleti teslimi İleti başına tek tüketici Birden çok abone kopya alabilir
Kullanım örneği Görev dağıtımı, yük dengeleme Etkinlik yayınlama, fan-out senaryoları
Filtreleme Desteklenmez Seçmeli ileti teslimi için abonelik filtreleri

Kuyruklar

Kuyruklar, bir veya birden çok rakip tüketiciye İlk Giren İlk Çıkar (FIFO) yöntemine göre ileti teslimi sunar. Yani, alıcılar genellikle iletileri kuyruğa eklendikleri sırayla alır ve işler. Her iletiyi yalnızca bir mesaj tüketicisi alır ve işler.

Gönderenlerden kuyruğa ve ardından alıcılara akan iletileri gösteren Service Bus kuyruğunun diyagramı.

Kuyrukları kullanmanın avantajları

Fayda Description
Zamansal ayrıştırma üreticiler (gönderenler) ve tüketiciler (alıcılar) aynı anda ileti göndermek ve almak zorunda değildir, çünkü iletiler kuyrukta durabilir bir şekilde depolanır. Üreticinin işlemeye devam etmek için tüketiciden yanıt beklemesi gerekmez.
Yük dengeleme Üreticiler ve tüketiciler farklı fiyatlarla ileti gönderip alabilir. Tüketen uygulamanın en yüksek yük yerine ortalama yükü işlemesi ve altyapı maliyetlerinden tasarruf etmesi gerekir.
Rakip tüketiciler Kuyruktan birden çok çalışan işlemi okuyabilir ve her ileti yalnızca bir çalışan tarafından işlenir. Bu çekme tabanlı yük dengeleme, çalışanların kendi maksimum hızlarında işlemesine olanak tanır.
Gevşek kavrama Üreticiler ve tüketiciler birbirinin farkında olmadığından, tüketici üreticiyi etkilemeden yükseltilebilir.

Kuyruk oluşturma

Aşağıdaki seçeneklerden birini kullanarak kuyruklar oluşturabilirsiniz:

Service Bus, ayırıcı olarak bölü işareti kullanılan hiyerarşik varlık adlarını destekler; örneğin orders/region/west. ARM tabanlı araçları (portal, CLI, PowerShell veya şablonlar) kullanırken, varlık adlarında / yerine ~ kullanın. Ayrıntılar için bkz. İleri eğik çizgi içeren öğe adları.

Ardından, aşağıdakiler de dahil olmak üzere programlama dillerinde yazılmış istemcileri kullanarak ileti gönderip alın:

Alma modları

Tüketicilerin Service Bus'tan ileti alabileceği iki farklı mod belirtebilirsiniz.

Alma ve silme modu

Service Bus isteği tüketiciden aldığında, iletiyi tüketildi olarak işaretler ve tüketici uygulamasına döndürür. Bu mod en basit modeldir ve uygulamanın bir hata oluşursa ileti işlememeye dayanabileceği senaryolar için en iyi şekilde çalışır.

Tüketici, mesajı işlemeden önce çökerse, Service Bus bunu zaten tüketilmiş olarak işaretlediği için mesaj kaybolur. Bu işlem genellikle en çok bir kez işleme olarak adlandırılır.

Önizleme kilidi modu

Alma işlemi iki aşamalı hale gelir, bu da eksik iletileri tolere edemeyen uygulamaları desteklemeyi mümkün kılar.

  1. Tüketilecek bir sonraki iletiyi bulmasının ardından, diğer tüketicilerin almasını önlemek için onu kilitler ve sonra mesajı uygulamaya döndürür.
  2. Uygulama iletiyi işlemeyi bitirdikten sonra Service Bus hizmetinden alma işleminin ikinci aşamasını tamamlamasını ister. Ardından hizmet , iletiyi tüketilen olarak işaretler.

Peek lock modunda hataları işleme:

  • Bırakma: Uygulama iletiyi işleyemiyorsa Service Bus'tan iletiyi bırakmasını isteyebilir. Service Bus iletinin kilidini açar ve yeniden alınabilecek şekilde kullanılabilir hale getirir.
  • Kilit zaman aşımı: Uygulama, kilit zaman aşımı süresi dolmadan önce iletiyi işleyemezse, Service Bus iletinin kilidini açar ve yeniden alınmaya hazır hale getirir.
  • Uygulama kilitlenmesi: Uygulama, iletiyi işledikten sonra ancak tamamlamadan önce kilitleniyorsa, uygulama yeniden başlatıldığında Service Bus iletiyi yeniden teslim eder. Bu işlem genellikle en az bir kez işlenir.

Senaryonuz yinelenen işlemeyi tolere edemiyorsa, yinelenenleri algılamak için uygulamanıza ek mantık ekleyin. Daha fazla bilgi için Yinelenen algılama olarak bilinen tam olarak bir kez işleme bakın.

Not

Bu iki mod hakkında daha fazla bilgi için bkz . Alma işlemlerini düzenleme.

Konular ve abonelikler

Kuyruk, iletinin tek bir müşteri tarafından işlenmesine olanak tanır. Kuyrukların aksine, konular ve abonelikler yayımlama ve abone olma düzeninde bire çok iletişim biçimi sağlar. Çok sayıda alıcıya ölçeklendirme açısından kullanışlıdır. Yayımlanan her ileti, konuya kayıtlı her abonelik için erişilebilir hale getirilir. Publisher bir konuya ileti gönderir ve bir veya daha fazla abone iletinin bir kopyasını alır.

İletilerin kopyalarını alan üç aboneliğin yer aldığı Service Bus konusunun diyagramı.

Yayımcılar, bir kuyruğa ileti gönderir gibi, bir konuya da ileti gönderir. Ancak tüketiciler doğrudan konu başlığından ileti almaz. Bunun yerine, tüketiciler konuyla ilgili aboneliklerden mesajlar alır. Konu aboneliği, konuya gönderilen iletilerin kopyalarını alan bir sanal kuyruğa benzer. Tüketiciler bir abonelikten kuyruktan ileti alma şekliyle aynı şekilde iletiler alır. Kuyruğun ileti gönderme işlevi doğrudan bir konuya eşler ve ileti alma işlevselliği bir aboneliğe eşler. Diğer özelliklerin yanı sıra, bu özellik aboneliklerin bu bölümün önceki kısmında kuyruklarla ilgili olarak açıklanan desenleri desteklediği anlamına gelir: rakip tüketici, zaman açısından ayrışma, yük düzleştirme ve yük dengeleme.

Abonelik filtreleri

Abonelikler, bir konu başlığından hangi iletileri almak istediklerini tanımlayabilir. Bu iletiler, bir veya daha fazla adlandırılmış abonelik kuralı biçiminde belirtilir. Her kural, belirli iletileri seçen bir filtre koşulundan oluşur ve isteğe bağlı olarak seçili iletiye ek açıklama ekleyen bir eylem içerir. Varsayılan olarak, bir konuya abonelik, konuya gönderilen tüm iletileri alır. Aboneliğin, tüm iletilerin aboneliğe seçilmesini sağlayan gerçek bir filtreye sahip ilk varsayılan kuralı vardır. Varsayılan kuralın ilişkili eylemi yoktur. Aboneliğin konu başlığına gönderilen iletilerin yalnızca bir alt kümesini alması için abonelikte kurallar ve eylemler içeren filtreler tanımlayabilirsiniz.

Filtreler hakkında daha fazla bilgi için bkz. Filtreler ve eylemler.

Konu başlıklarını ve abonelikleri oluşturma

Konu oluşturmak, önceki bölümde açıklandığı gibi kuyruk oluşturmaya benzer. Aşağıdaki seçeneklerden birini kullanarak konu başlıkları ve abonelikler oluşturabilirsiniz:

Ardından, bir konuya ileti gönderin ve aşağıdakiler dahil olmak üzere programlama dillerinde yazılmış istemcileri kullanarak aboneliklerden iletiler alın:

Kurallar ve eylemler

Birçok senaryoda, belirli özelliklere sahip iletiler farklı şekillerde işlenmelidir. Bu işlemeyi etkinleştirmek için abonelikleri, istenen özelliklere sahip iletileri bulacak ve ardından bu özelliklerde belirli değişiklikleri gerçekleştirecek şekilde yapılandırabilirsiniz. Service Bus abonelikleri konuya gönderilen tüm iletileri görse de, bu iletilerin yalnızca bir alt kümesini sanal abonelik kuyruğuna kopyalamak mümkündür. Bu filtreleme, abonelik filtreleri kullanılarak gerçekleştirilir. Bu tür değişikliklere filtre eylemleri adı verilir. Abonelik oluşturulduğunda, iletinin özellikleri üzerinde çalışan bir filtre ifadesi sağlayabilirsiniz. Özellikler hem sistem özellikleri (örneğin, Etiket) hem de özel uygulama özellikleri (örneğin, StoreName) olabilir. SQL filtre ifadesi bu durumda isteğe bağlıdır. SQL filtre ifadesi olmadan, bir abonelikte tanımlanan tüm filtre eylemleri söz konusu aboneliğin tüm iletilerinde gerçekleştirilir.

Tam çalışma örneği için GitHub'da TopicFilters örneğine bakın. Filtreler hakkında daha fazla bilgi için bkz . Konu filtreleri ve eylemleri.

Java message service (JMS) 2.0 varlıkları

Aşağıdaki varlıklara Java ileti hizmeti (JMS) 2.0 API'sini kullanarak erişilebilir.

  • Geçici kuyruklar
  • Geçici konular
  • Paylaşılan dayanıklı abonelikler
  • Paylaşılmayan dayanıklı abonelikler
  • Paylaşılan ve kalıcı olmayan abonelikler
  • Paylaşılamayan dayanıklı olmayan abonelikler

JMS 2.0 varlıkları ve bunların nasıl kullanılacağı hakkında daha fazla bilgi edinin.

İfade varlıkları

Önemli

Express varlıkları yeni uygulamalar için önerilmez. Service Bus'taki iyileştirmeler nedeniyle aktarım hızı ve gecikme süresi avantajları şu anda en düşük düzeydedir. Service Bus'ın Premium katmanı Express varlıklarını desteklemez.

Hızlı varlıklar yüksek aktarım hızı ve azaltılmış gecikme süresi senaryoları için oluşturulmuştur. Hızlı bileşenlerle, bir kuyruğa veya konuya ileti gönderilirse, ileti hemen mesajlaşma deposunda depolanmaz. Bunun yerine, ileti başlangıçta bellekte önbelleğe alınır. Varlıkta kalan iletiler bir gecikmeden sonra ileti deposuna yazılır ve bu noktada bir kesinti nedeniyle kaybolmaya karşı korunurlar.

Normal varlıklarda, herhangi bir çalışma zamanı işlemi (Send, Complete, Abandon, Deadletter gibi) önce depoda kalıcı hale gelir ve ancak işlem istemciye başarılı olduğu doğrulandıktan sonra kabul edilir. Hızlı varlıklarda, bir çalışma zamanı işlemi önce istemciye başarılı olduğu bildirilir ve yalnızca daha sonra tembelce veri saklama yerine kalıcı hale getirilir. Sonuç olarak, bir makine yeniden başlatıldığında veya bir donanım sorunu oluştuğunda, kabul edilen bazı çalışma zamanı işlemleri hiç kalıcı olmayabilir. Bu durumda istemci, olası veri kaybı ve/veya iletilerin yeniden teslimi pahasına express öğeleriyle daha düşük gecikme süresi ve daha yüksek aktarım hızı elde eder.

Sonraki adımlar

Örnekleri dilediğiniz dilde deneyin:

Eski .NET ve Java istemci kitaplıklarını kullanan örnekler için aşağıdaki bağlantıları kullanın:

30 Eylül 2026'da Azure SDK yönergelerine uymayan WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus ve com.microsoft.azure.servicebus Azure Service Bus SDK kitaplıklarını kullanımdan kaldıracağız. Ayrıca SBMP protokolünün desteğini de sonlandıracağız, bu nedenle 30 Eylül 2026'da bu protokolü artık kullanamayacaksınız. Bu tarihten önce kritik güvenlik güncelleştirmeleri ve geliştirilmiş özellikler sunan en son Azure SDK kitaplıklarına geçiş yapın.

Eski kitaplıklar 30 Eylül 2026'dan sonra da kullanılabilir olsa da artık Microsoft'tan resmi destek ve güncelleştirmeler almayacaktır. Daha fazla bilgi için destek kullanımdan kaldırma duyurusu'na bakın.

  • Last updated on