Сравнение: чем оптимистическое управление конкурентностью отличается от пессимистического по моменту обнаружения конфликта?
При пессимистическом управлении конкурентностью конфликт предотвращается заранее: транзакция блокирует ресурс перед изменением, а конкурентная транзакция ждёт или получает ошибку. При оптимистическом управлении блокировка обычно не удерживается во время чтения: конфликт проверяется при фиксации или записи, и одна из транзакций прерывается.
Пессимистический подход возник из необходимости безопасно работать с общими данными в условиях одновременных изменений: проще не допустить конкурирующую запись, чем исправлять её последствия. Его основой стали блокировки и протоколы вроде строгой двухфазной блокировки.
Оптимистический подход стал особенно полезен там, где конфликты редки, а длительное удержание блокировок слишком дорого. Он позволяет большему числу транзакций читать и подготавливать изменения параллельно, перенося проверку совместимости на более поздний этап.
Две транзакции могут прочитать один и тот же исходный вариант данных, независимо вычислить результат и попытаться сохранить его. Система должна либо не допустить несовместимые изменения, либо обнаружить конфликт до того, как обе операции будут считаться успешно завершёнными.
Пессимистическая стратегия снижает вероятность конфликтов, но может вызвать ожидание, блокировки и взаимные блокировки. Оптимистическая стратегия повышает параллелизм, однако при конфликте работа одной транзакции теряется и обычно требуется повтор всей транзакции.
При пессимистическом подходе транзакция получает несовместимую блокировку до изменения защищаемого ресурса. Пока блокировка удерживается, другая транзакция не может выполнить конфликтующую операцию: она ждёт, завершается ошибкой по тайм-ауту или становится жертвой разрешения взаимной блокировки.
При оптимистическом подходе чтение выполняется без эксклюзивной блокировки на весь период работы. СУБД или приложение сохраняет версию, контрольное значение или другое состояние, с которым сравнивается ресурс при обновлении. Если ресурс уже изменился, операция не подтверждается как успешная.
MVCC само по себе не означает полностью оптимистическое управление. Версионность может позволять читателям не блокировать писателей, но поведение конфликтующих записей определяется конкретной СУБД и уровнем изоляции: запись может ждать, завершиться ошибкой или быть отклонена при проверке сериализуемости.
Пессимистический вариант предпочтителен при частых конфликтах, дорогом повторе работы или высокой цене временно занятого ресурса. Оптимистический вариант выгоден при редких конфликтах, коротких транзакциях и возможности безопасно повторить всю бизнес-операцию.
Нельзя повторять только отдельный оператор без анализа логики транзакции: между операторами могли измениться исходные данные и бизнес-решения. При оптимистическом конфликте обычно откатывают всю транзакцию, перечитывают актуальные значения и повторяют её с ограничением числа попыток.
В сервисе редактирования карточки товара несколько операторов редко меняют описание одного товара. Долгая блокировка строки на время заполнения формы была бы неудобна: пользователь мог бы держать транзакцию открытой минуты, блокируя других пользователей.
Рассматривались два варианта. Пессимистическая блокировка сразу предотвращала перезапись, но требовала удерживать ресурс во время пользовательского ввода и создавала ожидания. Оптимистическая проверка версии позволяла редактировать независимо, но при сохранении сообщала об устаревших данных и требовала повторного решения конфликта.
Выбрали оптимистический вариант: вместе с изменяемыми данными передавалась версия записи, а сохранение разрешалось только при совпадении этой версии с текущей. При конфликте пользователь получал актуальную карточку и мог объединить изменения; транзакции оставались короткими, а блокировки почти не влияли на пользовательский сценарий.
Ответ: Даже при оптимистической проверке СУБД может кратковременно блокировать строки или индексы во время записи, проверки ограничений и фиксации. Оптимистичным называется не отсутствие блокировок вообще, а предположение, что длительные конфликты редки и их можно обнаружить вместо предварительного удержания эксклюзивного доступа.
Ответ: Откат транзакции базы данных не обязательно отменяет отправленное письмо, внешний HTTP-запрос или уже выполненную публикацию сообщения. Поэтому повтор должен быть идемпотентным либо побочные действия нужно отделять от транзакции и координировать, например через надёжную запись события в базе данных.
Ответ: Если конфликт возникает часто, большинство попыток будет завершаться откатом и повтором. Это увеличит нагрузку на CPU, журналирование и блокировки при фиксации, а задержка станет непредсказуемой. При высокой конкуренции за один ресурс заранее сериализовать доступ иногда дешевле, чем постоянно выполнять одну и ту же работу заново.