Недавно праздничное время майского праздника скорректировали, и я решил воспользоваться праздником, чтобы выйти и поиграть. Я вел переговоры со своей девушкой, я отвечал за планирование маршрута, а она отвечала за покупку дорожных принадлежностей. Все хорошо.Сравниваю цены между разными домами.Не знаю,что случилось.Моя девушка не в восторге,когда покупает и покупает.
существуетКак объяснить параллелизм и параллелизм своей девушкеВ статье мы рассмотрели параллелизм и параллелизм. Когда в программе может быть параллелизм, нам необходимо использовать определенные средства для обеспечения точности данных в параллельной ситуации.Это средство гарантирует, что, когда пользователь работает вместе с другими пользователями, полученные результаты отличаются от полученных им Результат молитвы во время операции тот же.
Такой подход называется контролем параллелизма. Цель контроля параллелизма — гарантировать, что работа одного пользователя не будет необоснованно влиять на работу другого пользователя.
Без хорошего контроля параллелизма это может привести кГрязные чтения, фантомные чтения и неповторяющиеся чтенияИ другие вопросы.
Основные средства для достижения контроля параллелизма можно условно разделить на две категории: оптимистичный контроль параллелизма и пессимистичный контроль параллелизма.
Прежде чем мы начнем введение, давайте проясним:Будь то пессимистическая блокировка или оптимистическая блокировка, это концепция, определяемая людьми, и ее можно рассматривать как разновидность мысли.На самом деле, это не только концепция оптимистической блокировки и пессимистической блокировки в системах реляционных баз данных, таких как memcache, hibernate, tair и т. д., все они имеют схожие концепции. Поэтому не следует сравнивать оптимистическую блокировку, пессимистическую блокировку и другие блокировки базы данных.
Когда мы хотим изменить часть данных в базе данных, чтобы избежать одновременного изменения другими, лучший способ — напрямую заблокировать данные для предотвращения параллелизма.
Этот метод блокировки перед изменением данных с помощью механизма блокировки базы данных называется пессимистическим контролем параллелизма (также известным как «пессимистический контроль параллелизма», сокращенно «PCC»).
Причина, по которой его называют пессимистической блокировкой, заключается в том, что это метод управления параллелизмом с пессимистическим отношением к модификации данных. Обычно мы считаем, что вероятность одновременного изменения данных относительно высока, поэтому их необходимо заблокировать перед модификацией.
Пессимистический контроль параллелизма на самом деле является консервативной стратегией «сначала блокировка, а затем доступ», которая обеспечивает гарантию безопасности обработки данных.
Оптимистическая блокировка (Optimistic Locking) относится к пессимистической блокировке.Оптимистическая блокировка предполагает, что данные вообще не будут вызывать конфликтов, поэтому при отправке и обновлении данных конфликт данных будет формально обнаружен.Если конфликт обнаружен, то пусть пользователь возвращает неверную информацию, пусть пользователь решает, что делать.
По сравнению с пессимистической блокировкой оптимистическая блокировка не использует механизм блокировки, предоставляемый базой данных при обработке базы данных. Общий способ реализации оптимистической блокировки — запись версии данных.
Реализация пессимистической блокировки часто зависит от механизма блокировки, предоставляемого базой данных. В базе данных процесс пессимистической блокировки выглядит следующим образом:
Перед изменением записи попробуйте добавить к записи монопольную блокировку.
Если блокировка не удалась, указывая на то, что запись модифицируется, текущему запросу, возможно, придется ждать или выдать исключение. Конкретный способ реагирования определяется разработчиком в соответствии с реальными потребностями.
Если блокировка прошла успешно, запись можно изменить, и транзакция будет разблокирована после ее завершения.
В то же время, если есть другие операции, которые изменяют запись или добавляют эксклюзивную блокировку, она будет ждать, пока мы разблокируем ее, или вызовет исключение напрямую.
Давайте возьмем в качестве примера более часто используемый движок MySql Innodb, чтобы проиллюстрировать, как использовать пессимистические блокировки в SQL.
Чтобы использовать пессимистическую блокировку, мы должны отключить атрибут autocommit базы данных mysql, потому что MySQL по умолчанию использует режим autocommit, то есть при выполнении операции обновления MySQL немедленно зафиксирует результат. установить автофиксацию=0;
Давайте возьмем простой пример, такой как необходимость вычета запасов во время процесса заказа Taobao, чтобы проиллюстрировать, как использовать пессимистические блокировки:
//0.开始事务
begin;
//1.查询出商品库存信息
select quantity from items where id=1 for update;
//2.修改商品库存为2
update items set quantity=2 where id = 1;
//3.提交事务
commit;
Выше, прежде чем изменять запись с id = 1, сначала заблокируйте ее для обновления, а затем измените. Это типичная пессимистичная стратегия блокировки.
Если приведенный выше код для изменения инвентаря выполняется одновременно, только один поток может одновременно открыть транзакцию и получить блокировку с id=1, а другие транзакции могут быть выполнены только после фиксации транзакции. Таким образом, мы можем гарантировать, что текущие данные не будут изменены другими транзакциями.
Выше мы упоминали, что использование select...for update заблокирует данные, но нам нужно обратить внимание на некоторые уровни блокировки.По умолчанию MySQL InnoDB использует блокировки на уровне строк. Все блокировки на уровне строк основаны на индексах. Если оператор SQL не использует индекс, он не будет использовать блокировки на уровне строк и будет использовать блокировки на уровне таблицы для блокировки всей таблицы. Это требует внимания.
Использование оптимистической блокировки устраняет необходимость полагаться на механизм блокировки базы данных.
Концепция оптимистической блокировки на самом деле объясняет конкретные детали ее реализации: в основном есть два этапа: обнаружение конфликтов и обновление данных. Типичным методом реализации является сравнение и замена (CAS).
CAS — это оптимистичная технология блокировки. Когда несколько потоков пытаются использовать CAS для одновременного обновления одной и той же переменной, только один из потоков может обновить значение переменной, а другие потоки терпят неудачу. Неудачный поток не будет приостановлен, но будет заблокирован.Сообщается, что вы провалили это соревнование и можете попробовать еще раз.
Например, предыдущую задачу вычета запасов можно решить с помощью оптимистической блокировки следующим образом:
//查询出商品库存信息，quantity = 3
select quantity from items where id=1
//修改商品库存为2
update items set quantity=2 where id=1 and quantity = 3;
Выше перед обновлением мы сначала запрашиваем текущее количество запасов (количество) в таблице inventory, а затем используем количество запасов в качестве условия модификации при выполнении обновления. Когда мы отправляем обновление, сравниваем текущий инвентарный номер соответствующей записи в таблице базы данных с инвентарным номером, вынесенным в первый раз.Если текущий инвентарный номер в таблице базы данных равен инвентарному номеру, вынесенному за первый раз время, обновите его, в противном случае он считается просроченным.
В приведенном выше операторе обновления есть более важная проблема, а именно легендарная проблема ABA.
Например, поток один берет из базы данных инвентарный номер 3. В это время другой поток два также берет из базы данных инвентарный номер 3, а второй выполняет какие-то операции, чтобы стать 2, а затем второй меняет инвентарный номер на 3. В это время Thread one выполняет операцию CAS и обнаруживает, что в базе данных все еще есть 3, а затем одна операция завершается успешно. Хотя операция CAS первого потока прошла успешно, это не означает, что процесс проходит без проблем.
//查询出商品信息，version = 1
select version from items where id=1
//修改商品库存为2
update items set quantity=2,version = 3 where id=1 and version = 2;
Каждый раз, когда оптимистическая блокировка выполняет операцию модификации данных, она выводит номер версии. Как только номер версии согласуется с номером версии данных, можно выполнить операцию модификации, и номер версии будет +1. В противном случае выполнение будет потерпеть поражение. Поскольку номер версии будет увеличиваться с каждой операцией, проблем с ABA не будет, потому что номер версии будет только увеличиваться, а не уменьшаться.
На самом деле у приведенного выше SQL все же есть определенные проблемы, т.е.Как только возникает высокий параллелизм, только один поток может быть успешно изменен, и будет много сбоев.
Для веб-сайтов электронной коммерции, таких как Taobao, высокий уровень параллелизма является обычным явлением, и пользователям явно неразумно воспринимать неудачу. Следовательно, все еще необходимо найти способ уменьшить гранулярность оптимистической блокировки.
Есть хорошее предложение, которое может уменьшить силу оптимистической блокировки, максимизировать пропускную способность и улучшить возможность параллелизма! следующее:
//修改商品库存
update item
set quantity=quantity - 1
where id = 1 and quantity - 1 > 0
В приведенном выше операторе SQL, если количество заказов, размещенных пользователем, равно 1,quantity - 1 > 0способ выполнить оптимистическое управление блокировкой.
Вышеприведенный оператор обновления во время процесса выполнения сам запросит значение количества в атомарной операции и вычтет его на 1.
Контроль детализации блокировки — важное знание в среде с высокой степенью параллелизма.Выбор хорошей блокировки может значительно повысить пропускную способность и производительность, обеспечивая при этом безопасность данных.
При выборе оптимистичной блокировки и пессимистической блокировки в основном смотрите на разницу между ними и применимыми сценариями.
1. Оптимистическая блокировка на самом деле не блокируется и имеет высокую эффективность. Как только степень детализации блокировки не будет хорошо понята, вероятность сбоя обновления будет относительно высокой, и легко может произойти сбой в бизнесе.
2. Пессимистичные блокировки основаны на блокировках базы данных и неэффективны. Вероятность сбоя обновления относительно низка.
С появлением трехуровневой архитектуры Интернета (высокий параллелизм, высокая производительность и высокая доступность) пессимистичные блокировки стали использоваться все реже в производственных средах, особенно в бизнес-сценариях с относительно большим параллелизмом.