distributed systems

[109]

ну вот, кстати, если кому интересно, чем я занимался 3-4 года назад: Zookeeper Atomic Broadcast. не в том смысле, что я этим зоопаркером занимался, а в том, что делал то же самое - global state synchronized through leader. читать очень интересно - практически все решения те же самые, с тем же самым обоснованием. только я это сделал в 2009 году, а статья по ссылке датирована 2011. и leader election у меня происходит за 5 ms, а у них за 200.

но вот что мне не понятно. вот тут приводятся цифры типа 30К writes per second. это в системе, где все writes проходят через лидера и каждый write involves hardening и multi-machine communications. по-моему, это враньё. столько сообщений не послать даже между двумя машинами, и даже если на диск не писать (please note that after sending every message we need to wait for response before sending the next one).

Comments

[selfmade.livejournal.com]

А почему асинхронно слать нельзя?

[exceeder.livejournal.com]

+1 Шлю себе асинхронно, протокльчик недавно на NIO2 сделал достаточно плотный. Но не Zookeeper... то есть просто протолкать 30k маленьких но полезных сообщений в секунду я берусь. Но не координационную систему для кластера.

[109.livejournal.com]

если слать асинхронно, то это просто два стрима - один в одну сторону, другой в другую. тогда уже становится бессмысленно говорить о количестве сообщений в секунду, а надо говорить о мегабодах.

[109.livejournal.com]

потому что order must be preserved.

[wizzard]

зукипер как бы давно известно что не самая быстрая реализация. 30k WPS у них получается, потому что пачки запросов от одного юзера батчатся.

Реально там <500 WPS.

[109.livejournal.com]

ааа бля, батчинг-то мне и не пришёл в голову. тогда понятно. но latency же тогда растёт. у меня-то как раз заточено было на low latency, ибо сцуко bing, 50 ms на весь pipeline.

а дотнетные есть продукты с похожей функциональностью?