Persistent (kalıcı) mesajlar ve kuyruklar Durable, Transient, Exclusive, Auto-Delete gibi kuyruk özellikleri Prefetch ayarları ve flow control Dead Letter Queues (DLQ) ve tekrar deneme (retry) stratejileri TTL (Time to Live) ayarları ve zaman aşım mekanizmaları

1. Persistent (Kalıcı) Mesajlar ve Kuyruklar

Bu konu, bir mesajın veya kuyruğun sistem çökse bile kaybolmamasını sağlamakla ilgili. Düşünsene, bir sistemde çok önemli mesajlar gönderiyorsun ve bir anda sunucu çöküyor. Eğer mesajlar persistent değilse, hepsi uçup gider! Ama persistent (kalıcı) yaparsan, bu mesajlar disk üzerinde saklanır ve sistem yeniden başladığında mesajlar hala orada olur.

  • Persistent Mesaj: Mesaj gönderilirken persistent olarak işaretlenir ve mesaj broker (mesajı yöneten sistem, örneğin RabbitMQ) bunu diske yazar. Böylece sistem çökse bile mesaj kaybolmaz.
  • Persistent Kuyruk: Kuyruğun kendisi de kalıcı yapılabilir. Kuyruk tanımlanırken durable seçilirse, kuyruk bilgisi de sistem yeniden başlasa bile kaybolmaz.

Özet: Kalıcı mesajlar ve kuyruklar, sistemin çökmesi durumunda veri kaybını önler. Ama bu biraz daha yavaş olabilir çünkü disk yazma işlemi hafıza yazmaya göre daha uzun sürer.

2. Kuyruk Özellikleri: Durable, Transient, Exclusive, Auto-Delete

Kuyruk oluştururken birkaç önemli ayar var ve bunlar kuyrukların nasıl çalışacağını belirliyor. Bunları teker teker inceleyelim:

  • Durable (Dayanıklı): Kuyruk durable olarak ayarlanırsa, sistem çökse bile kuyruk bilgisi korunur. Ama dikkat: Kuyruk durable olsa bile, içine attığın mesajlar persistent değilse, mesajlar kaybolabilir!
  • Transient (Geçici): Bu terim genelde mesajlar için kullanılır. Geçici mesajlar sadece RAM'de tutulur ve sistem kapandığında kaybolur. Performans açısından daha hızlıdır, ama güvenilirlik düşüktür.
  • Exclusive (Özel): Kuyruk exclusive olarak tanımlanırsa, o kuyruğa sadece bir bağlantı (connection) erişebilir. Bu bağlantı kapandığında kuyruk da otomatik olarak silinir. Genelde tek bir uygulama için geçici işler yaparken kullanılır.
  • Auto-Delete (Otomatik Silme): Kuyrukta mesaj kalmazsa ve kuyruk artık kullanılmıyorsa otomatik olarak silinir. Bu özellik genelde geçici işler için açılır, böylece sistem gereksiz kuyruklarla dolmaz.

Örnek: Bir kuyruk tanımlarken şöyle bir şey görebilirsin:


channel.queue_declare(queue='my_queue', durable=True, exclusive=False, auto_delete=False)

3. Prefetch Ayarları ve Flow Control

Burada işler biraz daha teknikleşiyor!

  • Prefetch: Bu ayar, bir tüketiciye (consumer) aynı anda kaç mesaj gönderileceğini belirler. Diyelim ki bir tüketici çok yavaş çalışıyor ama sen ona sürekli mesaj gönderiyorsun. İşte prefetch ayarı ile bu durumu kontrol edebilirsin. Mesela, prefetch_count=1 dersen, tüketici bir mesajı işlerken yeni bir mesaj gönderilmez.Neden önemli? Yavaş tüketicilerin kuyruğu şişirip sistemi tıkamasını önlemek için.
  • Flow Control (Akış Kontrolü): Mesaj broker, çok fazla mesaj biriktiğinde ya da tüketiciler yetişemediğinde sistemin yavaşlamasını sağlar. Bu, aşırı yüklenmeyi önler ve sistemin çökmesini engeller.

Örnek:

channel.basic_qos(prefetch_count=1)

Bu satırla, her tüketici bir seferde yalnızca bir mesaj alır ve onu işlemeden yeni bir mesaj almaz.

4. Dead Letter Queues (DLQ) ve Tekrar Deneme (Retry) Stratejileri

Bazen mesajlar işlenemeyebilir. Mesela bir hata olur, veri yanlış gelir ya da tüketici beklenmeyen bir durumla karşılaşır. İşte böyle durumlarda Dead Letter Queue (DLQ) devreye girer.

  • Dead Letter Queue (DLQ): İşlenemeyen mesajlar, özel bir kuyruğa (DLQ) gönderilir. Bu mesajlar daha sonra incelenebilir ya da tekrar işlenmek üzere sisteme geri gönderilebilir.
  • Retry (Tekrar Deneme) Stratejileri: Mesajlar işlenemezse, belirli bir süre sonra tekrar denemek isteyebilirsin. Genelde şu yöntemler kullanılır:
    • Sabit Gecikmeli Deneme (Fixed Delay Retry): Her başarısız denemeden sonra belirli bir süre bekleyip tekrar denersin.
    • Artan Gecikmeli Deneme (Exponential Backoff): Her başarısız denemede bekleme süresi katlanarak artar.

Örnek: Bir mesaj 3 kez işlenemediğinde DLQ'ya gönderilmesini sağlayabilirsin.

5. TTL (Time to Live) Ayarları ve Zaman Aşım Mekanizmaları

TTL (Time to Live), bir mesajın veya kuyruğun ne kadar süre sistemde kalacağını belirler. Mesaj, belirlenen süre boyunca tüketilmezse otomatik olarak silinir ya da DLQ'ya taşınır.

  • Mesaj Bazlı TTL: Mesaj gönderilirken, o mesajın ne kadar süre geçerli olacağını belirleyebilirsin. Süre dolduğunda mesaj silinir.
  • Kuyruk Bazlı TTL: Kuyruğa gelen tüm mesajlar için genel bir TTL belirlenir. Bu süre içinde işlenmeyen tüm mesajlar silinir.

Neden Önemli? Eski mesajların sistemde birikmesini ve gereksiz yere kaynak tüketmesini önler.

Örnek:

args = {'x-message-ttl' : 60000}  # Mesajlar 60 saniye sonra silinir.
channel.queue_declare(queue='my_queue', arguments=args)

Buradaki konu başlıklarını daha iyi anlayabilmen için, daha önce yayımladığım 3 makaleyi okumanı öneririm. Bu terimleri tam anlamıyla kavradığında, makale serisinin sonunda tüm bu konuları içeren bir projeyle pratik yapacağız. Bir sonraki makalede görüşmek üzere!