Bir mesaj kuyruğu, işi üreten sistemlerle işi yapan sistemleri birbirinden ayırır. Producer'lar mesajları broker'a teslim edip yollarına devam eder; consumer'lar onları kendi hızlarında işler. Bu size trafik dalgalanmalarında tamponlama, bir consumer başarısız olduğunda retry ve producer'larla consumer'ları bağımsız ölçekleme imkânı kazandırır — asenkron mesajlaşmanın çoğu ciddi mikroservis mimarisinin temelinde yatmasının nedeni de budur.

AMQP Modeli: Exchange'ler, Binding'ler, Routing Key'ler

RabbitMQ, AMQP 0-9-1 etrafında inşa edilmiş bir message broker'dır; RabbitMQ 4.x serisiyle birlikte yerleşik AMQP 1.0 desteği de eklendi. Giriş anlatımlarının çoğunun atladığı kısım şudur: RabbitMQ'da producer'lar kuyruklara yayınlamaz — exchange'lere yayınlar ve her mesajın hangi kuyruklara ulaşacağına, mesajın routing key'ine bakarak binding'ler karar verir. Exchange tipleri yönlendirme davranışını tanımlar: direct (routing key'in birebir eşleşmesi), topic (desen eşleşmesi, örn. orders.*.created), fanout (bağlı her kuyruğa yayın) ve headers. Bu yönlendirme katmanı RabbitMQ'nun asıl gücüdür: yayınlanan tek bir event, producer hiçbirinin varlığından haberdar olmadan bir iş kuyruğuna, bir denetim kuyruğuna ve bir bildirim kuyruğuna dağılabilir.

Kuyruk tarafında RabbitMQ 4.x üç seçenek sunar: klasik kuyruklar, quorum kuyruklar (Raft ile replike edilen, önemi olan her şey için varsayılan tercih — klasik mirrored kuyruklar 4.0'da kaldırıldı) ve Kafka benzeri kullanım senaryoları için append-only, tekrar oynatılabilir bir log tipi olan stream'ler.

Kalıcılık Varsayılan Değil, Bilinçli Bir Tercihtir

Kuyruk sistemleri mesaj kaybını kendiliğinden önlemez. RabbitMQ'da bir broker restart'ını atlatmak üç bilinçli seçim gerektirir: kuyruğu durable olarak tanımlayın, mesajları persistent olarak yayınlayın ve producer'ın mesajın broker tarafından gerçekten yazıldığını bilmesi için publisher confirm'leri etkinleştirin. Tüketici tarafında, makul bir prefetch limitiyle birlikte, işleme başarıyla tamamlandıktan sonra gönderilen manuel acknowledgement'lar kullanın — auto-ack, bir consumer çöktüğünde uçuştaki mesajların sessizce çöpe gitmesi demektir. Bunlardan herhangi birini atlarsanız, er ya da geç o klasik hata kaydını açarsınız: "kuyruk mesajımı kaybetti."

Teslim Garantileri ve Idempotency

Gerçekçi olarak elde edebileceğiniz garantiler at-most-once veya at-least-once'tır. İşe yarayan seçenek olan at-least-once, duplikasyon demektir: bir consumer, mesajı işledikten sonra ama acknowledge etmeden önce çökerse, mesaj yeniden teslim edilir. Bağımsız sistemler arasında uçtan uca exactly-once pratikte ulaşılabilir değildir; bu etkiyi consumer'ları idempotent yaparak — deduplication key'ler, upsert'ler, koşullu yazmalar — yaklaşık olarak elde edersiniz; böylece aynı mesajı iki kez işlemek hiçbir şeyi değiştirmez.

Sıralama da aynı dürüstlüğü hak ediyor. Kuyruktaki mesajlar sıralı saklanır, ama katı sıralama yalnızca tek consumer ile korunur. Birbirleriyle yarışan birden fazla consumer'a ölçeklendiğiniz anda — ki normal desen budur — mesajlar sırasız tamamlanır. Sıralama entity bazında önemliyse, ihtiyacınız olan daha büyük bir RabbitMQ kuyruğu değil, partition-key semantiğidir (Kafka veya SQS FIFO message group'ları).

Dead-Letter Kuyrukları

Consumer'ını çökerten bozuk bir "poison" mesaj, aksi hâlde sonsuza kadar yeniden teslim edilir ve arkasındaki her şeyi bloklar. RabbitMQ bunu bir dead-letter exchange (DLX) ile çözer: reddedilen veya süresi dolan mesajlar, incelenmek üzere bir bekletme kuyruğuna yönlendirilir. SQS aynısını redrive policy ve maxReceiveCount ile yapar. Dead-letter mekanizmasını sınırlı retry ve backoff ile eşleştirin ve DLQ derinliğine alarm kurun — büyüyen bir dead-letter kuyruğu bir olaydır ve önerdiğimiz izleme stack'lerinin herhangi biri bunu ucuza görünür kılabilir.

RabbitMQ vs Kafka vs SQS

RabbitMQ akıllı bir broker'dır: zengin yönlendirme, mesaj başına acknowledgement, öncelikler, düşük gecikmeli iş kuyrukları ve RPC desenleri. Tüketilen bir mesaj artık yoktur. Kendi işlettiğiniz servisler arasında görev dağıtımı ve karmaşık yönlendirme için onu seçin.

Kafka bir kuyruk değil, dağıtık ve replike edilmiş bir log'dur. Mesajlar yapılandırılan süre boyunca saklanır ve tekrar oynatılabilir; consumer group'lar kendi offset'lerini takip eder; sıralama partition başına garanti edilir, dolayısıyla key bazında sıralama ölçeklenir. Event streaming, event sourcing ve birden fazla bağımsız consumer'lı yüksek hacimli pipeline'lar için onu seçin — ve operasyonel ağırlığı ya da bir managed servis için bütçe ayırın.

Amazon SQS tamamen yönetilen bir kuyruktur: fiilen sınırsız throughput'lu at-least-once standart kuyruklar ya da daha düşük throughput'la sıralama ve deduplication gerektiğinde FIFO kuyruklar. Yönlendirme katmanı yoktur — fanout için SNS veya EventBridge ile eşleştirin. AWS üzerinde çalışıyorsanız ve ihtiyacınız kuyruk biçimliyse, işletilecek bir broker olmadığı için SQS pragmatik varsayılandır.

Kısa versiyonu: bir kez işlenen komutlar ve arka plan işleri için kuyruk (RabbitMQ, SQS); birden fazla consumer'ın okuduğu veya tekrar oynattığı event'ler için log (Kafka) kullanın. Bu katmanı doğru kurmak — kalıcılık ayarları, idempotent consumer'lar, dead-letter mekanizması, alarmlar — tam da DevOps mühendislik ekibimizin teslimat pipeline'larına ve production platformlarına inşa ettiği türden bir temeldir.

Bunu production'da mı çalıştırıyorsunuz? AWS Yönetilen Hizmetler ekibimiz böyle ortamları 7/24 işletiyor — izleme, olay müdahalesi, yama ve maliyet kontrolü, ismen bildiğiniz kıdemli mühendislerle, aylık €3.000'den başlayan fiyatlarla.

Etiketler: #MesajKuyruğu #RabbitMQ #Kafka #Mikroservisler