Простой протокол синхронизации для массива объектов - PullRequest
Новая
       41

Простой протокол синхронизации для массива объектов

0 голосов
/ 27 января 2019

Я ищу протокол или стандарт, подходящий для следующих требований:

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

Я провел несколько часов и столкнулся с проблемой, потому что нашел много сложных решений, таких как Paxos и Raft, которые требуют сетевой инфраструктуры.

Мое предложение

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

Архитектура.

Клиенты

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

Хранение данных

У нас есть одно хранилище данных, такое как AWS / Dropbox / Google Drive / Размещенные файлы, не имеет значения, важно, что нет доступа к таким продвинутым и мощным инструментам, как casandra. Есть два файла: текущие данные - это может быть сериализованный файл JSON или SQLite, который регистрирует это как файл с историей всех операций, отсортированных по отметке времени.

Точка доступа

У нас есть одна точка доступа к этим данным. Бессерверный блок со следующими задачами: получать локальные журналы от клиента, объединять их с глобальными журналами, обрабатывать их для обновления глобальных текущих данных, отправлять клиенту инструкцию о локальном изменении, которое должно применяться.

enter image description here

Обработка

Давайте рассмотрим следующий сценарий. Клиент изменяет локальные данные и добавляет любые изменения в локальные журналы.

Средства синхронизации. Тот 1) Клиент отправляет локальные журналы в точку доступа (сервер). Сервер создает пустой файл .lock, чтобы предотвратить изменение с других точек доступа. Если файл существовал ранее, синхронизация отклоняется. Сервер ищет дату последней синхронизации, сохраненную в локальном журнале. Затем загрузите журналы из хранилища и получите любые строки с даты последней синхронизации до настоящего времени. Сервер смешивает их и вычисляет две вещи: а) как обновлять глобальные текущие данные, б) как обновлять локальные текущие данные этого клиента. Затем на сервер загружают глобальные данные, применяют модификацию. Отправьте клиенту локальные инструкции по модификации. И удаляет файл .lock. Клиент применяет модификации, модифицирующие локальное состояние, удаляет локальные журналы и сохраняет в них дату последней синхронизации.

Исключения / Слияние

Теперь изображение, что два клиента удалили один и тот же элемент. Это должно быть удалено. Идентификатор случайный, поэтому два клиента не могут создавать два элемента с одинаковым идентификатором. Если в любом случае будет создан, второй действует и его создание изменяется на обновление. Если два клиента обновляют один и тот же ресурс, мы должны посмотреть на его структуру. Я упоминал о представлении JSON. Так что это коллекция ключей и значений. Следует применять следующую стратегию: 

First version         {a:1, b:2, c:3}
Update form client 1: {a:4, b:2, c:3}
Update from client 2: {a:1, b:5, c:3}
Merged version        {a:4, b:5, c:3}

Поскольку дата последнего изменения рассчитывается для любого объекта недвижимости самостоятельно.

Когда во время обработки исключений сервер останавливается и .lock не будет удален, система останавливает синхронизацию и требует ручного исправления.

Мои вопросы:

  • где я могу найти решения с открытым исходным кодом, аналогичные представленным?
  • Существуют ли протоколы, стандарты, которые мне следует изучить?
  • что мне ввести в Google / Duckduck, чтобы найти его?

Тема по теме с 2009 года.

Шаблон / алгоритм синхронизации клиент-сервер?

  • был svn, рекомендуется cvs

, но из-за CVS был заменен SVN, SVN на GIT . Стоит ли использовать GIT для синхронизации, подобной этой?В википедии системы контроля версий считаются «требующими больших затрат».

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

...