leader election again

[109]

вот, наткнулся на изделие мартина фаулера: lmax.

интересная и нетривиальная часть, как обычно, упомянута одним предложением: Should the master node go down, it's lack of heartbeat will be noticed, another node becomes master, starts processing input events, and starts its replicator.

вопросы, как обычно - кем will be noticed? что гарантирует единственность нового мастера? чем гарантируется, что старый мастер не очухается - или, если очухается, поймёт, что он уже не мастер?

в любом случае, интересное чтиво, например:

10: While the LMAX team shares much of the current interest in functional programming, they believe that the OO approach provides a better approach for this kind of problem. They've noticed that as they work to write faster code, they move away from a functional style towards OO style. Partly this because of the copying of data that functional styles require to maintain immutability. But it's also because objects provide a better model of a complex domain with a richer choice of data structures.

а, и ещё одного я не понял. почему фаулер считает, что lock приводит к context switching и cache invalidation? To deal with the write contention a queue often uses locks. But if a lock is used, that can cause a context switch to the kernel. When this happens the processor involved is likely to lose the data in its caches.

Comments

[thedeemon.livejournal.com]

Не приводит, а "может вызвать". Если lock занят, и запрашивающий его поток засыпает в ожидании, система делает активным другой поток, вот и context switch, вот и возможная потеря кэшей (новый поток их забивает своими данными). Ну и само обращение к lock в случае, когда он занят, это обычно ядреный вызов, переход с 3 на 0 кольцо, это тоже context switch называют. Так обычно описывают.

[plumqqz.livejournal.com]

The Business Logic Processor runs entirely in-memory using event sourcing.
Вы меня извините за сравнение, но чем-то мне это отечественные конференции "Хайло" напоминает, пусть и несправедливо. Такой же чемпионат по скорости записи в оперативную память.

[109.livejournal.com]

я ещё не определился со своим отношением к этому изделию. но с persistence на первый взгляд всё нормально, write ahead logging и replay в случае упадения.

[serge shikov (from livejournal.com)]

> it's lack of heartbeat will be noticed
Ну, это как раз просто. Тут noticed в смысле - остальными узлами кластера. Мастер очевидно регулярно посылает сообщения и том, что живой. Как только одно из них не доходит, инициируются выборы нового мастера.

Не могу ничего сказать про конкретно этот продукт, но напрашивается идея посмотреть на аналогичный Hadoop (а точнее на его часть ZooKeeper), где аналогичные первому вопросы возникают тоже. И насколько я помню, там именно что-то вроде выборов мастера происходит.

[109.livejournal.com]

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