Стратегии синхронизации данных

Шесть основных подходов к синхронизации распределённого состояния. От грубых (pessimistic lock) до математически чистых (CRDT).

1. Pessimistic (блокировки)

Перед изменением — захватываем lock на ресурс. Конфликт → одна сторона ждёт.

  • Где: реляционные БД, ACID-транзакции.
  • + Strong consistency.
  • - Не работает offline, узкое горло на координаторе.

2. Optimistic (last-write-wins)

Все пишут без блокировок. При конфликте — последний по timestamp побеждает.

  • Где: простые key-value, кеши.
  • + Просто, быстро.
  • - Потеря данных при близких изменениях, проблема clock skew.

3. Operational Transformation (OT)

Операции трансформируются друг относительно друга при применении. Google Docs использовал OT.

  • + Работает для real-time co-editing.
  • - Сложно: матрица трансформаций для каждой пары операций.

4. State-based CRDT

Реплики шлют полные состояния. Merge коммутативен/идемпотентен.

  • + Не нужен reliable transport, доставка в любом порядке.
  • - Большие пакеты.

5. Operation-based CRDT

Реплики шлют лог операций. Применяются с дедупликацией.

  • + Маленькие пакеты, подходит для real-time.
  • - Нужны гарантии доставки.

6. Patch-based (git-style)

Пессимистичная по своей сути. Правки в разных файлах → автоматический merge. Правки рядом → конфликт, ручное разрешение.

  • Где: Git, любые VCS.
  • + Прозрачно для человека.
  • - Конфликты требуют людей.

Сводная таблица

Стратегия Тип Offline Конфликты Сложность
Pessimistic Strong нет блокировка средняя
Optimistic (LWW) Eventual да потеря низкая
OT Eventual да автоматически высокая
State CRDT Eventual да автоматически средняя
Op CRDT Eventual да автоматически высокая
Patch-based Mixed да люди средняя

автор: как выбирать

«Оптимистическое всегда конфликт разрешается в пользу того, кто последний записал. Но это самые примитивные стратегии. Они на самом деле в очень многих случаях выше крыши.»

Не всегда нужны CRDT. Простые приложения отлично живут на LWW.

CRDT нужны, когда:

  • Concurrent edits — норма (collaborative tools).
  • Сеть нестабильна (offline-first).
  • Нужны множественные реплики без координатора.

Sync — отдельный слой

«Если синхронизацию состояния отдавать на откуп программистам, они её всегда начинают переизобретать. Хорошо может быть сделана только если вынесена в специальный слой синхронизации — отдельная библиотека, которая отлаживается специальными умными людьми.»

Не катите свою синхронизацию. Используйте Yjs / Automerge / Replicache / Metarhia GlobalStorage.

Topology

  • Client-server — все клиенты синкаются с сервером.
  • Peer-to-peer — клиенты синкаются друг с другом (WebRTC).
  • Hybrid — discovery через blockchain, sync через WebRTC.

🎓 Источники

См. также