Каков современный стандарт программирования для синхронизации данных между веб-сервисом и клиентом?
Вопрос немного общий, поэтому, чтобы помочь сузить фокус, я поделюсь своей текущей настройкой, которая мотивирует этот вопрос. У меня есть веб-сервис LAMP под управлением RESTful API. У нас есть две реализации клиента: один клиент на основе браузера javascript (локальное хранилище) и один клиент на базе iOS (основное хранилище данных). Очевидно, что эти два клиента хранят данные очень по-разному, но сами данные должны быть синхронизированы с удаленным сервером как можно чаще.
В настоящее время наш процесс синхронизации немного туповат (как, например, не умный). Концептуально это выглядит так:
- Клиент периодически запрашивает у ВСЕХ самые последние данные.
- Сервер отправляет удаленные данные, которые перезаписывают текущий набор локальных данных в хранилище клиента.
- Любые локальные создания / обновления / удаления после этой точки считаются золотыми и немедленно отправляются на сервер.
Сами данные хранятся реляционно и периодически обновляются пользователями-клиентами. Клиенты в моем конкретном случае не слишком заботятся о самих отношениях (вот почему мы можем сейчас уйти с локальным хранилищем в клиенте браузера).
Очевидно, это не настоящая синхронизация. Я хочу перейти к системе, в которой концептуально "diff" из самых последних изменений периодически отправляется на сервер, и сервер отправляет обратно "diff" из самых последних изменений, о которых он знает. Кажется, очень трудно добраться до этой точки, но, возможно, я просто не очень хорошо понимаю проблему.
REST кажется хорошим началом, но REST говорит только о том, как два хранилища данных общаются друг с другом, а не о том, как сами данные синхронизируются между ними. (Этот процесс синхронизации оставлен на усмотрение исполнителя каждого хранилища.) Как лучше всего реализовать этот процесс? Существует ли современный набор шаблонов проектирования программ, которые применяются для обоснования конкретного решения этой проблемы? В основном меня интересует общий (независимый от технологии) подход, если это возможно... но на конкретные структуры тоже было бы полезно взглянуть, если они существуют.
4 ответа
Репликация с несколькими хозяевами всегда (и всегда будет) трудна и сделана на заказ, потому что способ обработки конфликтов будет зависеть от вашего приложения.
IMO Более надежный подход состоит в том, чтобы использовать репликацию "ведущий-ведомый", когда ваша веб-служба является главным, а клиенты - ведомыми. Чтобы синхронизировать клиентов, используйте архивную информацию об изменениях (см. Источник событий) в соответствии с RFC5005. Это самый близкий к современному стандарту для этого типа репликации доступ, и он RESTful.
Когда клиенты подключены к сети, они не обновляют свою реплику напрямую, а отправляют команды на сервер и обновляют свою реплику через канал Atom.
Когда клиенты не в сети, все становится сложнее. У ваших клиентов должна быть модель поведения вашего веб-сервиса. Для этого потребуется автономная копия вашей реплики, которую следует копировать при записи из онлайн-реплики (онлайн-реплика обновляется фидом Atom). Когда клиент выполняет команды, которые изменяют данные, он должен сохранить команду (для последующего воспроизведения для веб-службы), ожидаемый результат (для проверки во время воспроизведения) и обновить автономную реплику.
Когда клиент возвращается в оперативный режим, он должен воспроизвести команды, сравнить результат с ожидаемым результатом и уведомить клиента о любых отклонениях. То, как обрабатываются эти отклонения, зависит от вашего приложения. Оффлайн реплика может быть отброшена.
Репликация CouchDB работает по HTTP и делает то, что вы ищете. Как только базы данных синхронизируются на обоих концах, они будут отправлять различия для добавления / обновления / удаления.
Couch может сделать это с другими компьютерами Couch или с мобильной платформой, такой как TouchDB.
https://github.com/couchbaselabs/TouchDB-iOS
Я сделал довольно много, но вы всегда можете настроить CouchDB на одном компьютере, настроить TouchDB на мобильном устройстве, а затем наблюдать, как HTTP-трафик движется взад-вперед, чтобы понять, как они это делают.
Или прочитайте это: http://guide.couchdb.org/draft/replication.html
Возможно, что-то из приведенной выше ссылки поможет вам понять, как сделать ваши собственные сравнения для вашего сервиса REST. (Так как они оба по HTTP думали, что это может быть полезно.)
В последнее время меня интересует Метеор.
Платформа настраивает Mongo на сервере и минимонго в браузере. Клиент подписывается на некоторые данные, и когда эти данные изменяются, платформа автоматически отправляет новые данные клиенту.
Это умное решение проблемы синхронизации, а также решение нескольких других проблем. Будет интересно посмотреть, будут ли другие платформы делать это в будущем.
Вы можете заглянуть в API Dropbox Datastore:
https://www.dropbox.com/developers/datastore
Похоже, это может быть очень хорошо подходит для ваших целей. У них есть клиенты iOS и JavaScript.