ugrás a tartalomhoz

ØMQ

inf3rno · 2014. Ápr. 9. (Sze), 10.58
ZeroMQ – aszinkron üzenetküldő rendszer nagy terhelésű eloszott alkalmazásokhoz
 
1

Használtátok már production

MadBence · 2014. Ápr. 9. (Sze), 18.59
Használtátok már production környezetben? Én leginkább AMQP környezetben (rabbitmq) mozgok, de érdekesnek tűnik ez a project is. Érdemes megnézni a nanomsg-t is, amit a zmq fejlesztése közben szerzett tapasztalatok figyelembe vételével írtak meg.
2

Van még az MQTT, ami szintén

inf3rno · 2014. Ápr. 9. (Sze), 19.26
Van még az MQTT, ami szintén egy hasonló rendszer. A ZeroMQ-hoz vannak még másik projektek is, amiket érdemes megnézni pl mongrel2, zerogw, nullmq stb...

Egyelőre csak ismerkedem ezekkel a technológiákkal, nagyon ígéretesnek tartom őket, de egy hete még a létezésükről sem tudtam... Amennyire tudom ZeroMQ-t használják éles környezetben páran jó eredménnyel, pl nodejs-hez kifejezetten ajánlják, illetve linkedIn-nél azt írják, hogy életrajban nagyon jó pont, ha valaki ismeri. A nanomsg még mindig béta, legalábbis tegnap még az volt.

Én valszeg robotikával kapcsolatos hobbi projektjeimnél fogom kipróbálni a ZeroMQ-t, nem webalkalmazásoknál. Teszelni akarom Raspberry PI-nál vezeték nélküli érzékelőknél a HTTP-REST-el összehasonlítva, stb...
3

Azt hiszem ez a válasz a

inf3rno · 2014. Ápr. 9. (Sze), 19.31
Azt hiszem ez a válasz a kérdésedre: is-zeromq-ready-for-production-use

Janoszen-nel beszéltem tegnap, ő azt írta, hogy ő php-hoz inkább nginx+php-fpm-et használ, mert ahhoz nagyobb a community, mint ZeroMQ-hoz. Ez mondjuk 1 a 17 nyelvből, ami támogatva van rajta...
4

Tomor

janoszen · 2014. Ápr. 10. (Cs), 00.37
Kicsit osszetomoritetted amit mondtam. A ket dolog alapvetoen masra valo, viszont webes kornyezetben sokszor bosegesen eleg, ha van egy jol megcsinalt API egy hatter szerveren, ami vissza tud terni es aszinkron modon tud mukodni. Itt jon a kepbe az nginx+PHP-FPM, ugyanis az utobbi a fastcgi_finish_request() hivasnak koszonheten tud aszinkron modon futni. Mi jelenleg igy hasznaljuk es siman van olyan job is, ami 1-2 oraig fut. Megfelelo DB alapu lockolassal egeszen ugy viselkedik, mint egy daemonkent futo, MQ alapu elosztott rendszer, csak ismert, jol kitesztelt eszkozokkel.

Az AMQP-t (RabbitMQ, ActiveMQ) kb egy eve megprobaltam mukodesre birni PHP alatt, de sajnos semmilyen szinten nem felelt meg a kivanalmaknak, mert nem lehetett neki graceful shutdownt tolni, csak megolni a folyamat kellos kozepen. A ZMQ-val nincs komolyabb tapasztalatom, de a mukodesi elvebol kiindulva csak arra az esetre jo, ha nem baj, hogy elvesznek adott esetben az uzenetek.

Update: az a valasz az SO-n odabasz rendesen. Remelem, nem tranzakciokat tolnak at rajta.
5

Update: az a valasz az SO-n

inf3rno · 2014. Ápr. 10. (Cs), 00.45
Update: az a valasz az SO-n odabasz rendesen. Remelem, nem tranzakciokat tolnak at rajta.

Lövésem sincs, írj nekik, ha érdekel... :-) Nem úgy tűnik, mintha elveszett üzenetek miatt aggódnának...

A wikipedia szerint az AMQP-vel egyszerre kezdték el fejleszteni ZMQ-t is 2007-ben, viszont simán lenyomta már 2010-ben is. A Sustrik srác, aki eredetileg elkezdte csinálni, kiszállt a csapatból és a nanomsg-t kezdte fejleszteni 2011-ben, szóval valószínűleg az még jobb lesz. Illetve, ha abból indulok ki, hogy a másikkal is nagyjából végzett 3 év alatt, akkor hamarosan jön az 1.0 nanomsg-ből is.

Összességében még nem olvastam sehol negatívumot ZMQ-ról, mondjuk még nem kerestem célirányosan ilyen hozzászólásokat...

update:
Azt írják róla, hogy nem lehet összehasonlítani a a kettőt, mármint az AMQP-s megoldások (RabbitMQ, ActiveMQ) azok alkalmazások, a ZMQ meg egy library, amit használni tudsz alkalmazások építéséhez. (Volt aki nem tudta, hogy lehetetlen, és megcsinálta.) Hasonlónak tűnik a különbség, mint apache és nodejs között, valószínűleg a sikere is ebben van, hogy nagy szabadságot ad a fejlesztőnek. A ZMQ körülbelül annyit csinál, hogy elviszi az üzeneteidet egyik thread-ből, process-ből vagy gépről egy másikra socketen keresztül az általad választott üzenetküldési stratégiával (Request-reply, Pub-sub, Pipeline, Exclusive pair). A szerializálást, parsolást, minden egyebet neked kell megcsinálnod, ami az üzenetekkel kapcsolatos, a ZMQ nem dolgozza fel az üzeneteket, csak elküldi őket. Ebben nagyon jó, és ezért nagyon könnyen lehet vele elosztott alkalmazásokat csinálni, skálázni több gépre egy alkalmazást, stb...

update2:

Nézem git-en a repo-kat: mongrel2 (webszerver ZMQ felett), ZMQ core lib, nginx. Hasonlóak a gites számok, mármint watch, star, fork. Mindegyik aktív, az utóbbi napokban is voltak commit-ok.

A google találatok száma már mást mutat, abban nginx, ami kb 10x erősebb zmq-hoz képest, és 100x mongrel2-höz képest.

Ezek alapján nem tudom mennyire lehet megítélni a közösségek méretét, mindenki vonja le maga a következtetést.

update3:

Nézegettem a lost message-es találatokat a google-ben. Legtöbbje már 3 éves, és általában programozói hiba okozza őket, nem a ZMQ. Általában amiatt panaszkodnak, hogy azelőtt küldenek ki üzeneteket pub/sub-al, mielőtt ténylegesen felállna vagy regenerálódna a rendszer. Az egyik comment-ben írják, hogy helyes beállításokkal ez elkerülhető.

Itt is írnak egy érdekes jelenségről, hogy alapból nincs timeout beleépítve a rendszerbe, és előfordulhat, hogy miközben újraindul a szerver, a kliens csak vár és vár a válaszra...

Találtam még a core lib-nél egy issue-t, ami azt mondja, hogy egy race condition miatt lehetséges az üzenet vesztés egy hetes folyamatos terhelés mellett, illetve, hogy csináltak már rá fix-et (pull request-et viszont még nem küldtek). Összességében a core lib eléggé letisztultnak tűnik. A csatolókban lehetnek még hibák, ott nyelvről nyelvre változhat a minőség, a php esetében pl valaki külsős csinálja a csatolót.

Összességében egyetértek azzal, hogy ki kell tapasztalni a vele kapcsolatos szopások körét, mert általában olyan gondok jönnek elő, amik amúgy talán szokatlannak számítanak, mert más rendszereknél alád írták őket. Üzenet vesztés úgy tűnik, hogy lehetséges kis mértékben (sok millióból egy), de gondolom be lehet építeni ellenőrzést, ami jelzi az ilyen szituációkat, és újraküldi az üzenetet. Nagyon úgy tűnik, hogy sok múlik azon, hogy mennyi tapasztalata van a fejlesztőnek a ZMQ-val. Maga az eszköz nem rossz, csak valószínűleg sokan olyanokat várnak tőle, ami eleve nem lett beletervezve, mert a fejlesztőre bízták.

update4:

Néztem sebesség teszteket is. Ezek alapján mongrel2 nem tűnik annyira kiforrottnak, mint a társai. Baromi gyors, sokat üzenetet át tud küldeni, de hamar összeomlik. Az nem derült ki, hogy ez a ZMQ vagy a szerver hibája. Btw a legtöbb cikk, amit ZMQ-val vagy mongrel2-vel kapcsolatban olvastam az 2012-es. Lehet, hogy azóta már jobban kiforrott a rendszer.