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ý, ...)?
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()
nebrat
Ale 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ě.
