(продолжение предыдущего поста)
### Пессимистическая блокировка (Pessimistic Locking)
Суть: предполагает, что конфликты при обновлении данных вероятны, поэтому блокирует доступ к ресурсу заранее — до совершения операции. Гарантирует целостность данных, но может снижать производительность из-за ожидания блокировки.
Как работает (на примере изображения):
1. Сара и Джон одновременно запрашивают данные аккаунта (id:1, amt:40).
2. Когда Сара получает данные, система устанавливает эксклюзивную блокировку на запись (показана иконкой замка). Это значит, что:
- Сара может изменять данные.
- Джон не может сразу изменить те же данные — его запрос «зависает» до снятия блокировки.
3. Сара уменьшает баланс на 20 (amt:20) и фиксирует изменения (
Commit & Release Lock), снимая блокировку.4. Только после этого Джон может выполнить свою операцию — уменьшить баланс ещё на 30. Итоговый результат: amt:-10.
5. Ключевой момент: пессимистическая блокировка запрещает даже чтение заблокированных записей до снятия блокировки (отмечено на схеме крестиком напротив попытки Джона обновить данные).
Особенности:
- Обеспечивает максимальную целостность данных.
- Может приводить к «contention» (конкуренции за ресурсы) — задержкам, если много пользователей хотят работать с одними данными.
- Блокировка снимается только после
COMMIT (фиксации транзакции).### Оптимистическая блокировка (Optimistic Locking)
Суть: основана на предположении, что конфликты маловероятны. Сначала выполняется чтение данных, а проверка на конфликт происходит только при записи (COMMIT). Это повышает производительность, но требует обработки возможных ошибок.
Как работает (на примере изображения):
1. Сара и Джон одновременно читают данные аккаунта (id:1, amt:40, version:1). Версия (version) — ключевой элемент оптимистической блокировки.
2. Сара уменьшает баланс на 20 и пытается зафиксировать изменения, используя исходную версию (version:1). Операция проходит успешно: amt:20, version:2.
3. Джон тоже пытается уменьшить баланс на 20, но использует устаревшую версию (version:1), которая уже не соответствует текущей (version:2).
4. Система отклоняет транзакцию Джона с ошибкой «No Account Row Matched» — потому что данные изменились с момента чтения.
5. Джону нужно:
- Перечитать актуальные данные (version:2).
- Повторить операцию с новой версией.
Особенности:
- Не блокирует доступ к данным — высокая параллельность операций.
- Конфликты выявляются только на этапе записи (write time).
- Требует логики повтора (retry logic) для транзакций, которые не прошли из-за конфликта версий.
- Использует версионирование (version) для отслеживания изменений.
### Ключевые отличия
- Время блокировки: пессимистическая — блокирует заранее, оптимистическая — проверяет конфликт только при записи.
- Влияние на производительность: пессимистическая может вызывать задержки, оптимистическая — эффективнее, но требует обработки ошибок.
- Сценарии применения:
- Пессимистическая — там, где критична целостность данных (банковские транзакции, учёт запасов).
- Оптимистическая — в системах с низкой вероятностью конфликтов или где важна скорость (веб-приложения, CRM).
Распространенные рекомендации по использованию
- Держать блокировки минимально возможное время.
- Применять блокировки на самом детальном уровне (строки, а не таблицы).
- Реализовать логику повтора для транзакций, потерпевших конфликт.
- Выбирать тип блокировки в зависимости от приоритетов: целостность данных (пессимистическая) или производительность (оптимистическая).
