Разработка приложений кластера

Question

Я не уверен, где именно (или даже как именно задать) этот вопрос, поэтому я надеюсь, что кто-то здесь может указать мне в правильном направлении.

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

Я хотел бы увеличить эту услугу. Я рассмотрел такие решения, как akka.net (модель актера), и у них есть решение для кластеризации. Из того, что я прочитал, он синхронизирует состояние с тем, что они называют «сплетнями», где каждый узел отправляет состояние другому узлу. Я не уверен, что на данный момент можно превратить мое рабочее приложение в akka.net.

Мне интересно, как кластеры сохраняют синхронизацию состояний между различными узлами (я получаю концепцию сплетен), что произойдет, если у меня есть машина A, которая получает сообщение, и в то же время машина B также получает сообщение - оба изменить одно и то же состояние объекта - это вызовет проблемы с целостностью данных между состояниями. Моя единственная мысль об этом - заблокировать общий ресурс, но это побеждает цель кластера.

Сохранение состояния в базе данных также не является вариантом, поскольку база данных становится узким местом и одной точкой отказа.

Я не могу найти подходящие материалы для чтения в Интернете, но мне также не хватает технических фраз, на которые мне нужно сосредоточиться.

В случае, если это имеет значение, я использую .NET Core и C# для разработки.

Может ли кто-нибудь объяснить концепцию кластеризации, ее работу и убедиться, что узлы находятся в синхронизации? или может указывать на правильное направление?

Answer 1

У вас есть большая проблема. Я думаю, что то, как вы думаете о проблеме, представляет собой большую проблему. Давайте рассмотрим некоторые основы.

Кластеризация используется для решения больших проблем, как проблема «съесть слона». Вы могли бы решить эту проблему, создав уникального крупного хищника с огромным ртом. Но история и палеонтология показали нам, что большие хищники нелегко выдерживают (они дороги в окружающей среде).

Чтобы решить вашу проблему, вы можете взять более сильный сервер.

Или вы можете использовать кластеризацию.

Clustering решает проблему «съесть слона» совершенно по-другому. Вместо того, чтобы посылать уникального огромного хищника с огромным ртом, чтобы съесть слона, он будет использовать концепцию распределенной и совместной обработки, чтобы съесть один укус одновременно. Когда все будет сделано правильно, муравьи могут съесть слона. Если их достаточно, и обстоятельства верны.

Но обратите внимание, что в моем примере муравьи очень маленькие ... Один муравей никогда не будет носить весь слон. Вы могли бы нести весь слон, если бы все муравьи работали вместе, но затем вы сталкивались с проблемами параллелизма и блокировки (вы должны координировать муравьев).

Муравьи показали нам гораздо лучший способ справиться с этим. Они возьмут кусок слона и справятся с проблемой в небольших кусках.

В вашей системе вы спрашиваете, как вы можете синхронизировать данные по узлам ... Мой вопрос был бы почему?Если вы синхронизируете данные, тогда вы зеркалируете, и ваша проблема становится еще больше (вы клонируете слона, но можете есть только оригинал).

Решение проблемы заключается в том, чтобы переосмыслить решение и посмотреть, можете ли вы решить проблему на более мелкие куски.

В Акке и в шаблоне Актера лучший способ справиться с проблемами - использовать более мелкие «процессы» (один муравей). Хотя сам процесс практически бесполезен, когда он используется в больших масштабах, они могут стать очень мощными. Когда архитектура будет правильно сделана, вы заметите, что захват огнеметов муравьям не победит их ... Больше муравьев придет, они будут продолжать работать над проблемой.

Копирование и синхронизация данных - это не ваше решение, кластеризация. Вы должны взять свои данные и разбить их до такой степени, что вы можете дать его одному мужу. Если вы можете это сделать, вы можете использовать Akka. Если этот подход кажется смехотворным, то Акка не для вас.

Но рассмотрите это ... У вас, очевидно, есть проблемы с базой данных базы данных - вы не хотите увеличивать IO и вводить одну точку отказа. Я должен согласиться с тобой. Но вам нужно переосмыслить все. Вы могли бы зеркалировать базы данных для удаления единственной точки отказа, но вы правы, что это не устранит узкое место. Итак, скажем, что зеркало удаляет единственную точку отказа ... Теперь давайте атакуем часть узкого места.

Если вы можете разделить свои данные на достаточно мелкие кусочки, с которыми муравьи могут справиться с этим, я настоятельно призываю вас сообщить вашим муравьям только сообщать в базу данных при изменении данных ... Вы можете прочитать ее один раз при инициализации (вам нужен бэкэнд-магазин, не обманывайте себя, электричество может быть быстро потеряно ... его нужно где-то сохранить), но если вы сообщите своим муравьям о сохранении только измененных данных, вы удалите все запросы из уравнения, которое будет резко сдвиг, откуда приходит груз. Когда у вас есть только обновления, вставки и удаления, чтобы иметь дело с ... весь ландшафт будет намного проще.

Кластеризация должна быть для вас решением, но только если вы можете отказаться от концепции зеркала от своего ума.

Узлы кластера могут и будут разбиваться ... Но они могут быть возрождены в другом месте на другие узлы, так что у вас всегда есть быстрая система. Если вы столкнулись с крахом или потерей узла/рабочего процесса/муравья, вам придется перезагрузить данные ...

Удачи ... вы наметили огромную проблему, что я видел людей с степенями программного обеспечения терпят неудачу при разрешении.