Синхронізація даних у мобільних додатках - кілька пристроїв, кілька користувачів

Я хочу розробити свій перший мобільний додаток. Однією з основних особливостей програми є те, що кілька пристроїв / користувачів матимуть доступ до одних і тих же даних - і всі вони матимуть права CRUD.

Я вважаю, що архітектура повинна включати центральний сервер, де зберігаються всі дані. Пристрої використовуватимуть API для взаємодії з сервером для виконання його операцій із передачею даних (наприклад, додавання запису, редагування запису, видалення запису).

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

1. Користувач A офлайн і редагує запис №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) за допомогою оптимістичного офлайн-блокування + MVCC, (2) через веб-API та (3) через Http кешування дуже добре.

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

• Постарайтеся використовувати однорідні технології, якщо це можливо. Під "однорідними" я маю на увазі технології, побудовані з тими ж принципами, наприклад, сценарії використання веб-2.0. Приклад: Використання належного клієнта CouchDb та REST (веб-API) з локальною стратегією кешування - кращий вибір, ніж використання SQL для мобільних додатків.

• Я настійно не рекомендую використовувати MySQL, оскільки це технологія, яка не була чітко створена для таких сценаріїв використання. Це працює, але вам набагато краще з системою баз даних, яка вже охоплює стиль веб-комунікації та одночасності (наприклад, багато баз даних NoSQL).

До речі, я влаштувався на CouchDb з користувацьким місцевим клієнтом, що працює проти API CouchDb, який працює і масштабує чудово. Я перейшов із використання MSQL + (N) в режим глибокого сну і заплатив високу ціну за те, що не зробив правильного вибору (мається на увазі недостатнього дослідження).

По-перше, ви згадали і 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. Ви можете використовувати SDK для iOS, щоб забезпечити деякі випадки фонової реплікації.

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