Merhaba,
Bir önceki yazımızda çalışma kuyruklarını incelemiştik. Çalışma kuyruklarındaki ana mantık ise, her bir görevin bir worker’a teslim olmasını sağlamaktı.
https://www.rabbitmq.com/tutorials/tutorial-three-dotnet.html
Bugünkü çalışmada ise birden fazla worker’a bir mesaj göndereceğiz. Bunu birden fazla kullanıcın bildirimlerini takip ettiği bir gazete gibi düşünebiliriz.
Gazete “Şok şok şok emekliye müjde!!! Doğalgaz bulundu…” diye bir yayın yaptı diyelim, o gazeteyi takip eden 1000 emekli olsun. Hepsine bu bildirimin gitmesi gibi bir senaryo. Yayınlanan tüm mesajlar kullanıcıların hepsi tarafından alınacak yani.
Önceki senaryolarda ele aldıklarımıza tekrar bakacak olursak;
Publisher/Sender : mesaj gönderen bir kullanıcı uygulamasıdır.
Queue : mesajları saklayan bir arabellektir.
Consumer/Receiver : mesajları alan bir kullanıcı uygulamasıdır.
RabbitMQ’daki mesajlaşma modelindeki temel fikir, üreticinin hiçbir zaman doğrudan bir kuyruğa mesaj göndermemesidir. Bunun yerine, Producer/Sender bir exchange’e mesaj gönderebilir. Exchange bir taraftan bu Sender’lardan mesajı alırken, diğer taraftan da onları kuyruğa yönlendiriyor. Exchange aldığı bir mesajla ne yapacağını tam olarak bilmelidir. Belirli bir sıraya eklenmeli mi? Birçok kuyruğa eklenmeli mi? Yoksa atılmalı mı? Bunun için kurallar Exchange tipine göre belirlenir.
Kullanılabilir birkaç Exchange tipi var; direct, topic, headers ve fanout … Demoda fanout ile ilgili çalışacağız. Bu türde bir Exchange oluşturacağız ve buna logs ismiyle takip edeceğiz. Fanout exchange tipi aldığı tüm mesajları bildiği tüm kuyruklara yayınlıyor.
Bu arada rabbit mq ile bazı kodları komut ekranından da çalıştırabilmek için cmd uygulamasını admin olarak açıp, cd ile aşağıdaki gibi bir path e windows’ta erişip, o komutları çalıştırabiliriz.
C:\Program Files\RabbitMQ Server\rabbitmq_server-3.9.9\sbin>
Örnek olarak mesela bind ları listele komutunu çağırdığımızda aşağıdaki gibi bir sonuç dönebilir, şuana kadar yaptığımız örneklerde kullandığımız tüm kuyruk isimlendirmelerine ait çıktılar mevcut.
Şimdi uygulama taraflarına gelecek olursak, aşağıda publisher uygulamamız bulunuyor. Burada yapılan değişiklikler şu şekilde oldu, oluşturduğumuz kanal için ExchangeDeclare ile Fanout tipinde bir Exchange tanımladık ve ismine de logs ismini verdik.
Daha önceki BasicPublish metholarında exhange alanını boş bırakıyorduk, bu senaryoda exhange isminin logs olduğunu söylüyoruz. properties ise null bırakıldı, daha önce buradaki veriyi de Persistent attribute ünü true doldurup atamasını yapıyorduk.
Alıcı taraftaki uygulama için de exhange tipini fanout olarak belirtip logs ismiyle takip ediyoruz. Burada bir önceki alıcı uygulamasına göre şöyle bir fark var,kuyruk ismini dinamik alıyoruz gibi bir durum var, bunu daha sonra basicconsume methodunda kullanacağız. QueueBind methodu ile exhange’in kuyruğumuza mesaj göndermesini söylüyoruz. Kuyruk ile exhange arasındaki ilişkiyi kuruyor.
Şimdi pub uygulamamızı ve 2 tane sub uygulamamızı çalıştıracağız, ilk olarak yine sub ları çalıştırıyoruz;
2 uygulamada farklı kuyruk isimleri ile yayında;
Son olarak publisher uygulamamı da çalıştırıyorum;
Gönderdiğim mesajın her 2 worker’ıma da ulaştığını görüyorum.
Son olarak rabbitmq yönetimi ile ilgili kodların cmd ekranında kullanımı ile ilgili olarak da bir örnek bırakalım, bind işlemlerini listelemek istediğimizde, çalışan 2 worker’ın datasını da görebiliyorum…
Publish/subscribe uygulamamızın sonunda geldik…
Github kodları için;
{ } Veritabanı & Yazılım Geliştirme 