Vlákno názorů k článku Nsq – systém pro doručování zpráv bez centrálního message brokera od lzap - Hmmm, distribuovaný systém pro výměnu zpráv to musí...
-
Pavel TišnovskýZlatý podporovatelOno 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... -
Pavel TišnovskýZlatý podporovatel
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/aktualizaci. 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...
