RabbitMQ
RabbitMQ
RabbitMQ bir MQ(message queue) sistemidir. Producer(ve ya publisher), Consumer( ve ya subscriber) -den ibaret olub Queue(FIFO) mentiqi ile calisir. Open source-dur. Cross-platform -dur muxtelif emeliyyat sistemlerine install edile biler. Daha rahat isleye bilmemiz ucun management interface de verilir bize:
RabbitMQ Documentation linki : (https://www.rabbitmq.com/getstarted.html)
Qisa umumi basliq verdik indi ise detaylara kecmezden evvel gelin niye bele bir seye MQ -ye ehtiyac yarandi evvel nece isleyirdik ona baxaq:
90-ci illerden en cox istifade edilen arxitektura client-server arxitekturasi idi. Kompyuterimizdei her hansi yuklenen programdan server terefe, server terefdeki app-e ferqli protokollar vasitesile elaqe yaradilirdi ve aralarinda xeberlesme ve melumat mubadilesi gerceklesirdi.
Ve app terefde adeten monolith, boyuk ve qarisiq bir app dayanirdi. Daha sonra yavas yavas bu huge app-lerden distrubuted modullar sekline bolerek mikroservis arxitekturasina ehtiyac ve kecid basladi. Burada da evveller butun modullar bir biri ile cox qarisiq elaqelerde(request/response) olurdu. Ve daha sonra bu qarisiqligi hell etmek ucun Event Driven Architecture adinda eventlerle isleyen yeni arxitektura ortaya cixdi.Burada ferq onda idi ki burada komponentler bir birleri ile yox arada yer alan Message Bus ile xeberlesirdiler.
Burada app-de tutaqk meselem hanisa emeliyyat bas verdi ve bununla bagli event gonderilir queue-ye ve bu queue-den hemin eventi alib asinxron olaraq calisan kompnentler olur.
Producer lazim olduqda ise dusur , consumer ise hemise islek olur consume etmek ucun gelen eventi.Queue-de her hansi message limit yoxdur.
Bu mentiqle isleyen MQ sistemlerden RabbitMQ, Apache Kafka daha cox meshurdurlar.
Indi gelin umumi mentiqi anladigimiza gore kecen RabbitMQ-de beyaq sekilde gosterdiyimiz modeli izah edek :
1- Publisher: queue-ye messaji eventi gonderendir
2- Consumer: hemin queue-yi izleyib uygun eventi handle edib consume edendir
3- RabbitMQ
* Routing key: Mesajimizin gonderilmesinde istirak eden routing key-e -imizdir
* Exchange: routing key-e gore uygun queue-ye yonlendiren
* Queue: Mesajimizin dusduyu umumi queue (FIFO prinsipi ile isleyir)
* Exchange type: routing key-e gore queue-lere yonlendirme tipi
(Direct Exchange, Fanout Exchange Topic Exchange Headers Exchange)
Gelin sirasi ile exchange tiplerimize ve nece islediyine baxaq:
Direct Exchange
routing key-e gore konkret uygun queue-ye atir
Headers Exchange
Burada routing key yox message header bilgisine gore axtaris edilir hansi queue-ye bind edilen x-match key uygun gelse ora yoneldirilir :
Fanaout Exchange
Burada routing key-e baxilmir ve butun queue-lere gonderilir eventimiz. Burada hamisina gonderir amma hansi sira ile gondereceyi belli olmur ozu qerar verir.
Topic Exchange
Burada routing key-e bir template formasinda baxilir. Match olan butun uygun queuelere gonderilir. Meselem :
man.liked -> kisilerin beyendikleri
man.unliked -> kisilerin beyenmedikleri
woman.liked -> qadinlarin beyendikleri
woman.unliked -> qadinlarin beyenmedikleri
man.* -> kisilerin beyendiyi ve beyenmedikleri her sey
woman.* -> qadinlarin beyendikleir ve beyenmedikleri her sey
*.liked -> butun beyenilenler
*.unliked -> butun beyenilmeyenler
# -> Hamisi ( bir nov fanout type kimi isleyecek # versez )
Message Acknowlidgment
RabbitMQ-nin bu ozelliyi default olaraq false-dir ancaq enable etdikde ne bas verir. Bezen hansisa sebebden consumerimiz dayanmis ola biler ve queue-deki uygun eventimiz orda ilisib qala biler. Ancaq bu ozellik sayesinde consumer ugurla eventi isledikden sonra rabbitmq-ni notify edir ki ugurlu oldu ve queue-den event silinir, eks halda rabbitmq bir seylerin bas verdiyi anlayb eventi yeniden queue-eye atir yeniden consume olunsun deye.
Round-robin dispatching
Bu ozellik rabbitmq-de consumerlerin eventleri consumer sayina gore bolmesini gosterir. Yeni eger 2 consumerim 5 mesajim varsa tutaqki 1 ci consumer 1,3,5 goturubse consumer 2 2,4 -cu eventleri consume edir.
Fair Dispatch
Round robin dispatching bildik ancaq burada bir sual yaranir.Eger orada 1,3,5 cox rahat asan consume olunan proses , 2,4 ise cox gec uzun cekecek prosesdirse bu bolusdurme edaletli deyil ona gore fair dispatch etmek ucun basic_qos() ozelliyine dispatch_count=1 vere bilerik.
Bu zaman rabbit-e bir mesaj consume olub bitmeyibse 2-ci mesaji da ona vermesinin qarsisi alinir , gozeyir bitmesini.
Yorumlar
Yorum Gönder