Forum
Aktif konular
Üyeler
Kurallar
Arama
Tahribat.com Forumları 
Webmaster ve Yazılım Geliştiriciler 
Rabbitmq'yu Hangi Durumlarda Kullanıyorsunuz? Rabbitmq'yu Hangi Durumlarda Kullanıyorsunuz?
-
merhabalar
genel olarak mesaj kuyruk sistemini hangi durumlarda kullanıyorsunuz? örneğin üye olma işlemleri pek yorucu olmadığından server response time'ı etkilemediğinden gerekli bir alan değil rabbitmq için. ama klasik kod örneklerinin yer aldığı email gonderme işini rabbitmqye atmak kullanıcıyı fazla bekletmeden güzel bir sonuç veriyor.
resim upload işlemlerinde resmi bytea çevirip gönderiyor munusuz?
başka neler var mimari yaklaşımınız nedir genel olarak rabbitmq için?
-
İşlemi uzun süreç alan ve sürecin sonucunun anında görülmesine gerek olmayan her alan olabilir.
-
haber sisteminde 3-4 farklı şekilde kullanıyordum.
piyasadaki bütün haber sitelerini dolaşıp haberlerin title spot content ve image larını alıp kaydeden bir yapım vardı. burada şu şekillerde kullanıyordum.
1-) Haberlere ait domainleri dolaşıp indirilecek olan urlleri rabbitmq ye atıyordum. böylece url arama servisi sürekli yeni haber urlleri arıyor ve indirmekle zaman kaybetmiyor.
2-)rabbitmq de olan urlleri download eden servis haberin textlerini download ederken resim urllerini yine indirilmek üzere imajdownload kuyruğuna atıyordu. böylece urldownload servisi sadece metinlerle ilgileniyordu.
resim indirme de kuyruğundaki resim urllerini bulup indiriyor tabi bu sırada.
3-)rabbitmq de urlleri download ettikten sorna yine haberlerin kategorisini tespit etmek için kategori tespit kuyruğuna ekliyordum. kategori tespit eden servisler yine kendi kuyruğunu kontrol ediyordu.
4-)urlleri download ettikten sonra yine aynı urlleri grup kuyruğuna atıyordum benzer haberleri gruplayan bir servis vardı. mesela cumhurbaşkanı açıklama yapıyor 100 tane haber sitesi aynı haberi aynı title spor ve contentle yayınlayabiliyor. biz bunları sistemde gruplayarak gösteriyorduk. bu grupları oluşturan servisinde kendi grubu vardı.
bu işlemlerin hepsi birbiridnen bağımsız yapılabildiği ve hr servisin dağıtık bir yapısı olduğu için ben bu şekilde kullandım. ama üye register için rabbitmq kullanmak doğru olmaz.
-
manglerman bunu yazdı
haber sisteminde 3-4 farklı şekilde kullanıyordum.
piyasadaki bütün haber sitelerini dolaşıp haberlerin title spot content ve image larını alıp kaydeden bir yapım vardı. burada şu şekillerde kullanıyordum.
1-) Haberlere ait domainleri dolaşıp indirilecek olan urlleri rabbitmq ye atıyordum. böylece url arama servisi sürekli yeni haber urlleri arıyor ve indirmekle zaman kaybetmiyor.
2-)rabbitmq de olan urlleri download eden servis haberin textlerini download ederken resim urllerini yine indirilmek üzere imajdownload kuyruğuna atıyordu. böylece urldownload servisi sadece metinlerle ilgileniyordu.
resim indirme de kuyruğundaki resim urllerini bulup indiriyor tabi bu sırada.
3-)rabbitmq de urlleri download ettikten sorna yine haberlerin kategorisini tespit etmek için kategori tespit kuyruğuna ekliyordum. kategori tespit eden servisler yine kendi kuyruğunu kontrol ediyordu.
4-)urlleri download ettikten sonra yine aynı urlleri grup kuyruğuna atıyordum benzer haberleri gruplayan bir servis vardı. mesela cumhurbaşkanı açıklama yapıyor 100 tane haber sitesi aynı haberi aynı title spor ve contentle yayınlayabiliyor. biz bunları sistemde gruplayarak gösteriyorduk. bu grupları oluşturan servisinde kendi grubu vardı.
bu işlemlerin hepsi birbiridnen bağımsız yapılabildiği ve hr servisin dağıtık bir yapısı olduğu için ben bu şekilde kullandım. ama üye register için rabbitmq kullanmak doğru olmaz.
eline sağlık hocam gerçekten hakkını verdirmişsin rabbitmqnun :)
-
Asenkron islemler icin yada farkli servislerin haberlesmesi icin kullanabilirsin. @manglerman ornek uzerinden guzel izah etmis.
-
vallah ben sirf pythonda celery icin kullaniyorum
-
Microservice kullanan mimarilerde servisler arası iletişim için de kullanılabiliyor bu yapılar.
Basit bir e-ticaret sistemi üzerinden örneklemeye çalışayım:
En yalın haliyle şu mikroservisleri olan bir e-ticaret platformumuz var diyelim: login, catalog, pricing, promotion, order, notification, shipment, recomendation, cart ve profile.
Her servisin kendi database'i, kendi sorumlulukları var. Her bir servisi bambaşka teknolojiler kullanarak geliştirebilirsin. Farklı docker imageleri üzerinde, farklı makinelerde hatta farklı coğrafyalarda çalışıyor olabilirler.
Product page (UI) birçok servis ile haberleşiyor arka planda. Ayrıca bu servislerin de birçoğu birbiri ile haberleşiyorlar diyelim.
İşte bu servisler arası haberleşmeler için bir yöntem gerekiyor. Bu yöntemlerden biri de bu message brokerlar. (Diğerleri için bknz: grpc, REST..)
Şu iki image de destekleyici materyal olarak dursun burada:
ve
-
JPriest bunu yazdı
Microservice kullanan mimarilerde servisler arası iletişim için de kullanılabiliyor bu yapılar.
Basit bir e-ticaret sistemi üzerinden örneklemeye çalışayım:
En yalın haliyle şu mikroservisleri olan bir e-ticaret platformumuz var diyelim: login, catalog, pricing, promotion, order, notification, shipment, recomendation, cart ve profile.
Her servisin kendi database'i, kendi sorumlulukları var. Her bir servisi bambaşka teknolojiler kullanarak geliştirebilirsin. Farklı docker imageleri üzerinde, farklı makinelerde hatta farklı coğrafyalarda çalışıyor olabilirler.
Product page (UI) birçok servis ile haberleşiyor arka planda. Ayrıca bu servislerin de birçoğu birbiri ile haberleşiyorlar diyelim.
İşte bu servisler arası haberleşmeler için bir yöntem gerekiyor. Bu yöntemlerden biri de bu message brokerlar. (Diğerleri için bknz: grpc, REST..)
Şu iki image de destekleyici materyal olarak dursun burada:
ve
teşekkürler hocam yorum için.
"İşte bu servisler arası haberleşmeler için bir yöntem gerekiyor." bu kısmı açar mısın biraz. Product ve Category birbiriyle konuşması gerekirken hangi adımda rabbitmqyu kullanması gerekir?
-
https://www.youtube.com/watch?v=wZbX_Qh8zbI
Detaylı ve örnekler ile gökhan anlatmıştı, yine aynı şekilde Apache Kafka ve Zeromq de mevcut.
-
cemnet bunu yazdı
teşekkürler hocam yorum için.
"İşte bu servisler arası haberleşmeler için bir yöntem gerekiyor." bu kısmı açar mısın biraz. Product ve Category birbiriyle konuşması gerekirken hangi adımda rabbitmqyu kullanması gerekir?
Hocam mesela satıcı ürünü kargoladı ve takip numarası girdi sisteme. Senin shipping servisine gitti diyelim bu bilgi ilk önce. O da bu bilgiyi gerekli kuyruklara yazacak. Mesela notification service dinliyor olsun o kuyruğu, gerekli kullanıcı için bir mesaj hazırlayacak ve mail servisine haber verecek. Kullanıcıya SMS, push ve mail gidecek vs. O arada order'ın status bilgisi değişecek, shipped olacak mesela. Order servisine bunu haber etmen gerekiyor.
Sepete ekledin ama henüz satın almadığın ürünler var diyelim. Fiyatlarda güncelleme olsun mesela, pricing service bunu ilgili kuyruğa yazar. Ordan mesela notification service okuyorsa müşteriye mail atar şu ürün(ler)in fiyatı değiştiği için sepetinin fiyatı arttı/azaldı vs.
Her servisin kendi persistence sistemi ayrı olduğu için, kendini ilgilendiren gerekli bilgileri her biri ayrı ayrı tutuyor olacaklar.
Umarım soruna cevap olmuştur birazcık da olsa.
-
JPriest bunu yazdıcemnet bunu yazdı
teşekkürler hocam yorum için.
"İşte bu servisler arası haberleşmeler için bir yöntem gerekiyor." bu kısmı açar mısın biraz. Product ve Category birbiriyle konuşması gerekirken hangi adımda rabbitmqyu kullanması gerekir?
Hocam mesela satıcı ürünü kargoladı ve takip numarası girdi sisteme. Senin shipping servisine gitti diyelim bu bilgi ilk önce. O da bu bilgiyi gerekli kuyruklara yazacak. Mesela notification service dinliyor olsun o kuyruğu, gerekli kullanıcı için bir mesaj hazırlayacak ve mail servisine haber verecek. Kullanıcıya SMS, push ve mail gidecek vs. O arada order'ın status bilgisi değişecek, shipped olacak mesela. Order servisine bunu haber etmen gerekiyor.
Sepete ekledin ama henüz satın almadığın ürünler var diyelim. Fiyatlarda güncelleme olsun mesela, pricing service bunu ilgili kuyruğa yazar. Ordan mesela notification service okuyorsa müşteriye mail atar şu ürün(ler)in fiyatı değiştiği için sepetinin fiyatı arttı/azaldı vs.
Her servisin kendi persistence sistemi ayrı olduğu için, kendini ilgilendiren gerekli bilgileri her biri ayrı ayrı tutuyor olacaklar.
Umarım soruna cevap olmuştur birazcık da olsa.
cevap oldu hocam tesekkürler.
cukurova bu videoyu görmüştüm ama izlememiştim artık izlemek farz oldu sağol hocam
Kısayol
Şikayet
Özel Mesaj
Alıntı yap
Cevapla