Представьте, что транзакция B началась после фиксации транзакции A, но система допускает их сериализацию в порядке B → A. Какая гарантия отсутствует и почему это важно?
Отсутствует гарантия строгой сериализуемости. Обычная сериализуемость требует, чтобы результат конкурентного выполнения соответствовал некоторому последовательному порядку, но не обязательно учитывает фактический порядок начала и фиксации транзакций. Строгая сериализуемость дополнительно сохраняет порядок реального времени: если A завершилась до начала B, A не может быть расположена после B в эквивалентном последовательном выполнении.
Сериализуемость появилась как способ безопасно выполнять транзакции параллельно, сохраняя результат, эквивалентный последовательному выполнению. Это позволяет получать конкурентность без принятия всех возможных эффектов перемешивания операций.
В распределённых системах одной сериализуемости оказалось недостаточно: пользователи и сервисы ожидают, что уже подтверждённое изменение будет учитываться последующими операциями. Поэтому для систем, моделирующих единую согласованную базу, важна дополнительная гарантия порядка реального времени — строгая сериализуемость.
Если B началась после фиксации A, но логически выполняется перед A, B может использовать состояние, которое уже не соответствует наблюдаемой истории системы. Например, запрос после подтверждения платежа способен прочитать баланс или статус до этого платежа.
Такая ситуация особенно опасна для распределённых БД, реплик и сервисов, которые принимают решения на основании результатов предыдущих операций. Простая проверка отсутствия конфликтующего изменения не гарантирует корректного порядка относительно уже завершившихся транзакций.
Сериализуемость означает существование некоторого последовательного порядка транзакций, дающего тот же результат, что и конкурентное выполнение. Этот порядок может быть выбран по зависимостям между операциями и не обязан совпадать с физическим временем начала или завершения транзакций.
Строгая сериализуемость добавляет условие реального времени. Если транзакция A завершилась до начала B, допустимый последовательный порядок обязан содержать A перед B. Если система не может обеспечить такой порядок, она должна задержать операцию, предоставить актуальное состояние или отклонить транзакцию.
Следует отличать это от линеаризуемости отдельных операций. Линеаризуемость обычно описывает атомарные операции над объектами, а строгая сериализуемость — транзакции, состоящие из нескольких чтений и записей.
За строгую гарантию приходится платить: необходимы координация, чтение из актуального источника, ожидание подтверждений или отклонение транзакций при неопределённости. Это может увеличить задержку и снизить доступность при сетевых сбоях. Если бизнес-логике достаточно eventual consistency или причинной согласованности, строгая сериализуемость может быть избыточной.
Важно, что название уровня изоляции SERIALIZABLE само по себе не следует автоматически трактовать как гарантию строгой сериализуемости во всех СУБД и распределённых конфигурациях. Нужно проверять документацию конкретной системы, включая поведение реплик, маршрутизацию запросов и обработку сетевых разделений.
Сервис после фиксации изменения профиля отправляет следующий запрос через другой узел кластера. Из-за отставания реплики этот запрос видит старое состояние и принимает решение, несовместимое с уже подтверждённым изменением.
Возможны несколько решений. Чтение только с первичного узла даёт простой порядок, но ограничивает масштабирование чтения. Ожидание реплики уменьшает вероятность устаревших данных, однако добавляет задержку. Передача клиентом токена причинной зависимости позволяет реплике читать не старше указанной версии, но требует поддержки протокола во всех сервисах.
Если решение поддерживает критический инвариант, выбирают чтение с актуального узла или механизм строгой сериализуемости с отклонением операции при невозможности подтвердить порядок. Для некритичного интерфейсного отображения допустимо чтение с задержавшейся реплики. Такое разделение требований сохраняет корректность там, где она необходима, и не тратит строгую согласованность на все запросы.
Нет, не всегда. Уровень SERIALIZABLE обычно обещает эквивалентность некоторому последовательному выполнению, но точная связь с порядком реального времени зависит от реализации и архитектуры доступа. Нужно отдельно выяснить, как система обрабатывает реплики, задержанные чтения, распределённые транзакции и операции, начавшиеся после фиксации другой транзакции.
Не во всех случаях. Если узел не может установить, завершилась ли зависимая транзакция или доступна ли актуальная версия данных, безопасный вариант — ждать или прервать операцию. Без ожидания или отклонения система рискует вернуть результат, нарушающий порядок реального времени.
Причинная согласованность сохраняет порядок операций, связанных отношением причины и следствия, но не обязана упорядочивать все независимые операции по физическому времени. Если бизнес-правило требует единого глобального порядка конфликтующих транзакций, например для уникального ресурса или лимита, нужна сериализация, а при требовании учитывать завершённые операции — её строгий вариант.