İleti aktarımları, kilitler ve kapatma

  • Makale

Service Bus gibi bir ileti aracısının merkezi özelliği, iletileri bir kuyruğa veya konuya kabul etmek ve daha sonra almak üzere kullanılabilir durumda tutmaktır. Send , bir iletinin ileti aracısı içine aktarılması için yaygın olarak kullanılan terimdir. Alma , bir iletinin alma istemcisine aktarılması için yaygın olarak kullanılan terimdir.

İstemci bir ileti gönderdiğinde genellikle iletinin aracıya düzgün aktarılıp aktarılmadığını ve aracı tarafından kabul edilip edilmediğini veya bir tür hata oluşup oluşmadığını bilmek ister. Bu olumlu veya olumsuz bildirim, iletinin aktarım durumu hakkında hem istemcinin hem de aracının anlaşılmasını sağlar. Bu nedenle, buna düzenleme denir.

Benzer şekilde, aracı bir iletiyi bir istemciye aktardığında, aracı ve istemci iletinin başarıyla işlenip işlenmediğini ve bu nedenle kaldırılıp kaldırılamayacağını ya da ileti tesliminin veya işlemenin başarısız olup olmadığını ve dolayısıyla iletinin yeniden teslim edilmesi gerekip gerekmediğini anlamak ister.

Gönderme işlemlerini kapatma

Desteklenen Service Bus API istemcilerinden herhangi birini kullanarak, Service Bus'a gönderme işlemleri her zaman açıkça tamamlanır, yani API işlemi Service Bus'tan bir kabul sonucunun gelmesini bekler ve sonra gönderme işlemini tamamlar.

İleti Service Bus tarafından reddedilirse, reddetme bir hata göstergesi ve içinde izleme kimliği bulunan bir metin içerir. Reddetme işlemi, işlemin herhangi bir başarı beklentisiyle yeniden denenip denenemeyeceğiyle ilgili bilgiler de içerir. İstemcide, bu bilgiler bir özel duruma dönüştürülür ve gönderme işleminin çağıranı için oluşturulur. İleti kabul edilirse işlem sessizce tamamlanır.

Gelişmiş Mesajlaşma Kuyruğa Alma Protokolü (AMQP), .NET Standard, Java, JavaScript, Python ve Go istemcileri için desteklenen tek protokoldür. .NET Framework istemcileri için Service Bus Mesajlaşma Protokolü (SBMP) veya AMQP kullanabilirsiniz. AMQP protokolunu kullandığınızda, ileti aktarımları ve düzenleme işlemleri işlem hattı oluşturulur ve zaman uyumsuz olur. Zaman uyumsuz programlama modeli API'sinin değişkenlerini kullanmanızı öneririz.

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 bkz . destek kullanımdan kaldırma duyurusu.

Gönderen, SBMP protokolünde veya HTTP 1.1'de olduğu gibi, her iletinin onaylanmasını beklemek zorunda kalmadan birkaç iletiyi ardı ardına kabloya ekleyebilir. İlgili iletiler kabul edildikçe ve depolandığında, bölümlenmiş varlıklarda veya farklı varlıklara gönderme işlemi çakıştığında bu zaman uyumsuz gönderme işlemleri tamamlanır. Tamamlamalar, özgün gönderme siparişinin dışında da gerçekleşebilir.

Gönderme işlemlerinin sonucunu işleme stratejisi, uygulamanız için anında ve önemli bir performans etkisine sahip olabilir. Bu bölümdeki örnekler C# dilinde yazılmıştır ve Java gelecekleri, Java mono'ları, JavaScript vaatleri ve diğer dillerdeki eşdeğer kavramlar için geçerlidir.

Uygulama burada düz döngüyle gösterilen ileti serileri üretirse ve hem bir sonraki iletiyi, hem zaman uyumlu hem de zaman uyumsuz API şekillerini göndermeden önce her gönderme işleminin tamamlanmasını beklerse, düzenleme için yalnızca 10 sıralı tam gidiş dönüş sonrasında 10 ileti gönderilir.

Şirket içi bir siteden Service Bus'a 70 milisaniyelik İletim Denetimi Protokolü (TCP) gidiş dönüş gecikme süresi uzaklığı olduğu varsayılarak ve Service Bus'ın her iletiyi kabul etmesi ve depolaması için yalnızca 10 ms süre verilmesiyle, aşağıdaki döngü yük aktarım süresini veya olası yol tıkanıklığı etkilerini saymak yerine en az 8 saniye sürer:

for (int i = 0; i < 10; i++)
{
    // creating the message omitted for brevity
    await sender.SendMessageAsync(message);
}

Uygulama 10 zaman uyumsuz gönderme işlemini hemen art arda başlatır ve bunların ilgili tamamlanmalarını ayrı olarak beklerse, bu 10 gönderme işlemi için gidiş dönüş süresi çakışıyor. 10 ileti anında ve hatta TCP çerçevelerini paylaşarak aktarılır ve genel aktarım süresi büyük ölçüde iletileri aracıya aktarmak için gereken ağ ile ilgili süreye bağlıdır.

Önceki döngüyle aynı varsayımlarla, aşağıdaki döngü için toplam çakışan yürütme süresi bir saniyenin altında kalabilir:

var tasks = new List<Task>();
for (int i = 0; i < 10; i++)
{
    tasks.Add(sender.SendMessageAsync(message));
}
await Task.WhenAll(tasks);

Tüm zaman uyumsuz programlama modellerinin bekleyen işlemleri barındıran bir tür bellek tabanlı, gizli iş kuyruğu kullandığını unutmayın. Gönderme API'si döndürdüğünde, gönderme görevi bu iş kuyruğunda kuyruğa alınır, ancak protokol hareketi yalnızca görevin çalışma sırası geldiğinde başlar. İletileri gönderme eğiliminde olan ve güvenilirliğin önemli olduğu kodlar için, çok fazla iletinin aynı anda "uçuşa" konulmadığına dikkat edilmelidir, çünkü gönderilen tüm iletiler kabloya konana kadar belleği alır.

C# dilinde aşağıdaki kod parçacığında gösterildiği gibi semaforlar, gerektiğinde bu tür uygulama düzeyinde azaltmayı etkinleştiren eşitleme nesneleridir. Bu semafor kullanımı, aynı anda en fazla 10 iletinin uçuşta olmasını sağlar. Kullanılabilir 10 semafor kilidinden biri göndermeden önce alınır ve gönderme tamamlandıktan sonra serbest bırakılır. Döngüden geçen 11. geçiş, önceki gönderme işlemlerinden en az biri tamamlanana kadar bekler ve ardından kilidini kullanılabilir hale getirir:

var semaphore = new SemaphoreSlim(10);

var tasks = new List<Task>();
for (int i = 0; i < 10; i++)
{
    await semaphore.WaitAsync();

    tasks.Add(sender.SendMessageAsync(message).ContinueWith((t)=>semaphore.Release()));
}
await Task.WhenAll(tasks);

Uygulamalar, işlemin sonucunu almadan hiçbir zaman uyumsuz gönderme işlemini "tetikle ve unut" şeklinde başlatmamalıdır. Bunu yapmak, iç ve görünmez görev kuyruğunun bellek tükenmesine kadar yüklenmesini ve uygulamanın gönderme hatalarını algılamasını engelleyebilir:

for (int i = 0; i < 10; i++)
{
    sender.SendMessageAsync(message); // DON’T DO THIS
}

Düşük düzey amqp istemcisi ile Service Bus ayrıca "önceden ayarlanmış" aktarımları kabul eder. Önceden ayarlanmış aktarım, her iki durumda da sonucun istemciye geri bildirilmeyen ve ileti gönderildiğinde tamamlandığı kabul edilen bir fire-and-forget işlemidir. İstemciye geri bildirim olmaması, tanılama için eyleme dönüştürülebilir veri olmadığı anlamına da gelir ve bu da bu modun Azure desteği aracılığıyla yardım için uygun olmadığı anlamına gelir.

Alma işlemlerini kapatma

Alma işlemleri için Service Bus API istemcileri iki farklı açık modu etkinleştirir: Receive-and-Delete ve Peek-Lock.

ReceiveAndDelete

Alma ve Silme modu, aracıya alıcı istemciye gönderdiği tüm iletileri gönderildiğinde tamamlanmış olarak dikkate almasını söyler. Bu, iletinin aracı tarafından kabloya yerleştirildiğinde tüketildiğinin kabul edildiği anlamına gelir. İleti aktarımı başarısız olursa, ileti kaybolur.

Bu modun en iyi tarafı, alıcının ileti üzerinde daha fazla işlem gerçekleştirmesi gerekmemesi ve düzenlemenin sonucunun beklenmesiyle de yavaş olmamasıdır. Tek tek iletilerde yer alan verilerin değeri düşükse ve/veya yalnızca çok kısa bir süre için anlamlıysa, bu mod makul bir seçimdir.

PeekLock

Peek-Lock modu, aracıya alıcı istemcinin alınan iletileri açıkça çözmek istediğini bildirir. İleti, diğer rakip alıcıların görememesi için hizmette özel bir kilit altında tutulurken alıcının işlemesi için kullanılabilir hale getirilir. Kilidin süresi başlangıçta kuyruk veya abonelik düzeyinde tanımlanır ve RenewMessageLockAsync işlemi aracılığıyla kilidin sahibi olan istemci tarafından uzatılabilir. Kilitleri yenileme hakkında ayrıntılı bilgi için bu makaledeki Kilitleri yenileme bölümüne bakın.

bir ileti kilitlendiğinde, aynı kuyruktan veya abonelikten gelen diğer istemciler kilitleri alabilir ve etkin kilit altında olmayan sonraki kullanılabilir iletileri alabilir. bir iletideki kilit açıkça serbest bırakıldığında veya kilidin süresi dolduğunda, ileti yeniden teslim için alma sırasının önüne veya önüne yerleştirilir.

İleti alıcılar tarafından tekrar tekrar serbest bırakıldığında veya kilidin tanımlı bir süre boyunca geçmesine izin verdiklerinde (En Fazla Teslim Sayısı), ileti otomatik olarak kuyruktan veya abonelikten kaldırılır ve ilişkili teslim edilemeyen ileti kuyruğuna yerleştirilir.

Alıcı istemci, ileti için Complete API'sini çağırdığında olumlu bir bildirimle alınan bir iletinin düzenlemesini başlatır. Aracıya iletinin başarıyla işlendiğini ve iletinin kuyruktan veya abonelikten kaldırıldığını gösterir. Aracı, alıcının düzenleme amacını, düzenlemenin yapılıp yapılamayacağını belirten bir yanıtla yanıtlar.

Alıcı istemci bir iletiyi işleyemediğinde ancak iletinin yeniden teslim alınmasını istediğinde, açıkça ileti için Abandon API'sini çağırarak iletinin serbest bırakılıp kilidinin açılmasını isteyebilir veya hiçbir şey yapamaz ve kilidin geçmesine izin verebilir.

Alıcı istemci bir iletiyi işleyemezse ve iletiyi yeniden teslim edip işlemi yeniden denemenin yardımcı olmadığını bilirse, iletide DeadLetter API'sini çağırarak iletiyi reddedebilir ve bu da iletiyle birlikte teslim edilemeyen ileti kuyruğundan alınabilecek bir neden kodu içeren özel bir özellik ayarlamaya olanak tanır.

Not

Bir kuyruk veya konu aboneliği için yalnızca kuyruk veya abonelik için teslim edilemeyen harf özelliğini etkinleştirdiğinizde bir teslim edilemeyen harf alt sırası vardır.

Ayrı bir makalede ele alınan erteleme, özel bir düzenleme durumudur.

Tutulan kilidin Completesüresi dolduysa veya kapatmayı engelleyen başka hizmet tarafı koşulları varsa, , DeadLetterveya RenewLock işlemleri ağ sorunları nedeniyle başarısız olabilir. İkinci durumlardan birinde hizmet, API istemcilerinde özel durum olarak ortaya çıkar ve negatif bir bildirim gönderir. Bunun nedeni bozuk bir ağ bağlantısıysa, Service Bus farklı bir bağlantıdaki mevcut AMQP bağlantılarının kurtarılmasını desteklemediğinden kilit bırakılır.

Başarısız olursa Complete , bu genellikle ileti işlemenin en sonunda ve bazı durumlarda iş işleme dakikalarından sonra gerçekleşirse, alan uygulama işin durumunu korumaya ve ikinci kez teslim edildiğinde aynı iletiyi yoksaymaya veya ileti yeniden teslim edildikçe iş sonucunu atıp atmayacağına ve yeniden deneneceğine karar verebilir.

Yinelenen ileti teslimlerini tanımlamaya yönelik tipik mekanizma, gönderen tarafından benzersiz bir değere ayarlanabilen ve bu değerin kaynak işlemdeki bir tanımlayıcıyla hizalanmış olması gereken ileti kimliğini denetlemektir. Bir iş zamanlayıcı, ileti kimliğini büyük olasılıkla belirtilen çalışanla çalışana atamaya çalıştığı işin tanımlayıcısına ayarlar ve bu iş zaten yapılmışsa çalışan iş atamasının ikinci oluşumunu yoksayar.

Önemli

PeekLock veya SessionLock'un iletide aldığı kilidin geçici olduğunu ve aşağıdaki koşullarda kaybolabileceğini unutmayın

  • Hizmet Güncelleştirmesi
  • İşletim sistemi güncelleştirmesi
  • Kilidi tutarken varlıkta (Kuyruk, Konu, Abonelik) özellikleri değiştirme.

Kilit kaybolduğunda, Azure Service Bus istemci uygulamasında ortaya çıkacak bir MessageLockLostException veya SessionLockLostException oluşturur. Bu durumda, istemcinin varsayılan yeniden deneme mantığı otomatik olarak devreye girer ve işlem tekrar denenir.

Kilitleri yenileme

Kilit süresi için varsayılan değer 1 dakikadır. Kuyruk veya abonelik düzeyinde kilit süresi için farklı bir değer belirtebilirsiniz. Kilidin sahibi olan istemci, alıcı nesnesinde yöntemleri kullanarak ileti kilidini yenileyebilir. Bunun yerine, kilidi yenilemeye devam etmek istediğiniz süreyi belirtebileceğiniz otomatik kilit yenileme özelliğini kullanabilirsiniz.

Kilidi yenilemeniz gerekmeyecek şekilde, kilit süresini normal işlem sürenizden daha yüksek bir değere ayarlamak en iyisidir. Maksimum değer 5 dakikadır, bu nedenle daha uzun süreye sahip olmak istiyorsanız kilidi yenilemeniz gerekir. Gerektiğinden daha uzun bir kilit süresine sahip olmak da bazı etkilere neden olur. Örneğin, istemciniz çalışmayı durdurduğunda, ileti yalnızca kilit süresi geçtikten sonra yeniden kullanılabilir duruma gelir.

Sonraki adımlar