1. Genel RabbitMq Yapısı ve Exchange Typelar

1.MESSAGE QUEUE

Message queue servisler arası data alışverişini daha kolay, loosely coupled ve fault tolerance olarak yapmamızı sağlayan bir yapıdır. Burada data dediğimiz bir process taskının başladığını belirten bir data, bir taskın başka bir uygulama tarafından bitirildiğini belirten bir data ya da bir servisin bir processi bitirebilmesi için gerekli olan info olabilir.

1.1 Message Queueların Temel Mimarisi

Message queuenın genel mimarisi oldukça basittir. Producer, consumer ve datadan oluşur. Producer datayı queue’a bırakan consumer da queuedan alan taraftır. Data queueya konulduğu zaman enqueue olmuş, queuedan alındığı zaman da dequeue olmuş denilebilir.

2.MESSAGE BROKER

Message broker uygun mesajı uygun destinationa ileten bir merkez gibi düşünülebilir. Message brokerı kafamızda oturtabilmek için telefon hattı örneğini düşünebiliriz. Telefon ilk bulunduğu zaman yani ana santrallerin olmadığı zamanları düşünün. Mahalledeki evlerin birbirilerini arayabilmesi konuşabilmesi yani data transfer edebilmesi için her evden bir diğerine hat çekilmesi gerekirdi. Bu da dağınık ve couplingi yüksek bir yapı ortaya çıkarır. Daha sonralarda telefon santrallerinin gelmesiyle birlikte tüm evlerden sadece santrale hat çekilmesi yeterli oldu. Bir kişi bir yeri arayacağı zaman hat üzerinden santrale bağlanır yani data gönderir santral de o kişiyi uygun kişiyle konuşturur. Yani o servisin datasını uygun servise sent eder. Burada senaryomuzdaki santral message queuedır.

3. RABBITMQ GENEL MESSAGE AKIŞI

RabbitMq AMQP protokolünün bir implementasyonudur ve genel olarak  3 tane AMQP entitysi vardır. Bunlar Exchange, Binding, Queue. Bu entityler rabbitmqdaki genel akışı oluşturur.

Rabbitmq’da mesajı üretecek olan taraf producer ürettiği mesajı direkt olarak Queue’ya koymaz. Öncesinde Exchange’e iletir. Exchage’de bunu ilgili Queue’ya aktarır. Consumer da subscribe olduğu Queue üzerinden ilgili bilgiyi alır.

Queuelar message’ı ilgili Consumera ileteceği için doğru message’ın doğru queue’ya gitmesi önemlidir. Dolayısıyla Producer message’ı exchange’e bıraktığında exchange’in message’ı doğru queue’a iletmesi önemlidir. Bu da routing ve binding keyler ile sağlanır. Producer message’ını exchange’e bir routing key ile aktarır. Exchange de ilişkili olduğu queuelara bir binding key ile bağlıdır. Exchange aldığı message’ın routing keyini binding key ile kıyaslayarak ilgili queue’a gönderir. Bu olayın detaylarına da exchange type kısmında gireceğim.

Gönderilememe durumunda message tamamen queue’dan silinmez. Gönderilmezse ya yolda drop olur ya da re-sent bu da producer tarafından tanımlanır.

4. EXCHANGE TYPE’LAR

Message Attributes

Producer bir message’ı  exchange’e iletirken beraberinde Routing key ve header da iletir. Bu attributelar exchange tarafından doğru mesajın doğru queue’a aktarımı için kullanılır.

RabbitMqda routing işlemi için farklı exchange typeları vardır. Bunlar Default exchange, Direct Exchange, Fanout Exchange, Topic Exchange ve Header Exchange’dir.

Default exchange

Her yaratılan queue aynı routing key ve bindinge sahip olacak şekilde ve bu key ve binding de otomatik olarak queue adıyla  aynı olacak şekilde yaratılır. Bir mesaj bir queueya gidecek şekilde kurgulanır.Basit uygulamalar için kullanışlıdır.

Direct Exchange

Direct exchange’de yarattığımız queueların binding key’ini kendimiz tanımlarız ve routing işlemi için producerdan gelen message’ın routing key’i ile queue’nun binding key’i tam olarak eşleşmeli. Bu eşleşmenin gerçekleşmesi durumunda exchange ilgili mesajı doğru queue’ya yönlendirebilir.

Fanout Exchange 

Fanout exchange’de routing key’in hiç bir etkisi yoktur. Fanout exchange message kopyasını tüm queuelara dolayısıyla ilgili tüm consumerlara yollar. Hatta fanout exchange ile exchange’den exchange’e de yönlendirme yapabilrsin. Mesela, Direct exchangeden fanoutout exchange’ de veri de gönderebilirisin.

Topic excahange

Topic exchange de direct exchange’e benzer bir yapıya sahiptir. Farkı routing için routing key ve binding keyin direkt eşleşmesine ihtiyaç duymak yerine binding pattern kullanır.

Örneğin

Routing key :  red.

Binding key : red.green , red.blue

Header Exchange

Temelde direct exchange’ benzeyen ancak bir fark ile ayrılan bir yapı. Header exchange messageleri ilgili queuelara iletmek için routing key yerine message header kullanır. Message Header dediğimiz konsepti de bir key value seti gibi düşünebiliriz. Exchange tarafında da, message header ile binding header eşleşiyorsa routing işlemi gerçekleşir.