Uz to zminoval Messa, ale pro mne to bylo velke prekvapeni pri pokusu o integraci s Flaskem: ZMQ funguje nad event loop, ktera monkey-patchuje I/O operace (zejmena sockety) v zakladni knihovne - byval to gevent, ted uz zrejme i dalsi. To znamena, ze jakmile ve Flaskove aplikaci (ktera spoleha na klasickou implementaci s prefork/threadpool workerama) udelam import zmq, tak se mi patchne socket a mam smulu => zmq neni kompatibilni a ZMQ komunikaci (napr. distribuci tasku z API na workery na nichz mi bezi nejaky machine learning) si musim provozovat v samostatnem procesu/interpretu Pythonu, oddelenem od weboveho API.
Dalsi prekvapko pro me bylo, ze kdyz jsem se z guidu docetl, ze jakmile v ZMQ odpojim subscribera (napr. prevysadim novou verzi me microservice), tak mu utecou vsechny zpravy ktere mezitim nekdo publikoval. Podobne ze pokud zacnu driv publikovat nez konzumovat, tak prijdu o zpravy ktere byly v mezicase publikovane. Tedy hodne jine chovani, nez u pub-sub s perzistenci, jako je napr. Kafka. Cili s tim chce pocitat pri navrhu a dobre si precist vsechny ty lazy pirate patterny a spol. (publisher si hlida, ze mu prislo potvrzeni o prijeti zpravy a kdyztak ji znova publikuje) v dokumentaci ZMQ.
A treti prekvapko pro me bylo, ze nad ZMQ nemuzu provozovat HTTPS - pokud chci sifrovat, tak bud si pro kazdy komunikacni kanal budu udrzovat point-to-point SSL tunel (a hlidat si, ze se nerozpadl, coz u velkeho poctu spojeni a M:N komunikace neni nic moc), nebo musim pouzit custom sifrovani ze ZMQ nadstavby pomoci eliptickych krivek, coz muze narazit na securitaky (ne ze by to nebylo bezpecne, ale nemaji to v korporatu na seznamu schvalenych technologii a kvuli ZMQ ho rozsirovat nehodlaji) a pokud dodavam externim zakaznikum tak me to muze znevyhodnovat ve vyberovem rizeni/RFP.
Kdyztak me pls nekdo doplnte/opravte, naposledy jsem se o ZMQ zajimal pred dvema lety a spousta se toho mohla od te doby zmenit.
ale vazne - fronty ZMQ samozrejme ma, vytvari se pro kazdy socket a podle typu pripojeni se resi, co delat s plnou frontou na vstupu nebo na vystupu (zahazovat zpravy nebo blokovat - opet podle toho co potrebuje uzivatel).
ty druhe dva body vyresite nasazenim normalniho message brokera - RabbitMQ, AMPQ, SQS, RQ. Pokud vam fakt staci message fronty a nejake zakladni pipeline, nema smysl IMHO pouzivat knihovnu urcenou na neco trosku jineho. Ten prvni je asi hodne relevantni, ale my to pouzivame s C/C++, kde takovy problemy nejsou (proste si ZMQ udela vlastni vlakno, ale o tom vlastne ani nemusime vedet).
