Подскажите алгоритм синхронизации массива строк в javascript с хранимыми на серевере строками в mySQL. Как синхронизировать несколько компьютеров с сервером

Question

[imater]

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

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

Какие современные технологии репликации применить?

Пока алгоритм видится так:
1. Ведём журнал изменений, где записываем время и id строки, которая изменилась. (при этом возникает вопрос синхронизации часов на всех компьютерах пользователя, а это непосильно)
2. При синхронизации, отправляем на сервер уникальный код устройства, и последнее время успешной синхронизации.
3. Все записи изменившиеся по журналу после времени последней успешной синхронизации, отправляем клиенту для обновления.
4. Клиент смотрит, если он сам менял данные из этих изменившихся позднее сервера, он оставляет себе свои свежие данные и отправляет на сервер команду изменить данные сервера на свои свежие.
5. Клиент выделяет все свежие данные по собственному журналу изменений и отправляет их на сервер.
6. Периодически опрашивать сервер: Были ли изменения после успешной синхронизации моего кода устройства, если были, то повторить шаги.
7. Если изменений слишком много, либо время сильно рассинхронизированно, либо клиент новый, то сервер отправляет все свои данные клиенту, а клиент отправляет свои данные серверу. Оба записывают в свои журналы изменений свежую дату успешной синхронизации.

Ответ можно написать в виде примерного алгоритма на русском языке.

Answer 1

[Павел Тысляцкий]

Данные:
1. Время синхронизации брать с сервера.
2. На клиенте хранить собственно данные, последнее время синхронизиции (прислонное с сервера) и id данных, измененных после последней синхронизации. Если данные еще нет, то последнее время синхронизации принимаем за 0.
3. На сервере хранить данные с дополнительным полем last_update или журнал изменения (отдельная таблица) с временем изменения и id записи (В любом случае такой журнал можно сжать до размера самих данных, удалив старые дубликаты id).
Описание:
1. Клиент стучится на сервер отправляю последнее время синхронизации и изменненые данные после последней синхронизации.
2. Сервер сохраняет данные если не было конфликтов, и возвращает обновленные данные после последнего пользовательского обноновления (можно без пользовательских обновлений), новую дату обновления. А клиент обновляет данные и удаляет отосланные id записей после синхронизации.
3. Если были конфликты (дата последнего изменнения пользователя меньше последнего изменения на сервере и хеши данных отличаются), то можно отложить обновление и передать пользователю данные для мержа, при этом обновив last_update таких записей до даты синхронизации возвращаемой пользователю. После чего пользователь снова синхронизируется. Если опять возник конфликт, то повторять до тех пор, пока не разрешится.
Запрос:
{time: , data: []}
Ответ:
{time: , data: [], mergeData: []}
Замечания:
Те localStorage хранит до 5 метров по спецификации, то возможно не стоит заморачиваться по поводу большого объема данных. Хотя можно добавить на сервер метод, который будет возвращать количество обновлений в байтах по последнему времени изменений и завязать дополнительную логику. Если данных больше 5 мб, то стоит использовать indexed db или web sql (привет ie 8 и 9), но в браузерах реализован асинхронный API.

Answer 2

[mark_ablov]

Я бы со временем не возился, а каждой версии данных лепил бы тег в виде хэша от данных.

Comments

[imater]

И нужно будет каждый раз отправлять хэши ВСЕХ данных серверу для сравнения? В принципе не очень страшно, там будет около 10 000 строк.

[imater]

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

[balloon]

Я бы в принципе для синхронизации использовал только время изменения в базе. Т.е. при загрузке клиент получает данные со временем их последнего изменения (для каждой строки). Клиент уходит в офлайн. При возвращении в онлайн, он отправляет время изменений и в ответ получает либо обновленные данные, либо ответ, что ничего не поменялось, и он может смело отправлять свои локальные изменения.

Answer 3

[1nd1go]

Есть couchdb, который специально для синхронизации данных и затачивался (если мобильник например долго вне зоны действия сети). Там каждому обхекту присваивается id. Дальше вставка идет по optimistic locking — предложили, если id одинаковый — записываем, если разные падаем и предлагаем пользователю самому решать.

Answer 4

[OCTAGRAM]

Чтобы не вести детальные журналы, в MySQL можно добавить столбцы типа TIMESTAMP, они автоматически обновляются при INSERT и UPDATE.

DELETE, правда, всё же придётся журналировать