İleti oturumları
Azure Service Bus oturumları, sınırsız sayıda birbiriyle ilgili iletinin birlikte ve düzenli olarak işlenmesini sağlar. Oturumlar ilk in, first out (FIFO) ve request-response desenlerinde kullanılabilir. Bu makalede, Service Bus kullanılırken bu desenleri uygulamak için oturumların nasıl kullanılacağı gösterilmektedir.
Not
Service Bus temel katmanı oturumları desteklemez. Standart ve Premium katmanlar oturumları destekler. Bu katmanlar arasındaki farklar için bkz . Service Bus fiyatlandırması.
İlk gelen, ilk çıkan (FIFO) deseni
Service Bus kuyruklarında veya aboneliklerinde iletileri işlemede FIFO garantisi gerçekleştirmek için oturumları kullanın. Service Bus, iletiler arasındaki ilişkinin yapısı hakkında açıklayıcı değildir ve ayrıca ileti dizisinin nerede başladığını veya bittiğini belirlemek için belirli bir model tanımlamaz.
Herhangi bir gönderen, oturum kimliği özelliğini oturuma özgü uygulama tanımlı bir tanımlayıcıya ayarlayarak bir konuya veya kuyruğa ileti gönderirken oturum oluşturabilir. AMQP 1.0 protokol düzeyinde, bu değer group-id özelliğiyle eşler.
Oturum kullanan kuyruklarda veya aboneliklerde oturum kimliğine sahip en az bir ileti olduğunda oturumlar ortaya çıkar. Oturum mevcut olduğunda, oturumun süresinin dolmasına veya kaybolmasına yönelik tanımlı bir zaman veya API yoktur. Teorik olarak, bugün bir oturum için bir ileti, bir yıl içinde bir sonraki ileti alınabiliyor ve oturum kimliği eşleşiyorsa, oturum Service Bus perspektifinden aynıdır.
Ancak genellikle bir uygulama, bir dizi ilgili iletinin nereden başlayıp bittiğine ilişkin net bir nota sahiptir. Service Bus belirli bir kural ayarlamaz. Örneğin, uygulamanız ilk iletinin başlatılıp başlatılmayacağını, ara iletilerin içeriğe ve son iletinin sona ermesi için Label özelliğini ayarlayabilir. İçerik iletilerinin göreli konumu, SequenceNumber başlangıç iletisinden geçerli SequenceNumber delta iletisi olarak hesaplanabilir.
Önemli
Bir kuyrukta veya abonelikte oturumlar etkinleştirildiğinde, istemci uygulamaları artık normal iletiler gönderemez/alamaz. Tüm iletiler bir oturumun parçası olarak gönderilmelidir (oturum kimliği ayarlanarak) ve oturum kabul edilerek alınmalıdır. İstemciler yine de oturumların etkinleştirildiği bir kuyruğa veya aboneliğe göz atabilir. Bkz. İletiye göz atma.
Oturumlar için API'ler kuyruk ve abonelik istemcilerinde bulunur. Oturumların ve iletilerin ne zaman alındığını denetleyen kesinlik temelli bir model ve alma döngüsünü yönetmenin karmaşıklığını gizleyen işleyici tabanlı bir model vardır.
Örnekler için Sonraki adımlar bölümündeki bağlantıları kullanın.
Oturum özellikleri
Oturumlar, sıralı teslimi korurken ve garanti ederken, birbirine kaydedilen ileti akışlarının eş zamanlı ayrıştırılması sağlar.
Oturumu kabul eden istemci tarafından bir oturum alıcısı oluşturulur. Oturum bir istemci tarafından kabul edildiğinde ve tutulduğunda, istemci kuyrukta veya abonelikte bu oturumun oturum kimliğine sahip tüm iletilerde özel bir kilit tutar. Daha sonra gelen oturum kimliğine sahip tüm iletilerde özel kilitler tutar.
Alıcıda close yöntemlerini çağırdığınızda veya kilidin süresi dolduğunda kilit serbest bırakılır. Alıcıda kilitleri yenileme yöntemleri de vardır. Bunun yerine, kilidi yenilemeye devam etmek istediğiniz süreyi belirtebileceğiniz otomatik kilit yenileme özelliğini kullanabilirsiniz. Oturum kilidi bir dosyada özel kilit olarak ele alınmalıdır; başka bir deyişle, uygulama artık gerekli olmadığı ve/veya başka ileti beklemediği anda oturumu kapatmalıdır.
Birden çok eşzamanlı alıcı kuyruktan iletileri çekerken, belirli bir oturuma ait iletiler o anda söz konusu oturumun kilidini tutan alıcıya gönderilir. Bu işlemle, bir kuyruk veya abonelikteki araya eklenen ileti akışı, farklı alıcılara temiz bir şekilde karıştırılır ve kilit yönetimi Service Bus'ın içinde hizmet tarafında gerçekleştiğinden, bu alıcılar farklı istemci makinelerinde de yaşayabilir.
Önceki çizimde üç eşzamanlı oturum alıcısı gösterilmektedir. = 4 olan SessionId bir Oturumun etkin, sahibi olan bir istemcisi yoktur; bu da bu oturumdan hiçbir iletinin teslim edilmemiş olduğu anlamına gelir. Oturum, bir alt kuyruk gibi birçok şekilde davranır.
Oturum alıcısı tarafından tutulan oturum kilidi, peek-lock düzenleme modu tarafından kullanılan ileti kilitleri için bir şemsiyedir. Oturumda yalnızca bir alıcı kilitlenebilir. Bir alıcının çok sayıda uçuş içi iletisi olabilir, ancak iletiler sırayla alınır. İletinin bırakılması, aynı iletinin bir sonraki alma işlemiyle yeniden teslim edilmesine neden olur.
İleti oturumu durumu
İş akışları yüksek ölçekli, yüksek kullanılabilirlikli bulut sistemlerinde işlendiğinde, belirli bir oturumla ilişkili iş akışı işleyicisinin beklenmeyen hatalardan kurtarabilmesi gerekir ve işin başladığı farklı bir işlem veya makinede kısmen tamamlanmış çalışmayı sürdürebilir.
Oturum durumu özelliği, aracı içindeki bir ileti oturumunun uygulama tanımlı ek açıklamasını etkinleştirir, böylece oturum yeni bir işlemci tarafından alındığında oturuma göre kaydedilen işleme durumu anında kullanılabilir hale gelir.
Service Bus perspektifinden bakıldığında, ileti oturum durumu, Service Bus Standard için 256 KB ve Service Bus Premium için 100 MB olan tek ileti boyutundaki verileri tutabilen opak bir ikili nesnedir. Oturuma göre işleme durumu oturum durumunda tutulabilir veya oturum durumu bu bilgileri barındıran bir depolama konumuna veya veritabanı kaydına işaret edebilir.
Ve GetStateoturum durumunu yönetme yöntemleri, SetState oturum alıcısı nesnesinde bulunabilir. Daha önce oturum durumu olmayan bir oturum için GetStatenull başvuru döndürür. Önceden ayarlanmış oturum durumu, alıcıdaki yönteme SetState null geçirilerek temizlenebilir.
Oturumdaki tüm iletiler tüketilmiş olsa bile oturum durumu temizlenmediği (null döndüren) sürece kalır.
Bir kuyrukta veya abonelikte tutulan oturum durumu, bu varlığın depolama kotasına göre sayılır. Uygulama bir oturumla bittiğinde, dış yönetim maliyetini önlemek için uygulamanın korumalı durumunu temizlemesi önerilir.
Teslim sayısının etkisi
Oturumlar bağlamında ileti başına teslim sayısı tanımı, oturumların yokluğundaki tanımdan biraz farklıdır. Burada, teslim sayısının ne zaman artırıldığında özetlendiği bir tablo yer alır.
| Senaryo | İletinin teslim sayısı artırıldı mı? |
|---|---|
| Oturum kabul edilir, ancak oturum kilidinin süresi dolar (zaman aşımı nedeniyle) | Yes |
| Oturum kabul edilir, oturum içindeki iletiler tamamlanmaz (kilitli olsalar bile) ve oturum kapatılır | Hayır |
| Oturum kabul edilir, iletiler tamamlanır ve oturum açıkça kapatılır | Yok (Standart akıştır. Burada, iletiler oturumdan kaldırılır) |
İstek-yanıt düzeni
İstek-yanıt deseni, gönderen uygulamasının istek göndermesini sağlayan ve alıcının gönderen uygulamaya doğru bir şekilde yanıt göndermesi için bir yol sağlayan, iyi oluşturulmuş bir tümleştirme desenidir. Bu desen genellikle uygulamanın yanıt gönderebilmesi için kısa süreli bir kuyruğa veya konuya ihtiyaç duyar. Bu senaryoda oturumlar, benzer semantiklere sahip basit bir alternatif çözüm sağlar.
Birden çok uygulama isteklerini tek bir istek kuyruğuna gönderebilir ve gönderen uygulamayı benzersiz olarak tanımlamak için belirli bir üst bilgi parametresi ayarlanır. Alıcı uygulaması kuyrukta gelen istekleri işleyebilir ve oturum etkin kuyrukta yanıt gönderebilir ve oturum kimliğini istek iletisinde gönderenin gönderdiği benzersiz tanımlayıcıya ayarlayabilir. İsteği gönderen uygulama daha sonra belirli oturum kimliğindeki iletileri alabilir ve yanıtları doğru şekilde işleyebilir.
Not
İlk istekleri gönderen uygulamanın oturum kimliği hakkında bilgi sahibi olması ve bu kimliği kullanarak yanıtı beklediği oturumun kilitlenmesi için oturumu kabul etmesi gerekir. Uygulamanın örneğini oturum kimliği olarak benzersiz olarak tanımlayan bir GUID kullanmak iyi bir fikirdir. Yanıtların belirli alıcılar tarafından kilitlenip işlenebilmesini sağlamak için kuyruk için oturum alıcıda oturum işleyicisi veya zaman aşımı belirtilmemiş olmalıdır.
Sıralama ve oturumlar karşılaştırması
Sıra numarası kendi başına sıraya alma sırasını ve iletilerin ayıklama sırasını garanti eder, ancak oturumlar gerektiren işlem sırasını garanti eder.
Kuyrukta üç ileti ve iki tüketici olduğunu varsayalım.
- Tüketici 1, ileti 1'i alır.
- Tüketici 2, 2. iletiyi alır.
- Tüketici 2, ileti 2'yi işlemeyi tamamlar ve 3. iletiyi alırken, Tüketici 1 henüz ileti 1'i işlemeyi tamamlamaz.
- Tüketici 2, ileti 3'in işlenmesini tamamlar, ancak tüketici 1 ileti 1'i işleme işlemi henüz tamamlanmamıştır.
- Son olarak, tüketici 1 ileti 1'i işlemeyi tamamlar.
Dolayısıyla iletiler şu sırayla işlenir: ileti 2, ileti 3 ve ileti 1. 1, 2 ve 3 iletilerinin sırayla işlenmesi gerekiyorsa oturumları kullanmanız gerekir.
İletilerin yalnızca sırayla alınması gerekiyorsa oturumları kullanmanız gerekmez. İletilerin sırayla işlenmesi gerekiyorsa oturumları kullanın. Bir kümede 1, 4 ve 8, başka bir kümede 2, 3 ve 6 olabilecek, birbirine ait iletilerde aynı oturum kimliği ayarlanmalıdır.
İleti süre sonu
Oturum etkin kuyruklar veya konuların abonelikleri için iletiler oturum düzeyinde kilitlenir. İletilerden herhangi birinin yaşam süresi (TTL) sona eriyorsa, varlıkta mesajlaşma süre sonu ayarında etkin olan teslim edilemedi harfine bağlı olarak bu oturumla ilgili tüm iletiler bırakılır veya geçersiz harfe dönüştürülür. Başka bir deyişle, oturumda TTL'yi geçen tek bir ileti varsa, oturumdaki tüm iletilerin süresi dolar. İletilerin süresi yalnızca etkin bir dinleyici varsa dolar. Daha fazla bilgi için bkz . İleti süre sonu.
Sonraki adımlar
Azure portalı, PowerShell, CLI, Resource Manager şablonu, .NET, Java, Python ve JavaScript kullanarak kuyruk oluştururken ileti oturumlarını etkinleştirebilirsiniz. Daha fazla bilgi için bkz . İleti oturumlarını etkinleştirme.
Azure Service Bus özelliklerini keşfetmek için örnekleri istediğiniz dilde deneyin.
- .NET
- Java
- Python
- JavaScript