Názory k článku RabbitMQ: jedna z nejúspěšnějších implementací brokera
-
.ex (neregistrovaný)
Prave proto, ze je Erlang dobry pro distribuovane aplikace, muze se hodit i pro HA. Jednim z duvodu, proc psat distribuovany system, muze byt prave HA (samozrejme krome jinych duvodu, napriklad skalovani). Soucasti ekosystemu Erlang/OTP je mimo jine i distribuovana db mnesia, kterou lze k HA vyuzit (rabbit ji pouziva pro uchovani metadat, ne vlastnich zprav).
-
Filip JirsákStříbrný podporovatelTaké jsem to hledal, seriál tady z toho myslím zatím udělaný není. Otevřete si seznam článků Pavla Tišnovského, a tam je to aktuální článek o RabbitMQ, dva články o Celery a článek o Redis Queue. Aspoň tak jsem si tu trojici nástrojů vyložil já.
-
Pavel TišnovskýZlatý podporovatelDobrý den,
omlouvám se, ale jako "obyčejný autor" nemám právo vytvářet seriály, takže jen posílám odkazy na RQ a Celery:
https://www.root.cz/clanky/pouziti-nastroje-rq-redis-queue-pro-spravu-uloh-zpracovavanych-na-pozadi/
https://www.root.cz/clanky/celery-system-implementujici-asynchronni-fronty-uloh-pro-python/
https://www.root.cz/clanky/celery-system-implementujici-asynchronni-fronty-uloh-pro-python-dokonceni/ -
Pavel TišnovskýZlatý podporovatel
Ano, ale ne tento rok :)
Pěkně se tím spojí oba paralelně běžící seriály... -
S tou konzumaci zprav, nevim jestli lze rucne potvrzovat zpravu, aniz bych potvrdil tu predchozi, ale tipl bych si ze ne.
V kazdem pripade se mi i libi, ze to polluje za me a nemusim mit smycku a vola to muj kod samo.Na konferencich lide nadavaji na Kafku, protoze se spatne spravuje (coz potvrzuji) a pry prechazeji na Rabbit. Tohle se mi libi vic nez Kafka, takze to urcite stoji za vyzkouseni.
-
Jde to. Múžete si třeba vybrat 100 zpráv a acknout je později.
Spíš jsem narazil na jeden nepříjemný a dost neočekávaný bug/vlastnost: pokud si vybere proces správu a spadne před acknutím, tak sice správa je stále ve frontě (vidět jako unacked v management konzoli), ale následně ji dostane i proces, který se přihlásí s routing key, který to nematchuje. Chovalo se to takto pro direct i topic fronty.
-
Pavel TišnovskýZlatý podporovatel
To by se stávat nemělo. Stane se to vždycky jen po pádu konzumenta (resp. po uzavření kanálu - protože RabbitMQ neví nic o procesu, jen o kanálu IMHO) nebo i když jen pošle NACK?
Něco podobného jsem viděl kdysi u kombinace Celery+Rabbit, ale tam šlo o to, že Celery v té době špatně implementovalo nějakou sémantiku AMQP (on je ten protokol docela začmodrchaný :-)
-
aaa (neregistrovaný)
Fakt ma Rabbit srovnatelne dobre resene HA a performance jako Kafka? A umi Rabbit seekovat v topicu, pamatovat si last committed offset consumera a pokracovat po restartu daneho consumera tam kde prestal? Zvlastni, me se naopak libi explicitni pollovani Kafky s timeoutem a nelibi callback.
-
armabeton (neregistrovaný)
Podle mě to neumí a je zapotřebí si vybrat, co přesně potřebujete pro práci. U nás máme RabbitMQ a SQS jako "obyčejné" message brokery, kde prostě zpráva buď přijde a je ACKovaná nebo není. Kafka je zase perfektní na zpracování výstupů od našich wannabe-AI lidí - to jsou mraky obrovských vektorů a tam Kafka vyhrává.
-
Tomáš (neregistrovaný)
0MQ je trosku slozitejsi na pochopeni ne? https://dzone.com/articles/concise-comparison-rabbitmq
jinak me to pripomelo fakt zajimavy blog o C++ (ani ne tak o 0MQ): http://250bpm.com/blog:4
-
Yenya (neregistrovaný)
Kdo nějaký takovýto message broker provozujete - jaké s tím máte zkušenosti z provozu, a jaký typ/velikost/frekvenci zpráv přes to posíláte?
Já třeba už delší dobu řeším věci typu cache na clusteru strojů - věci typu "přijde nový uživatel, nová HTTP session, nová cookie, a i když se vytvoří na jednom uzlu, bylo by z výkonových důvodů informovat ostatní uzly, protože load balancer pošle třeba příště jeho další HTTP požadavek na jiný uzel". Momentálně to řeším multicastem, přičemž u zpráv které se nemají ztratit (invalidace něčeho) mám per-sender sériové číslo, a při obdržení zprávy s vyšším sériovým číslem než posledně toho holt invaliduju víc nebo se nějak zařídím.
Má cenu pro takovýto typ zpráv mít toho brokera? A jak se řeší HA - více brokerů na virtuální předávané IP adrese? Jak se to chová v okrajových případech (broker neni, broker je pomalý, broker je přetížený, ...)?
Díky,
-Yenya
-
Kenny (neregistrovaný)
Kolega dělal před pár lety srovnání než jsme Rabbita nasazovali. Bylo to na verzi RabbitMQ 3.4.4 s Pythonem 2.7.6 a Twisted 15.0. Testoval na Ubuntu 14.04 na HW Intel i5-3320M, 8GB RAM s SSD diskem. Zde jsou poznámky z dokumentu:
Výkon
cca 10000 zápisů persistentích několika-bytových zpráv a 10000 potvrzovaných čtení za vteřinu
limitem je Twisted, kde reactor běží v jednom vlákně, např. při posílání 300000 zpráv ve smyčce se 15 vteřin "skoro nic neděje" a až pak se začnou posílat, potom, co už reactor není vytížen řazením zpráv pro odeslání (při řazení je tam ale yield na možnost vykonat v reaktoru další věci)Pika blocking connection
jednak je pomalé při použití jednoho vlákna (300 odeslaných zpráv za vteřinu)
za druhé při zátěžových testech docházelo k stack overflow, protože se při odesílání acku volá něco jako process_messages()
nebratAle je to 3 roky starý test a od té doby se lecos mohlo změnit. V produkci (call centra s zátěží do 100 souběžných hovorů, cca. 10 eventů za vteřinu) takových hodnot zpráv za sekundu zdaleka nedosahujeme, takže testování zátěže s aktuálními verzemi bohužel nemám k dispozici.
Oproti implementaci s multicastem pro Váš specifický use-case bude Rabbit určitě pomalejší už jen z logiky věci, že se jedná o univerzální řešení frontování, které navíc komunikuje unicastově.
ČLÁNKY DO MAILU