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. bylece 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. bylece 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 gsteriyorduk. 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 :)

teşekkürler hocam yorum için. "İşte bu servisler arası haberleşmeler için bir yntem 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 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. Sen hiç kaval çaldın mı?

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 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 yntem gerekiyor. Bu yntemlerden biri de bu message brokerlar. Şu iki image de destekleyici materyal olarak dursun burada: ve Sen hiç kaval çaldın mı?

belki saçma ama ben timeout olması muhtemel şeylerde de queue kullanıyorum mesela ui da bir veri filtreleme dalgamız var. adam bi ton parametre giriyor, şunu değiştir bunu değiştir falan yapıyo. nizle dediğinde parametrelerle arkaya yollayıp queue da previewi oluşturup front ende geri postalıyorum pusher la. bylece web serveri yormamış oluyorum ağır işi yine arkada workerlar yapıyo. Saçma değil aynen yle. queue çıkış mantığı; Handle edebileceğinden fazla miktarda veriyi işleyebilmek. rneğin saniye 3000 veri işleyebilen bir db sahipsin, ama sana saniyede 10.000 veri geliyor. Eğer bunlar udp üzerinden gelirse paketler kaybolur, tcp paketleri timeout düştüğü için karşı taraf yanıt alamadığı için her saniye sana tekrar 10.000 veriyi tekrar gnderir, dahada şişer. İşte queue mekanızması bu sorunu çzüyor, bunları sıraya koyuyor, ayırıyor ve işliyor. cukurova tarafından 20/Oca/21 16:49 tarihinde düzenlenmiştir

Asenkron islemler icin yada farkli servislerin haberlesmesi icin kullanabilirsin. @manglerman ornek uzerinden guzel izah etmis. herkes programcı olmak zorunda değildir, lütfen bir zorunluluk gibi programlama dilleri ğrenmeye çalışmayın. yabancı dil filan ğrenin amq.// s. kimin etini yerim, kasaba minnet etmem.// ince düşünene kalın girer.//

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. bylece 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. bylece 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 gsteriyorduk. 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. türk kızlarından sabun yapalım, rus kızları elini yıkasın.:)

cemnet bunu yazdı teşekkürler hocam yorum için. "İşte bu servisler arası haberleşmeler için bir yntem 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 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 grmüştüm ama izlememiştim artık izlemek farz oldu sağol hocam

yolbulucu bunu yazdı belki saçma ama ben timeout olması muhtemel şeylerde de queue kullanıyorum mesela ui da bir veri filtreleme dalgamız var. adam bi ton parametre giriyor, şunu değiştir bunu değiştir falan yapıyo. nizle dediğinde parametrelerle arkaya yollayıp queue da previewi oluşturup front ende geri postalıyorum pusher la. bylece web serveri yormamış oluyorum ağır işi yine arkada workerlar yapıyo. Saçma değil aynen yle. queue çıkış mantığı; Handle edebileceğinden fazla miktarda veriyi işleyebilmek. rneğin saniye 3000 veri işleyebilen bir db sahipsin, ama sana saniyede 10.000 veri geliyor. Eğer bunlar udp üzerinden gelirse paketler kaybolur, tcp paketleri timeout düştüğü için karşı taraf yanıt alamadığı için her saniye sana tekrar 10.000 veriyi tekrar gnderir, dahada şişer. İşte queue mekanızması bu sorunu çzüyor, bunları sıraya koyuyor, ayırıyor ve işliyor. grdüğüm kadarıyla genelde websocketla uzun süre açık kalan bi bağlantı kullanıp yapıyolar bu tarz işleri. bu yüzden amelelik yapıyomuşum gibi geldiydi 29.99cm, titanyum kaplamalı, çift damarlı, su ve yağ soğutmalı.

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 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 yntem gerekiyor. Bu yntemlerden biri de bu message brokerlar. Ş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 yntem gerekiyor." bu kısmı açar mısın biraz. Product ve Category birbiriyle konuşması gerekirken hangi adımda rabbitmqyu kullanması gerekir?

belki saçma ama ben timeout olması muhtemel şeylerde de queue kullanıyorum mesela ui da bir veri filtreleme dalgamız var. adam bi ton parametre giriyor, şunu değiştir bunu değiştir falan yapıyo. nizle dediğinde parametrelerle arkaya yollayıp queue da previewi oluşturup front ende geri postalıyorum pusher la. bylece web serveri yormamış oluyorum ağır işi yine arkada workerlar yapıyo. 29.99cm, titanyum kaplamalı, çift damarlı, su ve yağ soğutmalı.

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 gnderiyor munusuz? başka neler var mimari yaklaşımınız nedir genel olarak rabbitmq için?

https://www.youtube.com/watch?v=wZbX_Qh8zbI Detaylı ve rnekler ile gkhan anlatmıştı, yine aynı şekilde Apache Kafka ve Zeromq de mevcut.

vallah ben sirf pythonda celery icin kullaniyorum duanla yasamadim ki bedduanla oleyim - Arif

İşlemi uzun süreç alan ve sürecin sonucunun anında grülmesine gerek olmayan her alan olabilir. Bu imzayı her grdüğünüzde 4gb kotanızın 0,00000358559191226959228515625 azalmaktadır. Bilerek ve istenerek bu imza yapılmıştır. Amaç kotanızı smürmektir