Rabbit MQ – Routing

Merhaba,

Bir önceki senaryoda publisher tarafından gönderilen bir mesajın birden çok kullanıcıya gönderilmesini incelemiştik.

https://www.rabbitmq.com/tutorials/tutorial-four-dotnet.html

Şimdi ise yalnızca “error” hata mesajlarını günlük dosyasına yönlendirme konusunda çalışma yapacağız. Yine de tüm günlük mesajlarını konsolda istersek yazdırabiliriz. Bunu da alıcı taraftaki düzenleme ile yapabiliriz.

Exchange tiplerinden bahsetmiştik, bu örnekte “direct” olanı kullanacağız. Exchange ve queue arasındaki ilişkiyi binding ile tanımlıyorduk, önceki örnekte de

channel.QueueBind(queue: queueName,
                  exchange: "logs",
                  routingKey: "");

bu şekilde bir kullanımı vardı. Kuyruk, “logs” isimli exchange tipinden gelen mesajlarla ilgileniyor bilgisini burada veriyorduk. Burada ek olarak bir routingKey parametresi verebiliriz, bu örnekte de bununla ilgili olacak.

channel.QueueBind(queue: queueName,
                  exchange: "direct_logs",
                  routingKey: "black");

Direct exchange

Mesajların önem derecelerine göre filtrelemeye izin verecek şekilde yönlendireceğiz. Örneğin, diske günlük mesajları yazan betiğin yalnızca kritik hataları almasını ve uyarı veya bilgi günlüğü mesajlarında disk alanı boşa harcamamasını isteyebiliriz.

Direct exchange‘in arkasındaki yönlendirme algoritması “bir mesajı, binding key (routingKey) mesajın yönlendirme anahtarıyla tam olarak eşleştiyse” o sıraya al şeklindedir.

Bu örnekte mesela, exchange e gelen datadan orange routkey li olanı C1 e, black ve green i de C2 kuyruğuna gönderilmesi istenmiş.

Multiple bindings

Aynı routkey ile (black) birden fazla kuyruğa (Q1,Q2) bağlanmakta mümkündür. Bu davranış biçimi ile aslında fanout exchange tipini taklit etmiş gibi oluyor.

Emitting logs

Loglama için Fanout yerine Direct tipinde bir exchange oluşturacağız. Log ların önem derecesini (severity) bir yönlendirme anahtarı olarak tanımlayacağız. Bu şekilde, alıcı komut dosyası almak istediği önem derecesine göre seçim yapabilecek.

İlk olarak bir exhange deklare ediyoruz;

channel.ExchangeDeclare(exchange: "direct_logs", type: "direct");

burada exchange tipimizin adına da “direct_logs” demiş olduk.

daha sonra da mesajı gönderecek kod bloğunu hazırlıyoruz;

var body = Encoding.UTF8.GetBytes(message);
channel.BasicPublish(exchange: "direct_logs",
                     routingKey: severity,
                     basicProperties: null,
                     body: body);

severity tipimizin info,warning ve error’dan biri olabilieceği bilgisini şu şekilde veriyoruz publisher uygulamasında;

var severity = (args.Length > 0) ? args[0] : “info”;

Subscribing

Alıcı tarafta ise her bir önem derecesi için bir yeni bir bind işlemi gerçekleştiriyoruz (QueueBind) Eşleştiğinde ilgili kuyruk,exchange tipi ve routingkey de elindeki mesajı iletecektir.

var queueName = channel.QueueDeclare().QueueName;

foreach(var severity in args)
{
    channel.QueueBind(queue: queueName,
                      exchange: "direct_logs",
                      routingKey: severity);
}

Sonuç olarak çalışmasını beklediğimiz yapı şu şekilde olacak, hata mesajlarını her 2 aboneye de gönderelim, info ile warning i ise sadece q2 alsın.

UYGULAMA SENARYOSU

Şimdi publisher uygulamamız olan emitlog projesine ait kodları paylaşalım;

Alıcı taraf uygulama kodlarımız ise;

aynı uygulamayı 2 kere, aynı anda debug parametreleri birinde info warning error iken aşağıdaki gibi iken çalıştıralım..

not: 2.ci alıcı uygulamasını ise debug ta sadece error da iken çalıştıralım…

rabbitmq sunucusunda da 2 ayrı kuyruk olarak oluştuklarını görelim;

daha sonra da publish uygulamasının debug parametresine “error” yazıp çalıştıralım;

error önem derecesini routkey parametresi olarak göndermiştik, alıcı tarafta da error,info ve warning routkey leri tanımlıydı. Dolayısıyla benim diğer 2 alıcım da bu mesajları almış oldu, bir nevi fanout yaptık.

Şimdi aynı senaryoyu parametremiz fatal olacak şekilde tekrar deniyoruz, routkey anahtarımız bu sefer fatal ve alıcı tarafta karşılığı yok…

alıcı tarafta görüldüğü gibi mesajları alamadık…

şimdi gönderici uygulamadaki parametreyi “info” olarak değiştirip tekrar çalıştırıyorum;

mesajlarım sadece “info warning error” parametresi vererek çalıştırdığım alıcı uygulaması aldı.

Böylece “UYGULAMA SENARYOSU” görselinde verdiğimiz gibi senaryoları test etmiş olduk…

Routing için kullanılan parametre çalışmasının sonuna geldik…

Github kodları için;

https://github.com/erolakgul/RabbitMQ_ReceiveLogsDirect

https://github.com/erolakgul/RabbitMQ_EmitLogDirect

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Connecting to %s