TEMEL
RabbitMQ Nedir & Ne Zaman Kullanılır
Hemen çalışan bir şey görmek istiyorsan bu sıraya git:
5 Dakikada Başla (Quick Start Path)
0. Docker ile tek RabbitMQ başlat:
# docker-compose.yml (single-node, development)
services:
rabbitmq:
image: rabbitmq:4.3-management
hostname: rabbitmq
ports:
- "5672:5672" # AMQP
- "15672:15672" # Management UI
environment:
RABBITMQ_DEFAULT_USER: guest
RABBITMQ_DEFAULT_PASS: guest
healthcheck:
test: rabbitmq-diagnostics check_port_connectivity
interval: 10s
timeout: 5s
retries: 3
docker compose up -d
# Management UI: http://localhost:15672 (guest/guest)
- İlk mesajını gönder → .NET Entegrasyonu (Raw Client minimal setup)
- Consumer yaz → .NET (BackgroundService consumer)
- Güvenli yap → Reliability (Publisher Confirms + Consumer Ack)
- Cluster kurmak istersen → Clustering (3-node docker-compose)
Quick start sonrasında Temel Kavramlar ve Exchange Tipleri konularını okuyun — "neden böyle" sorusunun cevabını bu konularda bulabilirsiniz.
📖 Terimler Sözlüğü
Tüm terimleri göster (18 terim)
| Terim | Ne Demek | Benzetme |
|---|---|---|
| Broker | Mesajları alan, saklayan ve ileten aracı sunucu | Postane |
| Producer | Mesaj gönderen uygulama | Mektup yazan kişi |
| Consumer | Mesaj alan ve işleyen uygulama | Mektubu okuyan kişi |
| Exchange | Mesajları kurallara göre queue'lara yönlendiren bileşen | Postanedeki sıralama masası |
| Queue | Mesajların sırayla bekletildiği kuyruk | Posta kutusu |
| Binding | Exchange → Queue arasındaki yönlendirme kuralı | "Bu adrese giden mektupları şu kutuya koy" |
| Routing Key | Mesajın hangi queue'ya gideceğini belirleyen etiket | Zarfın üstündeki adres |
| Ack (Acknowledge) | Consumer'ın "mesajı aldım, işledim" demesi | İmza karşılığı teslim |
| Nack | Consumer'ın "mesajı işleyemedim" demesi | Geri iade |
| DLX (Dead Letter Exchange) | İşlenemeyen mesajların gönderildiği "çöp kutusu" exchange | İade edilen mektupların gittiği depo |
| TTL (Time To Live) | Mesajın maximum yaşam süresi (ms cinsinden) | Son kullanma tarihi |
| Durable | Broker restart'ta hayatta kalan (diske yazılan) | Kalıcı depolama |
| Prefetch | Consumer'a aynı anda en fazla kaç mesaj gönderileceği | "Bir seferde max 5 paket taşı" |
| Quorum Queue | Birden fazla node'a kopyalanan, güvenli queue tipi | Yedekli kasa (3 kopyadan 2'si onaylarsa tamam) |
| Raft | Quorum queue'ların kullandığı consensus algoritması | Oylama sistemi (çoğunluk karar verir) |
| WAL (Write-Ahead Log) | Veri yazılmadan önce tutulan log (crash recovery) | Günlük defteri (her şeyi yaz, sonra uygula) |
| Idempotent | Aynı işlemi 2 kez yapsan bile sonuç değişmeyen | ATM'den 2 kez "çek" bassan da 1 kez çekilir |
| Publisher Confirm | Broker'ın "mesajını aldım" dediği onay mekanizması | Kargo takip numarası |
| Cluster | Birlikte çalışan birden fazla RabbitMQ node'u | Şube ağı (hepsi aynı sisteme bağlı) |
| Federation | Farklı datacenter'lar arası mesaj kopyalama | Şehirler arası kargo hattı |
Versiyon Uyumluluk Matrisi
| Özellik | Min Versiyon | Notlar |
|---|---|---|
| Quorum Queues | 3.8+ | Classic mirrored queue yerine |
| Streams | 3.9+ | Kafka-like append-only log, Super Streams (4.0+), SAC for streams (4.0+) |
| OAuth 2.0 auth | 3.8+ | JWT token authentication |
| Classic mirrored kaldırıldı | 4.0+ | Sadece quorum queue |
| Khepri metadata store | 4.0+ | Mnesia yerine (opsiyonel) |
| AMQP 1.0 native | 4.0+ | Eklenti gerektirmez |
| MQTTv5 support | 4.1+ | IoT senaryoları |
RabbitMQ bir mesaj kuyruğu sistemidir — servislerin birbirine doğrudan bağlanmadan haberleşmesini sağlar. Gönderen "mesajı bırakır", alıcı "hazır olduğunda alır". Bu sayede servisler birbirini beklemez, biri çökse bile mesaj kaybolmaz.
📖 Teknik detay: RabbitMQ, AMQP protokolü üzerinde çalışır ve Erlang/OTP ile yazılmıştır. Bu detaylar günlük kullanımı etkilemez ama hata ayıklama ve performans tuning sırasında bilmek faydalıdır.
Ne Zaman Kullan / Kullanma
| Senaryo | RabbitMQ Kullan | Kullanma | Gerçek Hayat |
|---|---|---|---|
| Servisler arası asenkron iletişim | Task queue, work distribution | E-ticaret: sipariş onayı → fatura PDF üretimi | |
| Event broadcasting (fan-out) | Birden fazla consumer'a aynı event | SaaS: kullanıcı kaydı → email + analytics + onboarding | |
| Rate limiting / Load leveling | Spike'ları queue'da tamponla | Fintech: ani ödeme spike'ı → işlem sıraya alınır | |
| High-throughput event streaming | Kafka/Redpanda daha uygun | Clickstream: saniyede 500K+ event log | |
| Request-Response (sync) | gRPC/HTTP daha uygun | API Gateway → downstream service çağrısı | |
| Long-term event replay | Kafka log retention daha uygun | Audit log: 90 gün geriye dönük replay | |
| Routing karmaşıklığı yüksek | Exchange + binding flexibility | Multi-tenant: tenant.region.event routing |
Gerçek hayat senaryosu: Bir e-ticaret platformunda sipariş onaylandığında (ödeme alındı, stok ayrıldı — bu kısım senkron), Order Service bir
OrderConfirmedevent'i RabbitMQ'ya publish eder. Bildirim servisi email gönderir, fatura servisi PDF üretir, loyalty servisi puan ekler. Bu side-effect'ler birbirinden bağımsızdır — biri çökse bile sipariş geçerlidir, mesajlar queue'da bekler.
Dikkat: RabbitMQ bir event store değildir. Mesajlar consume edilip ack'landıktan sonra silinir. Replay ihtiyacı varsa Streams özelliğini veya Kafka'yı değerlendirin.
RabbitMQ vs Kafka — Kısa Karşılaştırma
| Kriter | RabbitMQ | Kafka |
|---|---|---|
| Model | Smart broker / dumb consumer | Dumb broker / smart consumer |
| Mesaj semantiği | Queue (consume edilince silinir) | Log (retention ile tutulur) |
| Routing | Exchange/binding ile esnek routing | Topic/partition — sınırlı |
| Throughput | ~50K-100K msg/s (single queue) | ~1M+ msg/s (partitioned) |
| Latency | Düşük (~ms) | Düşük-orta |
| Replay | Yok (Streams hariç) | Var (offset-based) |
| Protokol | AMQP 0-9-1, AMQP 1.0, MQTT, STOMP | Kafka protocol |