Каков современный стандарт программирования для синхронизации данных между веб-сервисом и клиентом?

Question

Вопрос немного общий, поэтому, чтобы помочь сузить фокус, я поделюсь своей текущей настройкой, которая мотивирует этот вопрос. У меня есть веб-служба LAMP, использующая API RESTful. У нас есть две клиентские реализации: один браузер на основе javascript-клиента (локальное хранилище) и один клиент на базе iOS (хранилище основных данных). Очевидно, что эти два клиента хранят данные по-разному, но сами данные должны храниться в двухсторонней синхронизации с удаленным сервером как можно чаще.

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

• Клиент периодически запрашивает сервер для ВСЕХ самых последних данных.
• Сервер отправляет удаленные данные, которые перезаписывают текущий набор локальных данных в хранилище клиента.
• Любое локальное создание/обновление/удаление после этой точки рассматривается как золото и немедленно отправляется на сервер.

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

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

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

Answer 1

Репликация CouchDB работает через HTTP и делает то, что вы ищете. После того, как базы данных будут синхронизированы с обоих концов, он отправит diffs для добавлений/обновлений/удалений.

Кушетка может делать это с помощью других автоматов Couch или с мобильным каркасом, таким как TouchDB.

https://github.com/couchbaselabs/TouchDB-iOS

Я сделал изрядное количество, но вы всегда можете настроить CouchDB на одной машине, установить TouchDB на мобильном устройстве, а затем смотреть HTTP трафик туда и обратно, чтобы получить идея того, как они это делают.

Или прочитать: http://guide.couchdb.org/draft/replication.html

Может быть что-то из приведенной выше ссылки поможет вам получить представление о том, как сделать свои собственные различия для вашей службы REST. (Так как они оба по HTTP считали, что это может быть полезно.)

Answer 2

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

IMO Более надежный подход заключается в использовании репликации Master-slave, а ваш веб-сервис - как мастер, так и клиенты как подчиненные. Для того, чтобы сохранить клиент в синхронизации, используйте архивный канал атомных изменений (см event sourcing) как на RFC5005. Это ближайшее вы получите современный стандарт для этого типа репликации и это RESTful.

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

Когда клиенты в автономном режиме становятся все труднее. Вашим клиентам потребуется модель как ваш веб-сервис будет вести себя. Он должен будет иметь автономную копию вашей реплики, которая должна быть copied on write из онлайн-реплики (онлайн-реплика - это то, которое обновляется с помощью подачи Atom). Когда клиент выполняет команды tha t изменить данные, он должен сохранить команду (для последующего воспроизведения против веб-службы), ожидаемый результат (для проверки во время воспроизведения) и обновление автономной реплики.

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

Answer 3

Вы можете посмотреть в API Dropbox Datastore:

https://www.dropbox.com/developers/datastore

Это звучит, как это может быть очень хорошо подходит для ваших целей. У них есть клиенты iOS и javascript.

Answer 4

В последнее время меня интересует Meteor.

Платформа устанавливает Mongo на сервере и minimongo в браузере. Клиент подписывается на некоторые данные, и когда эти данные изменяются, платформа автоматически отправляет новые данные клиенту.

Это умное решение проблемы синхронизации, и оно решает и другие проблемы. Будет интересно посмотреть, смогут ли другие платформы сделать это в будущем.