Broker, Exchange, Queue, Binding kavramları
Exchange türleri (Direct, Fanout, Topic, Headers) ve kullanım senaryoları
Routing Key ve Binding Key
Mesaj yönlendirme örnekleri

RabbitMQ, AMQP (sürüm 0.9.1) protokolünü uygulayan bir message broker yazılımıdır. AMQP’nin tanımladığı kavramları (Exchange, Queue, Binding, vb.) kendi mimarisinde kullanır ve geliştirir. “Broker” terimi de genelde, AMQP protokolünü uygulayan sunucu tarafı yazılımları için kullanılır (RabbitMQ, Apache Qpid, vb.).

“Broker, Exchange, Queue, Binding ve Routing Key gibi kavramlar aslında AMQP’nin tanımladığı temel bileşenlerdir. RabbitMQ, AMQP 0.9.1 protokolünü uygulayan en yaygın brokerlardan biri olduğu için, bu bileşenleri RabbitMQ’nun temel bileşenleri olarak da görebiliriz.”

Simdi bu bileşenleri detaylıca ele alalım.

Broker

• Broker, RabbitMQ sunucusunun kendisidir.
• Bir nevi “postane” gibi çalışır: mesajları alır, uygun yerlere yönlendirir ve saklar.
• ·RabbitMQ Broker’ı, gelen mesajları Exchange bileşenine iletir, ardından Exchange de mesajların hangi kuyruğa (ya da kuyruklara) gideceğine karar verir.
• Broker; kullanıcı yönetimi, yetkilendirme, eklenti (plugin) yönetimi gibi işlemleri de yürütür.

Exchange

• Mesajların hangi kuyruğa gideceğine karar veren bileşendir.
• Üretici (producer) uygulamalar, mesajlarını Exchange’e gönderir. Bu aşamada bir Routing Key iletilebilir.
• Exchange yapısı, gelen mesajı önceden tanımlanmış kurallara göre bir veya birden fazla kuyruğa yönlendirir (ya da hiç yönlendirmeyerek mesajı yok sayabilir).
• Exchange’lerin temel görevi, Routing Key, Binding Key ve kendi türüne (Direct, Fanout, Topic, Headers) özgü kural setlerini kullanarak mesajı uygun yere ulaştırmaktır.

Queue

• Mesajların saklandığı yerdir.
• RabbitMQ’da mesajın gerçekten “tutulduğu” (persist edildiği veya hafızada beklediği) tek yapı Queue’dur.
• Bir uygulama (consumer/tüketici) mesajları çekmek istediğinde, kuyruklar üzerinden bu mesajları alır.
• Kuyruklar, tanımlanma biçimlerine göre çeşitli özellikler kazanabilir:
  — Durable (kalıcı) veya Transient (geçici)
  — Exclusive: Sadece bu kuyruğu tanımlayan bağlantıya özel
  — Auto-delete: Eğer bağlı consumer kalmadığında kendi kendini silen kuyruk
  — TTL, Mesaj boyutu limiti vb.

Binding

• Binding, Exchange ile Queue arasındaki “eşleştirmeyi” tanımlar.
• Kısaca, “Bu kuyruk şu Exchange’den gelen şu türdeki mesajları alsın.” şeklindeki kuraldır.
• Binding tanımlanırken çoğu zaman bir Binding Key de verilir. Bu sayede Exchange, Routing Key ile Binding Key arasındaki eşleşmeye bakarak mesajın hangi kuyruk(lar)a gideceğine karar verir.

Exchange Türleri (Direct, Fanout, Topic, Headers)

RabbitMQ’da en çok kullanılan Exchange türleri şunlardır:

Direct Exchange

• Mesajın yönlendirilmesi: Mesajın yönlendirileceği kuyruğu, Routing Key’e tam uyum ile belirler.
• Routing Key kullanımı: Üretici uygulama mesajı bir Routing Key ile gönderir. Eğer bir queue, Binding Key olarak bu Routing Key’i tanımlamışsa, mesaj o kuyruk(lar)a gider.
• Eşleşme mantığı: Birebir eşleşme (exact match) mantığı esastır. Routing Key ile Binding Key tam uyumlu değilse mesaj iletilmez.

Kullanım Senaryosu:
Direct Exchange şu gibi durumlarda sıkça kullanılır:

Belirli bir işlem tipine ait mesajların yönlendirilmesi:
· Örneğin:
payment.created adlı Routing Key ile sadece ödeme oluşturma mesajlarını dinleyen bir kuyruğun beslenmesi.

Bildirim sistemleri:
· E-posta, SMS veya push bildirimlerini farklı sistemlere yönlendirmek.
· Örneğin:
notification.email → E-posta bildirim kuyruğu.
notification.sms → SMS bildirim kuyruğu.

Fanout Exchange

• Yayın Mantığı: Broadcast (yayın) mantığı ile çalışır. Mesajları, Routing Key veya Binding Key dikkate almadan, exchange’e bağlı tüm kuyruklara gönderir.
• Routing Key Gereksizdir: Bu exchange türünde, mesaj yönlendirmesi için Routing Key kullanılmaz.
• Tüm Bağlı Kuyruklara Mesaj Dağıtımı: Mesaj, exchange’e bağlı olan tüm kuyruklara kopyalanarak iletilir.

Kullanım Senaryosu:
Fanout Exchange şu durumlarda sıkça kullanılır:

Gerçek Zamanlı Bildirim ve Yayın Sistemleri:
· Örneğin:
Bir kullanıcı uygulamada oturum açtığında, oturum açma bilgisi birden fazla servise gönderilebilir (log sistemi, analitik sistemi, bildirim sistemi vb.).

Duyuru ve Uyarılar:
· Tüm sistem bileşenlerini ilgilendiren bir duyuru veya kritik bir uyarı paylaşımı için.
· Örneğin: “Sunucu bakımda” bildirimi.

Event-Driven Mimari:
· Bir olay gerçekleştiğinde (örneğin: sipariş oluşturma), bu olayın detaylarının farklı servislere dağıtılması.
· Örneğin:
Sipariş servisi sipariş detaylarını yayınlar ve bağlı olan ödeme, bildirim ve envanter servisleri bu bilgiyi alır.

Yedekleme ve Eş Zamanlı İşleme:
· Bir veri parçasının birden fazla yerde aynı anda işlenmesi gerektiğinde.
· Örneğin:
Veri hem bir işlem kuyruğuna hem de bir arşiv kuyruğuna yönlendirilir.

Topic Exchange

• Esnek Routing Key Kullanımı: Routing Key’ler, joker karakterler kullanılarak esnek bir şekilde eşleştirilir.
• Joker Karakterler:
• * (Yıldız): Routing Key’in tek bir segmentini temsil eder. Örneğin, payment.*.us → ortadaki kısmı esnek.
• # (Diyez): Routing Key’in bir veya daha fazla segmentini temsil eder. Örneğin, #.created → herhangi bir yerde .created ile biten her şey.

Örnek:

Routing Key: “payment.created.us”
· Mesaj bu anahtar ile gönderilir.\

Binding Key Örnekleri:
· payment.created.*: İki segmenti sabit, üçüncü segment esnek. (ör. payment.created.us, payment.created.eu)
· payment.*.us: Birinci ve üçüncü segment sabit, ortadaki esnek. (ör. payment.created.us, payment.failed.us)
· #.created: Herhangi bir başlangıç, .created ile bitmeli. (ör. payment.created, order.created)

Kullanım Senaryosu:

Log Mesajlarını Ayırmak:
· Logları türlerine veya kaynaklarına göre kategorize etmek.
· Örneğin:
log.info.api: API bilgi logları.
log.error.database: Veritabanı hata logları.
Binding Key: log.*.api → API loglarını alır.

Bölgesel İşlem Yönetimi:
· Farklı coğrafyalardaki işlemleri ayırmak.
· Örneğin:
· payment.created.us: ABD ödemeleri.
· payment.created.eu: Avrupa ödemeleri.
· Binding Key: payment.*.us → ABD işlemlerini işler.

Headers Exchange

• Routing Key Kullanmaz: Mesaj yönlendirmesi, header bilgileri üzerinden yapılır.
• Mantıksal Kurallar:
  · Binding sırasında kullanılan x-match özelliği ile mantıksal kurallar tanımlanır:
  x-match: all (AND): Tüm header eşleşmeleri sağlanmalıdır.
  x-match: any (OR): Herhangi bir header eşleşmesi yeterlidir.

Kullanım Senaryosu:

Rol Tabanlı İşlemler:
· Kullanıcı veya sistem rollerine göre mesajların ayrıştırılması.
· Örneğin:
Header: X-Role: Admin
Mesajlar sadece admin işlemlerini yöneten kuyruğa gider.

Dosya İşleme ve Gönderimi:
· Gönderilen dosya türüne göre işlemleri ayrıştırmak.
· Örneğin:
Header: X-FileType: PDF, X-FileType: Word, X-FileType: Excel
PDF dosyaları bir kuyruğa, Word dosyaları başka bir kuyruğa, Excel dosyaları ise farklı bir kuyruğa yönlendirilir.

Routing Key ve Binding Key

• Routing Key, üreticinin Exchange’e mesaj gönderirken belirttiği bir “etiket”tir.
• Binding Key, Exchange ile Queue arasındaki bağlantıda tanımlanır.
• Exchange, Routing Key ile Binding Key’i karşılaştırır ve eşleşme kurallarına göre mesajın hangi kuyruğa gideceğine karar verir.
• Direct ve Topic Exchange türlerinde bu eşleşme kritiktir. Fanout Exchange, bu anahtarları dikkate almaz.

Not: Headers Exchange’de, Routing Key yoktur; eşleşme, mesaj headler’larındaki tanımlara göre yapılır.

“RabbitMQ Mimari Standartları” bölümünde:

Broker, RabbitMQ sunucusunun kendisidir; tüm mesaj alım, yönlendirme ve saklama işlemleri onun çatısı altında gerçekleşir.

Exchange, mesajın varış noktasını belirleyen ana bileşendir. Türüne göre mesajlar farklı eşleştirme algoritmalarıyla kuyruğa iletilir.

Queue, mesajların gerçekten durduğu yerdir ve tüketiciler (consumer) buradan mesajları alır.

Binding, Exchange ile Queue arasındaki bir “eşleşme” kuralıdır. Routing Key ve Binding Key mantığına göre mesajın nereye gideceği netleşir.

Exchange Türleri farklı kullanım senaryolarına göre seçilmelidir. Direct, Fanout, Topic ve Headers, en yaygın ve güçlü yönlendirme mekanizmalarını oluşturur.