Mikroservis ve asenkron mimarilerde mesaj kuyrukları: RabbitMQ ve Apache Kafka arasındaki farklar, performans kriterleri ve doğru seçim kılavuzu burada.
Hızlı Özet (TL;DR)
Mikroservis mimarilerinde, kurumsal ERP entegrasyonlarında ve endüstriyel IoT (IIoT) veri toplama sistemlerinde servislerin birbiriyle doğrudan senkron (HTTP/REST veya gRPC) konuşması, tek bir alt servis yavaşladığında tüm sistemin kilitlendiği kaskat çöküşlere (Cascading Failures) yol açar. Mesaj aracıları (Message Brokers) ve olay akış platformları, üretici (Producer) ile tüketici (Consumer) servisleri birbirinden ayırarak (Decoupling) asenkron esneklik sağlar. RabbitMQ; karmaşık yönlendirme (Routing), mesaj önceliklendirme, gecikmeli görev yürütme ve anında teslimat için ideal bir “akıllı komisyoncu” (Smart Broker / Dumb Consumer) iken; Apache Kafka ise saniyede yüz binlerce telemetri ve işlem olayını sıralı olarak diske yazıp saklayan, geriye dönük tekrar okunabilen (Replayable) bir “dağıtık olay günlüğü (Distributed Commit Log)” platformudur.
Senkron (REST/HTTP) İletişimin Mikroservis ve Üretim Sahasındaki Kırılganlığı
Bir üretim tesisinde barkodlu depo terminalinden “Üretim Siparişi Tamamlandı” butonuna basıldığını düşünelim. Eğer arka plandaki yazılım senkron çalışıyorsa; ana servis sırasıyla Stok Servisini, Muhasebe/E-İrsaliye Servisini, Kalite Kontrol Servisini ve Müşteri Bildirim (SMS/E-posta) Servisini HTTP üzerinden çağırıp hepsinin yanıt vermesini bekler. O anda GİB E-İrsaliye entegratörü veya SMS sağlayıcısı 15 saniye gecikme yaşarsa, depo personelinin elindeki terminal ekranı donar; aynı anda 50 operatör işlem yaptığında ise sunucunun bağlantı havuzu (Thread Pool) tükenerek tüm fabrika yazılımı çöker.
Asenkron Mesajlaşma ve Geri Basınç (Backpressure) Yönetimi
Araya RabbitMQ veya Apache Kafka gibi asenkron bir mesajlaşma katmanı konulduğunda; ana servis yalnızca "UretimTamamlandi" olayını 2 milisaniye içinde kuyruğa bırakır ve operatöre anında “İşlem Başarılı” yanıtı döner. Arka plandaki alt servisler kendi işlem kapasiteleri (Throughput) ölçüsünde mesajları kuyruktan çekip işler. Herhangi bir alt servis (örneğin fatura servisi) bakım nedeniyle 1 saat kapalı kalsa dahi mesajlar kuyrukta güvenle birikir (Buffering) ve servis ayağa kalktığında tek bir veri bile kaybolmadan sırayla işlenir.
Mimari Karşılaştırma Matrisi: RabbitMQ vs Apache Kafka
Projenizin veri hacmine, mesaj ömrüne ve yönlendirme karmaşıklığına göre doğru altyapıyı seçebilmeniz için RabbitMQ ve Apache Kafka’nın mühendislik farkları aşağıdaki tabloda karşılaştırılmıştır:
| Değerlendirme Kriteri | RabbitMQ (Geleneksel Mesaj Kuyruğu) | Apache Kafka (Dağıtık Olay Akış Platformu) |
|---|---|---|
| Temel Mimari Model | Kuyruk tabanlı (Smart Broker / Dumb Consumer) | Dağıtık eklemeli kütük (Dumb Broker / Smart Consumer) |
| İletişim Protokolü | AMQP 0-9-1, AMQP 1.0, MQTT, STOMP | Kafka Özel İkili Protokolü (TCP üzerinde Binary Protocol) |
| Mesaj Teslim Yaklaşımı | Push (İtme): Broker mesajı tüketiciye主动 olarak iter (prefetch ile) | Pull (Çekme): Tüketici kendi hızına göre broker’dan veri çeker |
| Mesaj Saklama Politikası | Geçici (Transient/Persistent): Tüketici ACK gönderdiği anda silinir | Kalıcı (Retention): Okunsa bile belirlenen süre (Örn: 7–30 gün) diskte kalır |
| Geriye Dönük Okuma (Replay) | Mümkün değildir; işlenen mesaj kuyruktan yok olur | Mümkün: Offset sıfırlanarak geçmişteki tüm olaylar baştan okunabilir |
| Mesaj Sıralama Garantisi | Tekil kuyruk ve tekil tüketici bazında FIFO garantisi | Partition (Bölüm) anahtarı (Key) bazında kesin sıralama garantisi |
| Yönlendirme (Routing) | Çok Zengin: Direct, Topic, Fanout, Headers Exchange kuralları | Temel: Yalnızca Topic ve Partition anahtarına göre dağıtım |
| Mesaj Önceliklendirme | Destekler (Priority Queues): VIP/Acil işler kuyruğun en önüne geçebilir | Desteklemez: Tüm mesajlar kütüğün sonuna (Append-only) sırayla yazılır |
| Veri Akış Hızı (Throughput) | Saniyede 20.000 – 50.000 mesaj (Orta/Yüksek hacim) | Saniyede 500.000 – 1.000.000+ mesaj (Ultra yüksek hacim) |
RabbitMQ Mimarisi: Exchange Türleri, ACK/NACK ve Dead Letter Queue
Erlang diliyle geliştirilen RabbitMQ, mesajın kimden gelip hangi kurallara göre hangi kuyruklara düşeceğini merkezde yöneten son derece esnek bir yönlendirme motoruna sahiptir. Üretici (Producer) mesajı hiçbir zaman doğrudan kuyruğa (Queue) göndermez; önce Exchange (Santral) katmanına teslim eder. Exchange, tanımlı bağlama kurallarına (Bindings) ve yönlendirme anahtarına (Routing Key) bakarak mesajı ilgili kuyruklara kopyalar:
- Direct Exchange: Yönlendirme anahtarı tam eşleşen kuyruğa mesajı iletir (Örn:
fatura.olustur->FaturaKuyrugu). - Fanout Exchange: Gelen mesajı kendisine bağlı tüm kuyruklara koşulsuz olarak yayınlar (Broadcast).
- Topic Exchange: Joker karakterlerle (
*ve#) desen eşleştirmesi yapar. Örneğinfabrika.hat1.cnc.alarmanahtarıyla atılan bir mesaj; hemfabrika.*.cnc.*dinleyen bakım kuyruğuna hem defabrika.#dinleyen merkezi log kuyruğuna aynı anda düşer. - Headers Exchange: Yönlendirme anahtarı yerine mesajın HTTP benzeri başlık (Header) niteliklerine bakarak karar verir.
Güvenilir Teslimat, Prefetch Limit ve Ölü Mesaj Kuyruğu (DLQ)
RabbitMQ’da tüketici bir mesajı aldığında işlem başarılıysa Basic.Ack (Onay) gönderir ve mesaj silinir. Eğer veritabanı hatası veya bozuk veri nedeniyle işlem başarısız olursa tüketici Basic.Nack veya Basic.Reject göndererek mesajı Dead Letter Exchange / Dead Letter Queue (DLQ - Ölü Mesaj Kuyruğu) adı verilen karantina kuyruğuna yönlendirir. Ayrıca tüketicinin belleğinin taşmaması için Basic.Qos (Prefetch Count) ayarı (örneğin prefetch = 10) yapılarak bir işçiye aynı anda en fazla 10 onaylanmamış mesaj gönderilmesi garanti altına alınır.
Apache Kafka Mimarisi: Partitioning, Zero-Copy ve KRaft Konsensüsü
LinkedIn tarafından geliştirilip Apache Vakfı’na devredilen Kafka, geleneksel bir mesaj kuyruğundan ziyade dağıtık, bölümlenmiş ve çoğaltılmış bir olay günlüğüdür (Distributed Commit Log). Kafka’nın saniyede milyonlarca mesajı tek bir sunucu kümesinde darboğaz yaşamadan işleyebilmesinin arkasında üç temel işletim sistemi ve donanım optimizasyonu yatar:
1. Ardışık Disk Yazımı (Sequential Disk I/O) ve Sayfa Önbelleği (Page Cache)
Mekanik veya SSD disklerde yavaş olan işlem rastgele (Random) adreslere yazmaktır; dosyanın en sonuna ardışık ekleme yapmak (Append-Only Log) RAM hızına yakın bir performans sunar. Kafka gelen her mesajı doğrudan disk üzerindeki bölüm (Partition) dosyasının en sonuna ekler ve işletim sisteminin çekirdek Page Cache belleğini doğrudan kullanarak JVM çöp toplama (Garbage Collection) gecikmelerinden kaçınır.
2. Sıfır Kopyalama (Zero-Copy / sendfile Sistem Çağrısı)
Geleneksel uygulamalarda diskteki bir veri ağdan gönderilirken Disk -> OS Kernel Buffer -> Uygulama Belleği (User Space) -> Socket Buffer -> Ağ Kartı (NIC) şeklinde 4 kez kopyalanır. Kafka ise Linux çekirdeğinin sendfile() sistem çağrısını (Zero-Copy) kullanarak veriyi uygulama katmanına hiç çıkarmadan doğrudan Disk Önbelleğinden Ağ Kartı (NIC) tamponuna DMA (Direct Memory Access) ile aktarır.
3. Partition (Bölüm), Offset ve Consumer Group Ölçeklenmesi
Kafka’da her konu başlığı (Topic) birden fazla Partition (Bölüm) parçasına ayrılır ve her mesaja artan bir sıra numarası (Offset: 0, 1, 2, 3…) verilir. Mesajın hangi okuma sırasına (Offset) kadar işlendiğini Kafka değil, Consumer Group (Tüketici Grubu) takip eder. Bu sayede:
- Aynı veriyi Üretim Analitik Servisi gerçek zamanlı okurken, Veri Ambarı (ETL) Servisi gece yarısı gelip kaldığı Offset’ten itibaren okuyabilir.
- Yeni geliştirilen bir yapay zeka anomali tespit servisi devreye alındığında, kendi Offset değerini
0’a çekerek son 7 günün tüm fabrika telemetri verisini baştan sona tekrar oynatabilir (Event Replay).
Endüstriyel Sahada Hibrit Kullanım: Hangi Senaryoda Hangisi Seçilmeli?
Büyük ölçekli kurumsal mimarilerde RabbitMQ ve Apache Kafka birbirinin düşmanı değil, farklı katmanlarda birlikte çalışan tamamlayıcı teknolojilerdir:
[CNC / PLC Sensörleri] ---> (Apache Kafka: Saniyede 100K Telemetri & Event Log) ---> [MES / Analitik / AI]
|
(Anomali / İş Emri Tetiklendi)
v
[SMS / E-Posta / PDF Rapor / ERP İşçileri] <--- (RabbitMQ: Görev Dağıtımı, Öncelik & Retry)
RabbitMQ Tercih Edilmesi Gereken Senaryolar
- Arka Plan İş Kuyrukları (Background Jobs): PDF teklif/fatura üretimi, toplu e-posta/SMS gönderimi, görsel işleme ve dış API (E-Fatura, Kargo, Banka) çağrıları.
- Öncelikli ve Gecikmeli İşler: “Standart müşterilerin raporları sırayla üretilsin ama Yönetim Kurulu veya Acil Savunma Siparişi geldiğinde kuyruğun en önüne (
x-max-priority) geçsin” veya “Siparişten 30 dakika sonra ödeme kontrolü tetiklensin” senaryoları. - Karmaşık Mikroservis Komutları (RPC / Command Pattern): Hızlı doğrulama, işlem sonrası mesajın silinmesi ve düşük donanım kaynağı (RAM/Disk) tüketimi istenen projeler.
Apache Kafka Tercih Edilmesi Gereken Senaryolar
- Endüstriyel IoT ve Canlı Saha Telemetrisi: Fabrikadaki yüzlerce tezgahtan CNC ve Makine Veri Toplama kapsamında milisaniyede bir akan sıcaklık, titreşim, spindle yükü ve enerji tüketimi verilerinin kayıpsız toplanması.
- Event Sourcing ve CQRS Mimarileri: Sistemdeki her durum değişikliğinin değiştirilemez tarihsel bir olay kütüğü olarak saklanması ve Ortak Dosya Sunucusu ve Yedekleme politikalarıyla uyumlu uzun süreli denetim izi (Audit Log) oluşturulması.
- Gerçek Zamanlı Akış İşleme (Stream Processing): Apache Flink veya Kafka Streams ile akan veri üzerinde anlık OEE hesaplama ve siber güvenlik log korelasyonu (SIEM veri hattı).
Endüstriyel sahalarda PLC ve sensör verilerini işleyen gerçek zamanlı veri akış mimarileri için Özel ERP & CRM ve İmalat Çözümleri ve yüksek erişilebilirlikli kurumsal yazılım uzmanlığımız için Özel Yazılım Geliştirme sayfalarımızı inceleyebilirsiniz.
Sıkça Sorulan Sorular
Saniyede 500 mesaj geçen orta ölçekli bir kurumsal projede Kafka kullanmak doğru mudur?
Saniyede birkaç yüz veya birkaç bin mesajın geçtiği, mesajların işlendikten sonra tekrar okunmasına (Replay) ihtiyaç duyulmayan standart kurumsal uygulamalarda Apache Kafka kurmak gereksiz operasyonel karmaşıklık ve sunucu maliyeti (en az 3 düğümlü küme ve yüksek RAM/Disk ihtiyacı) yaratır. Bu ölçekteki görev kuyruğu ve mikroservis iletişimi ihtiyaçlarında RabbitMQ çok daha düşük kaynak tüketimiyle, çok daha esnek yönlendirme ve hata yönetimi (DLQ/Retry) imkanları sunar.
Apache Kafka’da aynı Partition içindeki bozuk bir mesaj (Poison Pill) tüm akışı durdurursa ne yapılır?
Kafka’da bir Partition içindeki mesajlar sırayla (Offset bazlı) okunduğu için, serileştirme hatası içeren bozuk bir mesaj (Poison Pill) tüketicinin sürekli çöküp aynı mesajı tekrar okumasına yol açabilir. Bu durumu engellemek için tüketici tarafında Dead Letter Topic (DLT) deseni uygulanır: Belirli sayıda (örneğin 3 kez) işlenemeyen hatalı mesaj, ana akışı tıkamaması için hata detaylarıyla birlikte ayrı bir hatali-mesajlar-dlt konusuna (Topic) yazılır ve ana Partition’daki Offset bir ileriye kaydırılarak üretime devam edilir.
RabbitMQ’da sunucu elektriği kesilirse veya yeniden başlarsa kuyruktaki mesajlar silinir mi?
Varsayılan ayarlarda kuyruklar geçici (Transient) oluşturulduysa RAM’de tutulur ve sunucu kapandığında silinir. Mesaj kaybını tamamen önlemek için üç adım birlikte uygulanmalıdır: Kuyruk tanımı kalıcı (durable: true) yapılmalı, üretici mesajı gönderirken teslimat modu kalıcı (delivery_mode: 2 / persistent) olarak işaretlenmeli ve mesajın diske yazıldığından emin olmak için Publisher Confirms mekanizması aktif edilmelidir. Ayrıca RabbitMQ 3.8+ sürümlerinde klasik aynalı kuyruklar yerine Raft konsensüs tabanlı Quorum Queues kullanılarak sunucu çöküşlerine karşı tam veri güvenliği sağlanır.