RabbitMQ, producer ve consumer uygulamalar arasında mesajları yönlendiren bir message broker’dır. Producer mesajı yayımlar; consumer mesajı alır ve uygulamanın işini yürütür. Arka plan işleri, servisler arası asenkron iletişim ve farklı alıcılara mesaj dağıtımı için kullanılabilir. Broker’ın görevi mesajı taşımaktır; uygulamanın iş işlemini doğru ve yalnız gereken sayıda yapması ayrıca tasarlanmalıdır.
Örneğin rapor oluşturma veya belge dönüştürme isteği kuyruğa bırakılabilir, worker işi daha sonra tamamlar. Celery’nin broker belgesi RabbitMQ desteğini açıklar. Farklı görev kütüphanelerinin aynı broker’ları desteklediği varsayılmamalıdır.
Exchange, queue ve consumer nasıl çalışır?
AMQP 0-9-1 modelinde temel akış producer → exchange → binding → queue → consumer şeklindedir. Binding, exchange ile queue arasındaki yönlendirme bağıdır. Exchange türüne göre routing key, binding veya header kurallarıyla mesaj sıfır, bir ya da birden fazla queue’ya yönlendirilebilir; her exchange türü routing key’i aynı şekilde kullanmaz. İşleme kapasitesini ise tüketici uygulaması ve arkasındaki bağımlılıklar sınırlar.
Kuyruğa eklemek, işlemin tamamlandığı anlamına gelmez. Kullanıcıya verilecek durum bilgisi, görev kimliği ve sonuç kaydı uygulama modelinin parçasıdır. Büyük dosyalar için dosyanın kendisi yerine kontrollü bir depodaki nesnenin referansını taşımak değerlendirilebilir.
Publisher confirms ve consumer acknowledgement
Resmi onay belgesi, iki ayrı güven sınırını açıklar:
- Publisher confirms: Üreticinin broker ile iletişimini kapsar; tüketicinin işini tamamladığını söylemez.
- Manual consumer acknowledgement: Consumer’ın teslimi işlediğini broker’a bildirmesidir; publisher confirm ile aynı mekanizma değildir. Uygulama bu onayı iş tamamlandıktan sonra vermelidir. Automatic acknowledgement modunda ise mesajın gönderilmesi başarılı teslim sayılabilir; bu, işin tamamlandığının kanıtı değildir.
Mesajın hiçbir kuyruğa yönlenmemesi de ayrıca ele alınmalıdır. Kullanılan protokol ve istemciye göre mandatory/return gibi mekanizmalarla yönlendirme sonucu izlenir. “Publish çağrısı hata vermedi” tek başına iş teslimi kanıtı değildir.
Quorum queue ve RabbitMQ cluster
Quorum queue, Raft tabanlı çoğaltılan kuyruk türüdür. Kuyruk üyelerinin çoğunluğu erişilebilir olmalıdır. Üç üyeli bir quorum queue, uygun yerleşimde bir üye kaybını karşılayabilir; üç broker kurulmuş olması her kuyruğun bu yerleşime sahip olduğunu göstermez.
Classic queue mirroring, RabbitMQ 4.0 ile kaldırılmıştır. Eski mirrored queue rehberleri yeni cluster tasarımına kopyalanmamalıdır. Kuyruk türü, üye dağılımı, istemci yeniden bağlantısı ve node bakım sırası birlikte planlanır.
Streams, kayıtların saklama süresi içinde yeniden okunabildiği ayrı bir veri yapısıdır. Görev kuyruğu ile aynı tüketim davranışına sahip değildir; replay gereksiniminde ayrıca değerlendirilir.
RabbitMQ mu Kafka mı?
Exchange tabanlı yönlendirme, worker’lara görev dağıtımı ve onay/yeniden teslim iş akışı belirginse RabbitMQ değerlendirilebilir. Olay geçmişi, partition sıralaması ve bağımsız tüketici gruplarının offset ile ilerlemesi baskınsa Apache Kafka karşılaştırmaya alınır.
Kararı yalnız saniyedeki mesaj sayısıyla vermeyin. Mesaj boyutu, saklama süresi, sıralama, yeniden okuma ve hata sonrası işleme kapsamı aynı koşullarda test edilmelidir. RabbitMQ Streams nedeniyle “RabbitMQ’da replay yok” genellemesi doğru değildir.
Yeniden teslim, retry ve dead-letter
Dayanıklılık rehberi, ağ ve node hatalarında tekrar teslim ihtimalini açıklar. Tüketici aynı mesajı yeniden aldığında çift fatura, çift bildirim veya çift stok düşümü oluşturmamalıdır.
- İş tamamlandıktan sonra uygun acknowledgement verilir.
- Retry sayısı ve bekleme davranışı sınırlandırılır; sürekli requeue döngüsü oluşturulmaz.
- İşlenemeyen mesajlar için dead-letter yolu, izleme ve kontrollü yeniden işleme süreci belirlenir. Dead-lettering de başarısız olabilir; varsayılan aktarım her koşulda kayıpsız değildir. Quorum queue’da at-least-once dead-lettering kullanılacaksa ilgili politika ve önkoşullar ayrıca doğrulanır.
- Prefetch ve worker sayısı, hedef veritabanının veya API’nin kapasitesine göre ayarlanır.
İşletim ve kurtarma kontrolü
Ready, teslim edilmeyi bekleyen; unacked, consumer’a teslim edilmiş fakat henüz onaylanmamış mesajları ifade eder. Bu sayılar, tüketici hızı, disk/bellek alarmları ve bağlantılar birlikte izlenir. Uçtan uca bekleme süresi gerekiyorsa uygulama timestamp’leri veya uygun ölçüm yöntemiyle ayrıca takip edilir. Kuyruk büyümesi her zaman broker’ın yavaş olduğu anlamına gelmez; tüketici veya bağımlı servis darboğazı araştırılır.
Vhost ve kullanıcı yetkileri uygulamalara göre ayrılır; yönetim erişimi sınırlandırılır ve TLS doğrulanır. Yedekleme belgesinde açıklanan definition dışa aktarımı, kuyruk içindeki mesajların yedeği değildir. Yapılandırma ve mesaj kurtarma kapsamları ayrı belgelenir; node kaybı, ağ kopması ve tüketicinin işlem ortasında kapanması pilotta sınanır.
