Простая парадигма построения отказоустойчивых распределенных приложений
Идея разделить систему на реплицируемую и не-реплицируемую часть применима очевидно не только к Веб-приладам.
При этом реплицируемую можно разделить на персистентную и не-персистентную.
Нереплицируемая часть неперсистентна, т.е. не переживает сбои. Зато она может быть распределенной, т.е. ее акторы могут быть распределены по разным нодам.
Реплицируемую часть разумно выделить в отдельную подсистему, обслуживаемую специальными протоколами, обеспечивающими репликацию.
Такой подход имеет некоторые преимущества, а именно в том, что реплицируемо-персистентную часть можно сделать на основе упрощенной модели данных, которую либо удобно прозрачно реплицировать, либо можно преодолеть сложности один раз и повторно использовать в других приложениях. Хороший вариант - key value store типа Redis.
В результате программирование не-реплицируемой части не зависит от специальных ограничений, упрощающих репликацию и персистенцию.
Другой вариант модели данных - простые ДБ таблицы.
Интерфейс к реплицируемой части можно сделать в разных вариантах:
1 запрос идет к одному из специальных процессов реплицируемой подсистемы, как вариант ответ может приходить от другого процесса
2 на каждом не-реплицируемом процессе есть специальный актор для связи с реплицируемой подсистемой
3 есть также вариант коммуникации от клиента к группе (возможен в некоторых библиотеках)
Конечно такой вариант не самый оптимальный по производительности, но по видимому самый простой
При этом реплицируемую можно разделить на персистентную и не-персистентную.
Нереплицируемая часть неперсистентна, т.е. не переживает сбои. Зато она может быть распределенной, т.е. ее акторы могут быть распределены по разным нодам.
Реплицируемую часть разумно выделить в отдельную подсистему, обслуживаемую специальными протоколами, обеспечивающими репликацию.
Такой подход имеет некоторые преимущества, а именно в том, что реплицируемо-персистентную часть можно сделать на основе упрощенной модели данных, которую либо удобно прозрачно реплицировать, либо можно преодолеть сложности один раз и повторно использовать в других приложениях. Хороший вариант - key value store типа Redis.
В результате программирование не-реплицируемой части не зависит от специальных ограничений, упрощающих репликацию и персистенцию.
Другой вариант модели данных - простые ДБ таблицы.
Интерфейс к реплицируемой части можно сделать в разных вариантах:
1 запрос идет к одному из специальных процессов реплицируемой подсистемы, как вариант ответ может приходить от другого процесса
2 на каждом не-реплицируемом процессе есть специальный актор для связи с реплицируемой подсистемой
3 есть также вариант коммуникации от клиента к группе (возможен в некоторых библиотеках)
Конечно такой вариант не самый оптимальный по производительности, но по видимому самый простой