посоветуйте шаблон или статью по построению распределенного веб-приложения. Теоретическая задача, как обеспечить работоспособность филиала если пропал интернет, и доступ к основному веб-приложению нет. Пока что придумал запускать по копии приложения в каждом филиале, и вести работу автономно когда нет инета, и синхронизировать данные когда связь появляется. Условно заливать в каждый терминал по Docket контейнеру, и по расписанию синхронизировать данные с мастером.
Это нормальный подход? Есть возможность и резервных каналов, но хочется добиться абсюлютной high availability в такие моменты, чтобы бизнес не останавливался, если всерезервные каналы накрылись и связи с внешним миром нет.
Ниже уже озвучили основные тезисы. Еще добавлю что самый простой способ это репликация бд, если падает связать с сервером переключаетесь на локальную бд и переходите в режим чтения. как правило нет требования 100%го онлайна, есть требование доступа к данным.
Хотя если есть возможность потратить N времени на разработку меанизма слияния, включающего решение конфликтов то дело хорошее.
Добавлю, если писать требуется чаще, чем читать, то делайте раздельные данные, например база на филиал (или отдельные таблицы). Каждый филиал пишет в свои таблицы для записи, основные справочники общие на чтение.
И еще, если вдруг запись изменилась сразу с разных мест, то делайте рапределенные псевдо-транзакции, во все основные таблицы добавьте поле version и увеличивайте его на единицу программно или ставьте таймстемп или просто уникальное число (но не автоинкрементом!). Тогда при объединении данных, просто проверяйте, что version равен у обновленных и старых данных, иначе откатывайте транзакцию и разбирайте руками. Это называется оптимистическими блокировками - https://en.wikipedia.org/wiki/Optimistic_concurren...
О CAP теореме слышали?
Вы хотите иметь доступность и устойчивость к разделению, следовательно, вы должны отказаться от консистентности. См. AP-системы.
Нормальный ли подход - зависит от задачи, нужно рассматривать конкретную ситуацию и конкретный бизнес. Если ограничения целостности позволяют, то да, нормальный. План слияния и решения конфликтов только заранее описать.
Простой
Простой
