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

Я смотрю на создание моего первого мобильного приложения. Одной из основных функций приложения является то, что несколько устройств / пользователей будут иметь доступ к одним и тем же данным - и все они будут иметь права CRUD.

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

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

1. Пользователь А не в сети и редактирует запись # 100
2. Пользователь B не в сети и редактирует запись # 100
3. Пользователь C не в сети и удаляет запись # 100
4. Пользователь C выходит в сеть (предположительно, запись № 100 должна быть удалена на сервере)
5. Пользователь A и B выходит в сеть, но отредактированные записи больше не существуют.

Все виды сценариев, подобных вышеупомянутому, могут придумать.

Как это вообще обрабатывается? Я планирую использовать MySQL, но мне интересно, если это не подходит для такой проблемы.

В настоящее время я работаю над мобильным / настольным / распределенным приложением с точно такими же требованиями и проблемами.

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

Обычно все сводится к тому, что у вас есть потенциальная запись данных, которая распространяется среди n клиентов, которые могут редактировать ее одновременно. Что вам нужно

1. правильный механизм контроля версий / блокировки,
2. правильное управление правами / доступом,
3. правильная стратегия синхронизации / кэширования

Для (1) вы можете применить несколько шаблонов: есть две часто используемые стратегии блокировки: оптимистическая автономная блокировка и пессимистическая автономная блокировка . Некоторые из них применяются в различных «шаблонах» управления версиями, таких как MultiVersion Concurrency Control (MVCC), который использует счетчик (своего рода очень простая «отметка времени») для каждой записи данных, которая обновляется при каждом изменении записи ,

(2) и (3) сами по себе очень широкие вопросы, которые необходимо решать независимо от (1). Несколько советов из моего опыта:

• Используйте технологию клиент-сервер, которая устраняет большинство проблем для вас. Я настоятельно рекомендую некоторые веб-технологии, такие как CouchDb , которые обрабатывают (1) с помощью Optimistic Offline Locking + MVCC, (2) через Web API и (3) с помощью кэширования Http очень хорошо.

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

• Попробуйте использовать однородные технологии, если это возможно. Под «однородным» я подразумеваю технологии, разработанные с учетом тех же принципов, например, сценарии использования web 2.0. Пример: использование правильного CouchDb и REST Client (веб-API) со стратегией локального кэширования - лучший выбор, чем использование SQL для мобильных приложений.

• Я настоятельно рекомендую не использовать MySQL, потому что это технология, которая явно не была создана для таких сценариев использования. Это работает, но вам гораздо лучше с системой баз данных, которая уже охватывает веб-коммуникацию и стиль параллелизма (например, многие базы данных NoSQL).

Кстати, я остановился на CouchDb с пользовательским локальным клиентом, работающим с API-интерфейсами CouchDb, который работает и прекрасно масштабируется. Я отказался от использования MSQL + (N) Hibernate и заплатил высокую цену за то, что не сделал правильный выбор (то есть, не проводил достаточно исследований).

Во-первых, вы упомянули как API, так и базу данных (MySQL). Я очень рекомендую вам использовать API и не пытаться связываться напрямую между базами данных. Этот последний маршрут не будет хорошо масштабироваться вообще.

Хорошей отправной точкой, которую вы должны рассмотреть, является использование Apache CouchDB . Он не содержит схем, основан на HTTP и JSON и обладает очень хорошим механизмом репликации. Мы используем его для решения аналогичной проблемы.

Механизм репликации CouchDB использует тот же HTTP API, что и любой другой клиент. По сути, он обеспечивает репликацию через API.

Для iOS я рекомендую использовать проект Couchbase Lite . Это очень хорошо работает для синхронизации данных. Для Android та же компания, которая делает вышеупомянутый проект Couchbase Lite, работает над аналогичным предложением - Couchbase Lite для Android . Он не такой полный, как версия для iOS, и ему еще предстоит проделать определенную работу.

Однако есть несколько вещей, которые следует учитывать в CouchDB.

1. Вам нужно будет предоставить собственное разрешение конфликта. К счастью, если возникают конфликты, CouchDB сохраняет конфликтующие версии и выборки, а также произвольный, но детерминированный конфликт в качестве основной версии. Таким образом, вы можете рассмотреть возможность отсрочки разрешения конфликта для вашей первоначальной версии.
2. Механизм репликации предназначен для репликации баз данных, а не для синхронизации как таковой. Поэтому, если у вас есть много удаленных документов, ваша репликация с сервера на клиент займет больше времени. Есть способ избежать этого, используя «ротацию базы данных». Это по существу удаляет старые удаляет.
3. Вы не можете контролировать порядок репликации. Однако вы можете сделать несколько умных решений для повышения производительности репликации, например, использовать отфильтрованную репликацию, чтобы сначала получить некоторые документы, или даже получить доступ к серверу напрямую по требованию.
4. Репликация не будет происходить в фоновом режиме на iOS. Вы можете использовать iOS SDK, чтобы обеспечить некоторые случаи фоновой репликации.

Наконец, если вы не хотите использовать CouchDB, вы можете, по крайней мере, использовать его как хорошую справочную информацию о том, как вы можете создать алгоритм синхронизации с использованием HTTP API. Мое предложение было бы начать с CouchDB, а затем, если вам нужно что-то более нестандартное, подумать о развертывании своего.