Mesaj Kuyruğu (Message Queue) Nedir?

Üretici, broker, tüketici

Bir e-ticaret sitesinde sipariş alındığında stok düşülür, fatura kesilir, depoya bildirim gider ve müşteriye e-posta atılır. Bunların hepsini sipariş isteği içinde, birbiri ardına yapmak hem yavaştır hem de kırılgandır: e-posta servisi o an yanıt vermezse sipariş de hata verir. Mesaj kuyruğu bu zinciri koparır. Sipariş servisi bir mesaj bırakır ve işine döner; ilgili servisler mesajları kendi hızlarında alır.

• Üretici (producer): Mesajı oluşturup kuyruğa gönderen taraf.
• Message broker: Mesajları kabul eden, saklayan, doğru kuyruğa yönlendiren ve tüketicilere dağıtan sunucu yazılımı ya da yönetilen servis.
• Tüketici (consumer): Mesajı alıp işleyen ve işin bittiğini broker'a bildiren taraf.

Bu ayrımın üç somut faydası vardır. Zamansal bağımsızlık: tüketici bakımda olsa bile mesajlar kaybolmaz, döndüğünde işlenir. Yük tamponu: kampanya anındaki ani sipariş dalgası kuyrukta birikir, arka taraf onu sabit bir hızla eritir. Yatay ölçek: yetişemeyen bir kuyruk için yeni tüketici eklemek yeterlidir; bu, ölçeklenebilirliğin en ucuz yollarından biridir.

Onay (ack) ve “en az bir kez” teslim

Broker bir mesajı tüketiciye verdiğinde onu hemen silmez. Tüketici işi bitirip onay (acknowledgement, ack) gönderene kadar mesaj “işlemde” sayılır. Tüketici çökerse veya belirlenen süre içinde onay gelmezse mesaj tekrar kuyruğa döner ve başka bir tüketiciye verilir.

mesaj = kuyruk.al(gorunmezlik_suresi=30)   # 30 sn boyunca başkasına verilmez
siparisi_isle(mesaj.govde)                 # yan etkiler burada
kuyruk.onayla(mesaj)                       # ack: ancak iş bittikten sonra

Bu düzen mesaj kaybını önler ama bir bedeli vardır: iş yapılıp tam onay gönderilecekken bağlantı koparsa, mesaj ikinci kez işlenir. Teslim garantileri genellikle üç başlıkta anlatılır:

Pratikte çoğu sistem en az bir kez teslim eder. Örneğin Amazon SQS standart kuyrukları için AWS dokümantasyonu, aynı mesajın nadiren tekrar alınabileceğini belirtir ve uygulamaların idempotent tasarlanmasını önerir. Yani tüketici, aynı mesajı iki kez gördüğünde ikinci kez para çekmemeli veya ikinci bir fatura kesmemelidir. Bunun yolu idempotency'dir: mesaj kimliğini kaydedip daha önce işlenmiş olanı atlamak.

Kuyruk ve konu: bir mesajı kaç tüketici alır?

Klasik kuyrukta (point-to-point) her mesajı tüketicilerden yalnızca biri alır; tüketiciler işi paylaşan rakip işçilerdir. “Sipariş oluşturuldu” gibi bir bilginin fatura, depo ve analitik servislerinin her birine ayrı ayrı ulaşması gerekiyorsa yayınla-abone ol (pub/sub) modeli kullanılır; her abone mesajın kendi kopyasını alır. Bu ikinci model, olay güdümlü mimarinin temelidir. RabbitMQ gibi broker'lar iki modeli de exchange ve kuyruk tanımlarıyla kurmaya izin verir.

İşlenemeyen mesajlar ve geri basınç

Bozuk bir mesaj her denemede tüketiciyi hataya düşürüyorsa sonsuz bir döngü oluşur. Bunun önlemi, belirli sayıda başarısız denemeden sonra mesajı ayrı bir “ölü mesaj kuyruğuna” (dead letter queue) taşımaktır; oradaki mesajlar incelenip düzeltildikten sonra yeniden gönderilebilir. İzlenmesi gereken bir diğer gösterge kuyruk derinliği ve en eski mesajın yaşıdır. Kuyruk sürekli büyüyorsa tüketiciler üretimin gerisinde kalmıştır; bu, ya daha fazla tüketiciye ya da üreticiyi yavaşlatan bir geri basınç (backpressure) mekanizmasına ihtiyaç olduğunu gösterir.

Kuyruk ne zaman gereksiz?

Kullanıcının sonucu hemen görmesi gereken işlemler, örneğin oturum açma veya stok sorgusu, doğrudan istek-yanıtla daha basit ve anlaşılırdır. Tek sunucuda çalışan küçük bir uygulama için ayrı bir broker işletmek de çoğu zaman fazla yüktür; veritabanı tablosu üzerinde çalışan basit bir iş kuyruğu aynı ihtiyacı karşılayabilir. Dış bir sistemin size olay bildirmesi gerekiyorsa da kuyruk yerine bir webhook yeterli olabilir.