Weblabor

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.