Kuyruk Tabanlı Asenkron Mimari: Backpressure ve Teslim Garantileri
Yüksek trafikte asenkron mimari: kuyruk mu olay logu mu, backpressure tasarımı, "exactly-once" gerçeği ve idempotent tüketici, sıralama, DLQ ve zehirli mesaj yönetimi.
Asenkron mimari yüksek trafikte neyi çözer?
Zamanı ayrıştırır: üretici ile tüketicinin aynı anda, aynı hızda ve aynı sağlıkta olmak zorunluluğunu kaldırır. Zirve trafiği kuyrukta emilir, ağır iş arka planda sindirilir, geçici arızalar yeniden denemeyle kapanır. Ama bu güç bedava değildir: teslim garantileri, sıralama ve hata yönetimi artık mimarinizin açıkça tasarlaması gereken sözleşmelerdir. Bu yazı o sözleşmeleri kurar.
Kuyruk mu, olay logu mu?
Boyut | Mesaj kuyruğu (RabbitMQ tarzı) | Olay logu (Kafka tarzı) |
|---|---|---|
Model | İş dağıtımı: mesaj işlenir, silinir | Kayıt akışı: olaylar saklanır, tekrar okunabilir |
Güçlü olduğu yer | Görev kuyrukları, RPC-benzeri akışlar, esnek yönlendirme | Yüksek hacim, çoklu tüketici, yeniden oynatma (replay) |
Sıralama | Kuyruk bazında; rekabetçi tüketicide zayıflar | Partisyon içinde güçlü garanti |
Tipik kullanım | E-posta, PDF üretimi, entegrasyon görevleri | Olay yayını, CDC, akış işleme, denetim izi |
Karar iş modeliyle verilir: 'bu iş bir kez yapılsın ve bitsin' kuyruğun, 'bu olay birden çok sistemin gerçeği olsun' logun işidir. İkisinin bir arada yaşadığı mimariler normaldir; yanlış olan, birini diğerinin işine zorlamaktır.
Backpressure: sistemin fren sistemi
Asenkron mimarinin en çok atlanan parçası geri basınçtır: tüketici yavaşladığında biriken kuyruğun, sistemin geri kalanını nasıl etkileyeceği tasarlanmalıdır. Araç seti dört parçadır: sınırlı kuyruk derinliği (sonsuz kuyruk, ertelenmiş çöküştür — bellek/disk dolana kadar sorun görünmez); üretici tarafında yavaşlatma (kuyruk eşiği aşılınca üretim hızının kısılması veya düşük öncelikli işin reddi); tüketici önceden-çekme (prefetch) sınırı (tüketicinin hazmedebileceğinden fazla mesajı üstüne çekmemesi); ve kuyruk yaşı alarmı (derinlik kadar, en eski mesajın bekleme süresi de izlenir). Kampanya senaryosunda kuyruk tampondur — ama tamponun taşma davranışı önceden yazılmamışsa, çöküş yalnızca ertelenmiş olur.
Teslim garantileri: 'exactly-once' pazarlaması ve gerçek
Dağıtık sistemde pratik varsayılan at-least-once'tır: mesaj en az bir kez ulaşır, yani bazen iki kez ulaşır. 'Exactly-once' etiketi, belirli sınırlar içinde (aynı akış platformunun içi gibi) geçerli özel mekanizmaları anlatır; sizin veritabanınıza, e-posta sunucunuza, ERP'nize yazan uçtan uca akışta sihir yoktur. Bu yüzden kural değişmez: tüketici idempotent yazılır — iş anahtarı (sipariş no, mesaj kimliği) ile 'bunu daha önce işledim mi?' kontrolü yapılır; ikinci geliş, yeni etki üretmeden mevcut sonucu döner. Üretici tarafında da ikizi vardır: yayının veritabanı işlemiyle atomik bağlanması için outbox deseni. İdempotent tüketici + outbox üretici, asenkron mimarinin taşıyıcı kolonlarıdır.
Sıralama: küresel değil, anahtar bazında iste
Küresel sıralama, ölçekle çelişir — tek kuyruk/tek tüketici darboğazı demektir. Doğru hedef anahtar bazlı sıralamadır: aynı siparişin olayları sırayla işlensin, farklı siparişler paralel aksın. Log tarafında bu, partisyon anahtarıyla (orderId) doğal sağlanır; kuyruk tarafında anahtara göre tekil tüketici veya oturum mekanizmalarıyla kurulur. Tasarım sorusu şudur: 'hangi anahtarın içinde sıra şart?' — cevabı iş verir, altyapı uygular.
Hata yönetimi: retry, DLQ ve zehirli mesaj
Geçici hatalar (ağ, kilit, hedef sistemin anlık yoğunluğu) artan aralıklı yeniden denemeyle (exponential backoff + jitter) çözülür; kalıcı hatalar (bozuk veri, iş kuralı reddi) ise denemeyle düzelmez — sayaç sınırı dolunca mesaj ölü mektup kuyruğuna (DLQ) düşer. Zehirli mesaj (her işleyişte tüketiciyi düşüren kayıt) için bu sınır hayatidir; yoksa tek mesaj tüm hattı kilitler. DLQ bir çöp kutusu değil operasyon panosudur: boyutu alarma bağlıdır, içerik incelenebilir ve düzeltme sonrası güvenle tekrar oynatılır — ki bu da idempotent tüketici sayesinde risksizdir. Korelasyon kimliği uçtan uca loglanır; 'bu mesaj nerede?' sorusu dakikada cevaplanır.
İş etkisi: kuyruk, müşteri deneyiminin amortisörüdür
Asenkron mimarinin ticari değeri iki yerde okunur. Birincisi zirve dayanımı: sipariş alma hattı, arkadaki entegrasyonların hızından bağımsızlaşır — kampanyada ERP yavaşlasa bile satış durmaz, kuyruk sindirir. İkincisi operasyon sükûneti: geçici arızalar gece alarmı yerine sabah raporuna dönüşür, çünkü retry ve DLQ mekanizması olayı zaten yönetmiştir. Bu iki değerin ölçüsü de nettir: kuyruk yaş metriği hedefte, DLQ normalde boş.
Sık sorulan sorular
Her şeyi asenkron mu yapmalıyım?
Hayır: kullanıcının cevabını beklediği sorgular ve güçlü tutarlılık isteyen kritik yazmalar senkron kalır. Asenkron; ertelenebilir, yeniden denenebilir ve zirveye duyarlı işler içindir.
Kafka her zaman daha mı iyi?
Hayır — güç, ihtiyaç eşleşmesindedir. Görev dağıtımı ve esnek yönlendirmede klasik kuyruk sade ve yeterlidir; yüksek hacimli olay yayını ve replay ihtiyacında log mimarisi öne geçer.
Mesaj şeması nasıl evrilir?
Sözleşme sürümlenir: alan eklemek serbest, silmek/tip değiştirmek yeni sürüm ister; tüketici bilinmeyen alanı yok sayar. Şema kaydı (schema registry) bu disiplinin otomasyonudur.
Kuyruk gecikmesini kullanıcıya nasıl yansıtmalıyım?
Dürüst durum tasarımıyla: 'alındı → işleniyor → tamamlandı' adımlarının görünür olması, tamamlanma bildirimleri ve gerekiyorsa tahmini süre. Gecikmeyi gizlemek değil, yönetmek deneyimdir.
Asenkron mimari kontrol listesi
Senkron/asenkron ayrımı iş semantiğiyle yazılı
Kuyruk vs olay logu seçimi kullanım desenine göre yapıldı
Kuyruk derinliği sınırlı; üretici yavaşlatma eşiği tanımlı
Tüketiciler idempotent; üretici outbox ile atomik
Sıralama ihtiyacı anahtar bazında tanımlı ve uygulanmış
Backoff+jitter retry, deneme sınırı ve DLQ + alarm kurulu
Kuyruk yaşı ve DLQ boyutu panoda; replay süreci yazılı
SSH Yazılım, kuyruk tabanlı mimarilerin tasarımını ve mevcut sistemlerin asenkron dönüşümünü uçtan uca yürütür. Zirve dayanımınızı birlikte kuralım.