Оптимист против.Пессимистическая блокировка
https://stackoverflow.com/questions/129329
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я понимаю разницу между оптимистической и пессимистической блокировкой.Теперь может ли кто-нибудь объяснить мне, когда я вообще буду использовать любой из них?
И меняется ли ответ на этот вопрос в зависимости от того, использую ли я хранимую процедуру для выполнения запроса?
Но просто для проверки: оптимистический означает «не блокировать таблицу во время чтения», а пессимистический означает «блокировать таблицу во время чтения».
Решение
Оптимистическая блокировка это стратегия, при которой вы читаете запись, записываете номер версии (другие методы для этого включают даты, временные метки или контрольные суммы/хэши) и проверяете, что версия не изменилась, прежде чем записывать запись обратно.Когда вы записываете запись обратно, вы фильтруете обновление версии, чтобы убедиться, что оно является атомарным.(т.е.не было обновлено между проверкой версии и записью записи на диск) и обновлением версии одним нажатием.
Если запись загрязнена (т.версия, отличная от вашей), вы прерываете транзакцию, и пользователь может ее перезапустить.
Эта стратегия наиболее применима к системам большого объема и трехуровневым архитектурам, где вам не обязательно поддерживать соединение с базой данных во время сеанса.В этой ситуации клиент фактически не может поддерживать блокировки базы данных, поскольку соединения берутся из пула, и вы не можете использовать одно и то же соединение при каждом доступе к другому.
Пессимистический локинг это когда вы блокируете запись для своего исключительного использования до тех пор, пока не закончите с ней.Он имеет гораздо лучшую целостность, чем оптимистическая блокировка, но требует от вас осторожности при разработке приложения, чтобы избежать Тупики.Чтобы использовать пессимистическую блокировку, вам необходимо либо прямое соединение с базой данных (как это обычно бывает в двухуровневый клиент-сервер приложение) или внешний идентификатор транзакции, который можно использовать независимо от соединения.
В последнем случае вы открываете транзакцию с TxID, а затем повторно подключаетесь, используя этот идентификатор.СУБД поддерживает блокировки и позволяет вам восстановить сеанс через TxID.Вот как распределяются транзакции с использованием протоколов двухфазной фиксации (таких как ХА или Транзакции COM+) работа.
Другие советы
Оптимистическая блокировка используется, когда вы не ожидаете большого количества коллизий.Выполнение обычной операции обходится дешевле, но если конфликт ДЕЙСТВИТЕЛЬНО произойдет, вам придется заплатить более высокую цену за его разрешение, поскольку транзакция будет прервана.
Пессимистическая блокировка используется, когда ожидается столкновение.Транзакции, нарушающие синхронизацию, просто блокируются.
Чтобы выбрать правильный механизм блокировки, вам необходимо оценить количество операций чтения и записи и соответствующим образом спланировать.
Оптимистический предполагает, что пока вы это читаете, ничего не изменится.
Пессимист предполагает, что что-то произойдет, и поэтому блокирует его.
Если не важно, чтобы данные были четко прочитаны, используйте оптимистический подход.Вы можете получить странное «грязное» чтение, но это с гораздо меньшей вероятностью приведет к взаимоблокировкам и тому подобному.
Большинство веб-приложений нормально справляются с «грязным» чтением — в редких случаях данные не совсем соответствуют следующей перезагрузке.
Для точных операций с данными (как и во многих финансовых транзакциях) используйте пессимистический.Очень важно, чтобы данные считывались точно, без каких-либо неотображаемых изменений — дополнительные затраты на блокировку того стоят.
Да, и сервер Microsoft SQL по умолчанию блокирует страницы — в основном строку, которую вы читаете, и несколько строк с каждой стороны.Блокировка строк более точна, но намного медленнее.Часто имеет смысл настроить транзакции на чтение с подтверждением или без блокировки, чтобы избежать взаимоблокировок при чтении.
В дополнение к тому, что уже было сказано, следует сказать, что оптимистическая блокировка имеет тенденцию улучшать параллелизм за счет предсказуемости.Пессимистическая блокировка имеет тенденцию уменьшать параллелизм, но она более предсказуема.
Вы платите деньги и т. д.
Я бы подумал еще об одном случае, когда пессимистическая блокировка была бы лучшим выбором.
Для оптимистической блокировки каждый участник модификации данных должен согласиться на использование такого типа блокировки.Но если кто-то изменит данные, не позаботившись о столбце версии, это испортит всю идею оптимистической блокировки.
Есть два самых популярных ответа.А первый в основном говорит
Для Optimistic требуется трехуровневая архитектура, в которой вам не обязательно поддерживать соединение с базой данных для вашего сеанса, тогда как для пессимистической блокировки вы блокируете запись для своего исключительного использования до тех пор, пока не закончите с ней.Он имеет гораздо лучшую целостность, чем оптимистическая блокировка: вам нужно либо прямое соединение с базой данных.
Оптимистическая (управление версиями) выполняется быстрее из-за отсутствия блокировки, но (пессимистическая) блокировка работает лучше, когда конкуренция высока, и лучше предотвратить работу, а не отбрасывать ее и начинать заново.
или
Оптимистическая блокировка работает лучше всего при редких столкновениях.
Как говорится на этой странице.
Я создал свой ответ, чтобы объяснить, как «поддерживать соединение» связано с «низким уровнем коллизий».
Чтобы понять, какая стратегия лучше для вас, думайте не о количестве транзакций в секунду в вашей БД, а о продолжительности одной транзакции.Обычно вы открываете транзакцию, выполняете операцию и закрываете транзакцию.Это короткая классическая транзакция, которую имел в виду ANSI, и ее можно избежать без блокировки.Но как реализовать систему бронирования билетов, в которой множество клиентов одновременно бронируют одни и те же номера/места?
Вы просматриваете предложения, заполняете форму с множеством доступных вариантов и актуальными ценами.Это занимает много времени, и варианты могут устареть, все цены недействительны между тем, как вы начали заполнять форму и нажимать кнопку «Я согласен», потому что не было блокировки данных, к которым вы получили доступ, и вмешался кто-то другой, более гибкий. изменение всех цен, и вам нужно начать заново с новыми ценами.
Вместо этого вы можете заблокировать все параметры по мере их чтения.Это пессимистический сценарий.Вы понимаете, почему это отстой.Вашу систему может вывести из строя один-единственный клоун, который просто запустит резервацию и пойдет курить.Никто не может ничего зарезервировать до того, как он закончит.Ваш денежный поток падает до нуля.Поэтому в реальности используются оптимистические оговорки.Тем, кто медлит слишком долго, придется заново бронировать билеты по более высоким ценам.
При таком оптимистическом подходе вам необходимо записывать все данные, которые вы читаете (как в мое Повторное чтение) и перейдите к точке фиксации с вашей версией данных (я хочу купить акции по цене, которую вы указали в этой котировке, а не по текущей цене).На этом этапе создается транзакция ANSI, которая блокирует БД, проверяет, ничего ли не изменилось, и фиксирует/прерывает вашу операцию.ИМХО, это эффективная эмуляция МВКК, который также связан с Optimistic CC и также предполагает, что ваша транзакция перезапустится в случае прерывания, то есть вы сделаете новое резервирование.Транзакция здесь предполагает принятие решений пользователем.
Я далек от понимания того, как реализовать MVCC вручную, но думаю, что длительные транзакции с возможностью перезапуска являются ключом к пониманию предмета.Поправьте меня, если я где-то ошибаюсь.Мой ответ был мотивирован это глава Алекса Кузнецова.
В большинстве случаев оптимистическая блокировка более эффективна и обеспечивает более высокую производительность.При выборе между пессимистической и оптимистической блокировкой учитывайте следующее:
Пессимистическая блокировка полезна, если есть много обновлений и относительно высоких шансов, что пользователи пытаются обновить данные одновременно.Например, если каждая операция может обновлять большое количество записей за раз (банк может добавить процентную прибыль на каждый счет в конце каждого месяца), и два приложения выполняют такие операции одновременно, у них будут конфликты Полем
Пессимистическая блокировка также более уместна в приложениях, содержащих небольшие таблицы, которые часто обновляются.В случае этих так называемых «горячих точек» конфликты настолько вероятны, что оптимистическая блокировка приводит к потере усилий по откату конфликтующих транзакций.
Оптимистическая блокировка полезна, если возможность для конфликтов очень низкая-много записей много, но относительно мало пользователей, или очень мало обновлений и в основном операции типа чтения.
Одним из вариантов использования оптимистической блокировки является использование вашим приложением базы данных, чтобы позволить одному из ваших потоков/хостов «претендовать» на задачу.Это техника, которая мне регулярно пригодилась.
Лучший пример, который я могу придумать, — это очередь задач, реализованная с использованием базы данных, с несколькими потоками, одновременно требующими выполнения задач.Если задача имеет статус «Доступно», «Заявлено», «Завершено», запрос к базе данных может сказать что-то вроде «Установить статус = «Заявлено», где статус = «Доступно».Если несколько потоков попытаются изменить статус таким образом, все потоки, кроме первого, потерпят неудачу из-за «грязных» данных.
Обратите внимание, что это вариант использования, включающий только оптимистическую блокировку.Таким образом, в качестве альтернативы высказыванию «Оптимистическая блокировка используется, когда вы не ожидаете большого количества коллизий», ее также можно использовать, когда вы ожидаете коллизий, но хотите, чтобы ровно одна транзакция была успешной.
