Стратегии работы с конфликтами записи

📌 Предотвращение

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

📌 Сходимость к согласованному состоянию

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

▶️Присвоить каждой операции записи уникальный идентификатор (например, метку даты/времени, случайное длинное число, UUID или хеш ключа и значения). Среди конфликтующих операций выбрать операцию-победителя с максимальным значением этого идентификатора, а остальные отбросить. В случае использования метки даты/времени в качестве идентификатора этот метод известен под названием «выигрывает последний» (last write wins, LWW). Такой подход популярен, но ему свойственно терять данные.

▶️Присвоить уникальный идентификатор каждой реплике и считать, что у операций записи, исходящих от реплик с бóльшим номером, есть приоритет перед операциями, которые исходят от реплик с меньшим номером. Этот подход тоже приводит к потерям данных.

▶️Каким-то образом слить значения воедино, например, конкатенировать строки. В примере с семейной встречей она получила бы название «Шашлык 12:00/Копаем картошку 12:00»

▶️Записывать конфликты в отдельную структуру данных и написать код приложения, который бы разрешал конфликты позднее (возможно, спрашивая для этого пользователя).

▶️Использовать структуры данных, специально разработанные для автоматического разрешения конфликтов:
🔸 бесконфликтные реплицируемые типы данных (conflict-free replicated datatype, CRDT) — структуры данных, которые допускают конкурентное редактирование несколькими пользователями и автоматически разрешают конфликты.
🔸 объединяемые хранимые структуры данных (mergeable persistent data structures), которые отслеживают историю аналогично Git.
🔸 операциональное преобразование (operational transformation) для приложений с совместным редактированием (Google Docs).
Реализации алгоритмов автоматического разрешения конфликтов в БД все еще довольно незрелы, но есть вероятность, что в будущем они будут включаться во все большее количество реплицируемых систем.

Резюмируем. Репликация с несколькими лидерами:
➕ устойчивее к отказам узлов
➕ устойчива к проблемам с сетью
➖ значительно сложнее в организации
➖ имеет слабые гарантии согласованности

#кабанчик #сисдиз