Как распределённые системы обрабатывают и разрешают конфликты, когда одни и те же данные одновременно изменяются на нескольких репликах в архитектурах с несколькими мастерами или несколькими регионами?

Проблема

В архитектурах с несколькими мастерами или несколькими регионами одни и те же данные могут записываться независимо на несколько реплик одновременно, создавая конфликты записи, которые должны быть разрешены для поддержания консистентности.

Распространённые стратегии разрешения конфликтов

• Last-Writer-Wins (LWW): Каждая запись содержит временную метку; сохраняется самая свежая. Просто реализуется, но рискует потерей данных, если временные метки близки друг к другу или часы рассинхронизированы.

• Version Vectors: Каждая реплика отслеживает причинную историю обновлений. Это позволяет системе определить, какие записи конкурируют друг с другом, а какие идут последовательно, что даёт возможность более умного обнаружения конфликтов.

• CRDTs (Conflict-free Replicated Data Types): Структуры данных, математически гарантированно сходящиеся без координации. Идеальны для счётчиков, множеств или append-only логов, где автоматическое слияние предсказуемо.

• Разрешение на уровне приложения: Конфликты передаются приложению или пользователю для ручного слияния — похоже на то, как Google Docs обрабатывает одновременное редактирование. Гибко, но добавляет сложность.

• Пользовательские функции слияния: Логика, зависящая от домена, объединяет конфликтующие обновления — например, берёт объединение двух корзин покупок вместо перезаписи одной.

Как выбрать

Главный вывод

Универсального решения не существует — правильная стратегия зависит от требований к консистентности, типа данных и допустимого уровня потери данных. Продакшен-системы вроде DynamoDB, Cassandra и Riak предоставляют эти опции как настраиваемые параметры, позволяя инженерам балансировать между доступностью и консистентностью в зависимости от конкретного use case.