Здравствуйте, __SPIRIT__, Вы писали:
__S>Очень сложная конструкция. Большая вероятность ошибок из-за постоянного мержа состояний. Неустранимые проблемы с выходом ноды в офлайн. Самое неприятное, когда авария на магистрали и локальная нода доступна пользователям, а вся система нет.
1. Надо обеспечить HA каждой ноды. Т.е. ситуации, что в локальную ноду загрузили данные, а она умерла, не успев синхронизоваться с остальными, быть не должно. На пальцах: локальная "нода" — трёхмашинный кластер, коммит в который требует кворума 2/3. Вероятностью split brain в локальном кластере можно пренебречь.
2. Надо обеспечить более-менее избыточное подключение региональной ноды к интернету. Штука не очень нужная, т.к. современные магистрали как правило лежат редко, а чинятся — быстро. Найти точку на карте интернета, которая может остаться без связи с большой землёй на 48 часов — это какая-то экзотика в труднодоступных местах. Если вам повезло иметь ноду в таком месте, то купите резервный канал. GPRS через другого провайдера, спутник, что угодно.
__S>Не понятно что делать с одновременным изменением одной сущности на разных нодах
Это отдельный большой вопрос. Я знаю три стратегии:
1. Pessimistic locking. Т.е. перед началом изменения мне нужно захватить блокировку на объект, которая получается путём кворума.
2. Разрешение конфликтов.
3. Workflow-based locking. Это разновидность п.1. — когда у документа всегда есть единственный owner, и передача права на редактирование происходит при репликации. При этом забрать право нельзя — можно только отдать.
__S>Долгий апдейт, если на одну ноду загрузили 100Гигов, другие ноды получат данные очень не скоро.
С этим придётся смириться. Это интернет, детка (tm). Альтернатива — одеа центральная нода. Те же 100 гигов до неё доедут очень нескоро — по ровно той же причине. Введение региональных нод позволяет хотя бы местным пользователям оперативно насладиться 100 гигами.
__S>Очень большой уровень дублирования. Большая часть данных дублируется бессмысленно, они просто не будут использованы. Не оптимально
4. Это решается только семантически. Т.е. вы должны уметь хорошо предсказывать, какие данные будут не нужны локальному пользователю. В общем случае — неразрешимо, т.к. если есть возможность порезать связи данных, то вы сразу получаете набор локальных самодостаточных приложений. Которые могут обмениваться какой-то общей информацией, но только в специальных случаях. Ну, типа локальный офис торгует со своего склада; в тех редких случаях, когда нужного товара на локальном складе нет, мы делаем запросы к коллегам и инициируем дорогостоящий процесс перемещения между складами. Если локальных офисов слишком много, то мы можем завести глобальную базу остатков для ускорения поиска — и все будут реплицироваться в неё. Опять таки, решение построено на доскональном знании не только предметной области, но и относительных частот различных сценариев. Получить обобщённый вариант такого решения не представляется возможным.
__S>Это навскидку, уверен проблем будет больше.
Альтернатив, по большому счёту, нету никаких. Либо 1 центральная нода — страдаем от проблем ширины и надёжности канала к ней. Либо локальные ноды = страдаем от проблем ширины и надёжности канала между ними
Чем кончилось-то?
Здравствуйте, Sinclair, Вы писали:
S>Чем кончилось-то?
замыслы не получилось претворить в жизнь. Могу рассказать что я хотел, но без реального опыта. В реальности же появился "гуру", а дальше как в сказке — "чем дальше тем страшнее"...
Чтобы не быть голословным, рассказывая про сказку. После того как гуру родил дизайн на основе патерна God object, и начал имплементацию методом copy/paste. Он между делом родил свой Razor, основанный на строковых вьюшках в контроллере и массовых реплэйсах... Какой там нахер балансинг...
Даже банальные IoC, Unit testing и линк пошли лесом(с мотивацией что без них жили и все было ок).
Наверное, уже не актуально, поэтому добавлю для истории пример архитектуры из текущего проекта:
1. Да, региональные узлы. Главная причина, как ни странно, не технологическая, а правовая — законы о персональных данных, требующие в некоторых странах (Россия, Китай) хранить их локально.
2. Микросервисы. Поскольку разные куски функционала отделены друг от друга физически, это хорошо помогает сохранить слабо связанную архитектуру и делать оптимизации в каждом конкретном случае отдельно, по задаче. Клиентские приложения ходят в микросервисы через API GW и балансировщик.
3. Шардинг — для региональных данных, плюс кэширование на ближайших к клиенту узлах, плюс асинхронная обработка ближайшим к клиенту узлом запросов на изменение. Превентивное кэширование пока не используется. Блокировки — оптимистические (специфика системы позволяет).
4. Репликация — фактически только для словарей.
Здравствуйте, __SPIRIT__, Вы писали:
__S>Очень сложная конструкция. Большая вероятность ошибок из-за постоянного мержа состояний.
__S>Не понятно что делать с одновременным изменением одной сущности на разных нодах
С этим
CRDT может помочь
Здравствуйте, __SPIRIT__, Вы писали:
Есть так называемая
CAP-теорема. Выбирайте тот компромисс, который вам больше подходит.
Ну и еще пару мыслей: если решитесь на шардирование-репликацию по регионам, то тут либо асинхронность, либо тормоза до нескольких минут на каждый синхронный апдейт.
Если нужен мультимастер — то такое умеет кассандра.
Покрутите ивент сорсинг, вполне возможно он несколько облегчит обработку конкурентного апдейта
Ну и надо проектировать систему так, чтобы минимизировать число конкурентных апдейтов. Идеально если получится шардировать и каждый шард привязать к региону.
