Názory k článku Nsq – systém pro doručování zpráv bez centrálního message brokera

Hmmm, distribuovaný systém pro výměnu zpráv to musí být noční můra pro administrátory. Dělal jsem na projektu postaveném na podobné technologii (TIBCO Rendezvous) a deployment byl udělaný zcela záměrně nedistribuovaně ačkoli to platforma umožňovala. Docela jsem je chápal :-)

Ono to ve skutečnosti může být docela trivka, pokud stačí mít jen jeden lookup. Protože jednotlivé nsqd (v podstatě vlastní brokery) můžu mít s naprosto stejnou konfigurací někde na OpenShiftu (například) s tím, že se budou připojovat k jednomu lookupu. A potom mě pád nsqd (resp. podů s ním) vlastně nevadí v případě, že je dané téma+kanál duplikováno. Samozřejmě pokud má běžet víc lookupů, je to už složitější, to asi admini nebudou úplně nejraději :-)

Moc nechapu proc by to mel byt problem. Predpokladam, ze by to fungovalo jako failover. Proste nsqd (a klienti) dostanou seznam lookupu a pripojej se na prvni dostupnej (nebo nahodne kvuli load balancingu). Je pak na lookupech, aby si data mezi sebou synchronizovali.
Moc sem to nezkoumal, takze nevim jestli je to takhle implementovany. Kazdopadne neni duvod aby ne. Podobne mame nastaveny tri licencni servery pro 500 databazovych serveru a podobne fungujou taky DNS servery...

Jj ta druhá část takto funguje, tam by problém být neměl. Akorát to hledání lookupu, jejich seznam, aktualizace toho seznamu v runtime, zkoušení, kterej je v provozu, přepojení na jinej při pádu - to může být problém (neříkám že všude a vždycky, ale už to není úplně triviální setup).

No seznam se da pri instalaci/aktu­alizaci. Aktualizace v runtime proc? Snad se nemenej tak casto, aby to bylo potreba a v pripade potreby restart urcite nezabere tak dlouho jako DB serveru s nekolika TB dat a kterej je nutnej taky restartovat pro update licencnich serveru. Zkouseni jestli je v provozu a prepnuti na dalsi v seznamu je vetsinou reseny timeoutem. Fakt v tom nevidim nic slozityho...

Ahoj Pavle. Planujes napisat nieco o nasom "rodinnom" qpidd? Vie to AMQP 1.0 a neutron je broker-less. Teda ziadny single point of failure. Pre viac info staci ze prebehnes do druhej budovy ;)

Ahoj jasně, chystám se. A právě proto, že je v RH spousta lidí, co to znají od a do z, se trošku bojím, aby byl článek kvalitní :-.)

Bylo by hodně pěkné mít nějakou tabulku s porovnáním message brokerů z různých pohledů. Protože někdo může preferovat jednoduchost nasazení a nemusí mu vadit třeba nějaké výpadky, další má zase k dispozici obrovský cluster a má jiné požadavky. Nikde jsem to nenašel a tady už zaznělo snad 10 message brokerů...