У тебя большая проблема. Я думаю, что то, как вы думаете о проблеме, является большей проблемой. Давайте рассмотрим некоторые основы.
Кластеризация используется для решения больших проблем, очень похожих на задачу «съесть слона». Вы можете решить эту проблему, сконструировав уникального крупного хищника с огромной пастью. Но история и палеонтология показали нам, что крупных хищников нелегко поддерживать (они дорого обходятся окружающей среде).
Итак, чтобы решить вашу проблему, вы можете взять более мощный сервер.
Или вы можете использовать кластеризацию.
Кластеризация решает проблему «съесть слона» совершенно по-другому. Вместо того, чтобы отправлять уникального огромного хищника с огромным ртом, чтобы съесть слона, он будет использовать концепцию распределенной и общей обработки, чтобы есть его по кусочку за раз. Если все сделано правильно, муравьи могут съесть слона. Если их достаточно и обстоятельства правильные.
Но обратите внимание, в моем примере муравьи очень маленькие... Один муравей никогда не понесет всего слона. Вы могли бы нести всего слона, если бы все муравьи работали вместе, но тогда вы столкнетесь с проблемами параллелизма и блокировки (вы должны координировать муравьев).
Муравьи показали нам гораздо лучший способ справиться с этим. Они возьмут часть слона и решат проблему небольшими порциями.
В вашей системе вы спрашиваете, как вы можете синхронизировать данные между узлами... Мой вопрос: почему? Если вы синхронизируете данные, то вы зеркалируете, и ваша проблема становится еще больше (вы клонируете слона, но можете съесть только оригинал).
Решение вашей проблемы заключается в том, чтобы переосмыслить решение и посмотреть, сможете ли вы разбить проблему на более мелкие части.
В Akka и в паттерне Актер лучший способ решения проблем — использовать меньшие «процессы» (один муравей). Хотя этот процесс сам по себе почти бесполезен, при использовании в больших масштабах они могут стать очень мощными. Когда архитектура будет сделана должным образом, вы заметите, что бросив огнемет к муравьям, вы не победите их... Придут другие муравьи, они продолжат работать над проблемой.
Копирование и синхронизация данных — это не ваше решение, а кластеризация. Вы должны взять свои данные и разбить их до такой степени, чтобы вы могли передать их одному муравью. Если вы можете это сделать, вы можете использовать Akka. Если такой подход кажется нелепым, то Akka не для вас.
Но подумайте об этом... Очевидно, у вас есть опасения по поводу серверной части вашей базы данных - вы не хотите увеличивать количество операций ввода-вывода и создавать единую точку отказа. Я должен был бы согласиться с вами. Но вам нужно переосмыслить вещи. У вас может быть зеркальное отображение базы данных, чтобы устранить единую точку отказа, но вы правы, что это не устранит узкое место. Предположим, что зеркало устраняет единственную точку отказа... Теперь давайте приступим к узкому месту.
Если вы можете разделить свои данные на достаточно маленькие фрагменты, чтобы муравьи могли с ними справиться, я бы настоятельно призвал вас сказать вашим муравьям сообщать в базу данных только при изменении данных... Вы можете прочитать его один раз при инициализации (вам нужен бэкэнд). храни, не обманывай себя, электричество можно быстро потерять... его надо где-то хранить) но если вы скажете своим муравьям сохранять только измененные данные, то вы уберете все запросы из уравнения, что резко сместит нагрузку исходит из. Когда у вас есть только обновления, вставки и удаления, все становится намного проще.
Кластеризация должна быть решением для вас, но только если вы сможете выбросить из головы концепцию зеркала.
Узлы кластера могут и будут падать... Но их можно возродить в другом месте на других узлах, так что у вас всегда будет быстрая система. Только когда вы имеете дело со сбоем или потерей узла/рабочего процесса/муравья, вам придется перезагружать данные...
Удачи ... вы обрисовали в общих чертах огромную проблему, которую, как я видел, люди со степенью инженера-программиста не смогли решить.
person
Karell Ste-Marie
schedule
17.11.2016
