Skip to main content

> ölü_mektup_değişimleri_(dlx):_zehirli_mesaj_i̇zolasyonu_ve_otomatik_yeniden_sürme_(redrive)_boru_hatları

Ölü Mektup Değişimleri (DLX): Zehirli Mesaj İzolasyonu ve Otomatik Yeniden Sürme (Redrive) Boru Hatları

Bozuk mesajlar ('Zehirli Mesajlar - Poison Pills') RabbitMQ/Kafka tüketicilerinde neden sonsuz çökme döngüleri yaratır; Ölü Mektup Değişimleri (DLX) ve otomatik yeniden sürme (redrive) yapıları hatalı mesajları nasıl güvenle izole eder?

Senior (L5)

ÖZET VE TEKNİK CEVAP

Asenkron olay güdümlü mimarilerde bir tüketici bir mesajı işlerken temelde iki farklı sebepten hata alabilir: Kısa süre sonra kendiliğinden düzelen **Geçici Hatalar (Transient Errors)** (veritabanı anlık kopması, hız limiti) ve asla düzelmeyecek olan **Kalıcı Hatalar / Zehirli Mesajlar (Poison Pills)** (bozuk JSON, şema uyumsuzluğu, koddaki null pointer hatası). Tüketici bir zehirli mesajı sınırsız bir şekilde NACK (işlenemedi) edip kuyruğa geri bırakırsa, mesaj kuyruğun en başına döner. Tüketici mesajı tekrar alır, tekrar çöker ve bu döngü CPU'yu %100 kilitleyen bir **Sonsuz Çökme Döngüsüne (Poison Loop)** dönüşerek arkadaki binlerce geçerli mesajın işlenmesini durdurur. Canlı sistemler bunu **Ölü Mektup Değişimleri (Dead Letter Exchange - DLX)** ile çözer: (1) Mesaj deneme sayısını `max-delivery-count = 3-5` ile sınırlandırmak, (2) Limiti aşan mesajı hata detaylarıyla birlikte (`x-death`, `x-exception-stack`) izole bir `orders.dlx` kuyruğuna aktarmak, ve (3) Kod düzeltildikten sonra bu mesajları ana kuyruğa geri basan Otomatik Yeniden Sürme (Redrive) sistemleri kurmak.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

DLX hata izolasyonu 4 sistemik adımda gerçekleşir: (1) Deneme Sayacı Takibi: Her geçici hatada tüketici mesajdaki `x-retry-count` başlığını artırır ve gecikmeli olarak kuyruğa iade eder. (2) DLQ Yönlendirmesi: Deneme sayısı sınırı aştığında (`x-retry-count >= 5`), mesaj kuyruk yöneticisi tarafından doğrudan `queue.dlq` kuyruğuna aktarılır. (3) Hata Üstverisi Ekleme: Mesaja hata nedeni, yığın izi (stack trace) ve başarısızlık zamanı eklenir. (4) Yeniden Sürme (Redrive): Hata düzeltildikten sonra yönetim paneli veya CLI aracı üzerinden DLQ'daki mesajlar güvenle ana kuyruğa geri pompalanır.

2. Doğru Kullanım Senaryosu

Ödeme işleme kuyrukları, asenkron e-posta/SMS bildirim sistemleri, arka plan video işleme işçileri ve webhook karşılama servisleri.

3. Prodüksiyon Arıza Modları

DLQ'da biriken mesajlar için alarm kurmayıp binlerce siparişin sessizce kaybolmasına göz yummak; DLQ'daki 500.000 hatalı mesajı tek seferde ana sisteme basıp veritabanını aşırı yükten çökertmek.

4. Teşhis ve Telemetri Sinyalleri

DLQ kuyruk derinliği grafiğinin sıfırın üzerine çıkması; tüketici CPU'sunun %100'e vurması ancak işlenen mesaj sayısının sıfıra düşmesi; loglarda aynı hata izinin her milisaniye peş peşe basılması.

5. Önleme ve Mimari Bariyerler

Canlı ortamdaki her kuyruğa mutlaka bir `x-dead-letter-exchange` bağlayın; DLQ derinliği 0'ı geçtiğinde öten PagerDuty alarmları kurun; yeniden sürme (redrive) işlemlerini hız limitli (saniyede en fazla 50 mesaj) çalıştırın.

6. Mimari Ödünleşimler (Trade-offs)

DLQ mekanizmaları tüketici kilitlenmelerini önler ve sağlıklı trafiği korur; ancak hatalı mesajları incelemek ve güvenle yeniden sürmek için operasyonel araçlar gerektirir.

Vaka İncelemesi (TinyCTO Örneği)

Bir e-ticaret sipariş hazırlama servisi, bir satıcının posta kodu alanına emoji girmesi yüzünden çöktü. RabbitMQ'da DLX ayarlanmadığı için tüketici mesajı reddetti (NACK). Mesaj anında kuyruğun başına döndü ve 8 işçi pod'unun sonsuz çökme döngüsüne girmesine yol açarak arkadaki 45.000 siparişi kilitledi. SRE ekibi `x-max-delivery-count: 3` kuralıyla bir Ölü Mektup Kuyruğu (`fulfillment.dlx`) tanımladı. Zehirli mesaj 3 denemeden sonra DLQ'ya aktarıldı ve bekleyen 45.000 sipariş 4 dakikada işlendi. Geliştirici emoji hatasını düzelttikten sonra tek bir komutla DLQ'daki siparişi ana kuyruğa sürerek başarıyla tamamladı.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Mesaj kuyruğu mimarilerinde 'Zehirli Mesaj' (Poison Pill) nedir?

Tüketici tarafından işlenmesi imkansız olan, kuyruğa her iade edildiğinde uygulamanın tekrar çökmesine ve sonsuz döngüye girmesine yol açan bozuk mesajdır.
Q2

Otomatik Yeniden Sürme (Redrive) Boru Hattı ne işe yarar?

Koddaki hata veya altyapı kesintisi giderildikten sonra, DLQ'da bekleyen mesajları kontrollü bir şekilde ana işleme kuyruğuna geri aktarır.

Ölü Mektup Değişimleri (DLX): Zehirli Mesaj İzolasyonu ve Otomatik Yeniden Sürme (Redrive) Boru Hatları — Sıkça Sorulan Sorular

Bir DLQ yeniden sürme (redrive) işlemi sırasında veritabanını aşırı yükten korumak için ne yapılmalıdır?

Yeniden sürme aracına hız limiti (rate limit) koyarak mesajları tek seferde değil, saniyede 20-50 mesaj gibi kontrollü bir hızla ana kuyruğa aktarmak.

Bir mesaj DLQ'ya aktarılırken mesaja hangi teşhis başlıkları eklenmelidir?

Orijinal kuyruk adı, toplam deneme sayısı, son hata zamanı, fırlatılan hata mesajı ve yığın izi (stack trace).

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸Zehirli mesajlar deneme limiti olmadan kuyruğa iade edilirse sonsuz çökme döngülerine yol açar.
  • ▸Ölü Mektup Değişimleri belirli deneme sayısından ($N=3-5$) sonra hatalı mesajları izole eder.
  • ▸Sessiz veri kaybını önlemek için DLQ derinliği alarmları yüksek öncelikle izlenmelidir.
  • ▸Yeniden sürme sistemleri veritabanını korumak için mesaj aktarım hızını sınırlandırmalıdır.

Yaygın Yanılgılar

  • ✗Yanılgı: Mesajı DLQ'ya atmak hatayı çözer (Gerçek: DLQ sadece semptomu karantinaya alır; hatanın incelenmesi ve mesajın yeniden sürülmesi şarttır).
  • ✗Yanılgı: Sınırsız üstel deneme yapmak DLQ kullanmaktan daha iyidir (Gerçek: Sınırsız deneme kuyruk başını kilitler ve tüm tüketicilerin çökmesine sebep olur).

Karar Kılavuzu & Önceliklendirme

Mesaj akışının kesintisiz devam etmesi için tüm asenkron kuyrukları sınırlı deneme, DLX ve hız limitli yeniden sürme otomasyonu ile donatın.

Doğrulanmış Kaynaklar & Referanslar