I. Обзор:
концепция:Несколько команд могут выполняться одновременно, что по сути представляет собой набор команд. Все команды в транзакции сериализуются и выполняются последовательно, без вставки другими командами, и не допускается застревание.
Redis частично поддерживает транзакции, но не поддерживает: сильная согласованность
Что я могу сделать:В очереди выполнять серию команд одновременно, последовательно и монопольно.
Общие команды:
-
MULTI: Начать транзакцию.После выполнения MULTI клиент может продолжать посылать серверу любое количество команд.Эти команды не будут выполняться немедленно, а будут помещены в очередь. -
EXEC: выполнить все команды в очереди -
DISCARD: очистить очередь транзакций и отказаться от выполнения транзакции. -
UNWATCH:ОтменаWATCHКомандный мониторинг всех ключей -
WATCH key1 key2 ...: следить за одним (или несколькими) ключами, если этот (или эти) ключи будут изменены другими командами до выполнения транзакции, то транзакция будет прервана.
2. Используйте:
Обычное исполнение:
Отказаться от сделки:
Все сидят вместе:
Синтаксическая ошибка команды, примечание: я сказал синтаксическая ошибка! , EXEC сообщает об ошибке.
Недобросовестные кредиторы (частично поддерживающие сделки):
У несправедливости есть голова, у долга есть хозяин, право освобождается, а неправильное ищется. Это также означает: Redis частично поддерживает транзакции, право освобождается, а неправильно сообщается.
НАБЛЮДЕНИЕ за мониторингом: сначала отслеживайте, а затем запускайте транзакции
Кэшированные данные могут быть взяты и изменены кем угодно, поэтому они должны быть помечены для отслеживания поведения. Это включает в себя блокировки: пессимистические блокировки / оптимистичные блокировки / CAS (проверить и установить)
-
悲观锁(Pessimistic Lock): Как следует из названия, это очень пессимистично.Каждый раз, когда я иду, чтобы получить данные, я думаю, что другие будут их изменять, поэтому каждый раз, когда я получаю данные, они будут заблокированы, так что, если кто-то захочет получить данные , он будет блокироваться, пока не получит блокировку. Многие такие механизмы блокировки используются в традиционных реляционных базах данных, например, блокировки строк, таблиц, чтения, записи и т. д., все из которых блокируются перед выполнением операций. -
乐观锁(Optimistic Lock): Как следует из названия, очень оптимистичен. Каждый раз, когда я иду получать данные, я думаю, что другие не будут его модифицировать, поэтому он не будет заблокирован, но я буду судить, когда он будет обновлен. В этот период, будет ли другие обновили данные, вы можете использовать номер версии и другие механизмы. Оптимистическая блокировка подходит для типов приложений с множественным чтением, что может повысить пропускную способность, - Стратегия оптимистичной блокировки (обычно используется): зафиксированная версия должна быть больше, чем текущая версия записи, чтобы выполнить обновление. Это не влияет на параллелизм и может удовлетворить потребности.
Демонстрационный пример: кредитные карты и балансы
Нормальное состояние: пробка не вскрыта.
Бывают случаи глушения несанкционированного доступа:
После мониторинга WATCH кто-то изменяет баланс, что приведет к прерыванию транзакции.Последнее значение должно быть обновлено для успешного выполнения транзакции, аналогично механизму номера версии оптимистической блокировки.
Три этапа сделки:
1. Открыть: начать транзакцию с MULTI
2. Ставить в очередь: поместить в транзакцию несколько команд.Когда эти команды будут получены, они не будут выполняться немедленно, а будут помещены в очередь транзакций, ожидающих выполнения.
3. Выполнение: транзакция запускается командой EXEC.
Три характеристики транзакций:
1. Отдельные изолированные операции: все команды в транзакции сериализуются и выполняются последовательно. Во время выполнения транзакции она не будет прервана командным запросом, отправленным другими клиентами.
2. Нет понятия уровня изоляции: команды в очереди не будут фактически выполняться до тех пор, пока они не будут отправлены, потому что никакие инструкции не будут фактически выполнены до отправки транзакции, поэтому внутри транзакции нет запроса. транзакции не может быть виден запросом вне транзакции" Это очень головная боль
3. (Важно) Атомарность не гарантируется: если команду не удастся выполнить в той же транзакции redis, последующие команды все равно будут выполняться без отката, а именно:RedisТранзакции частично поддерживаются.
резюме:
Несколько ключей отслеживаются перед выполнением транзакции с помощью команды WATCH. Если значение любого ключа изменится после WATCH, транзакция, выполненная командой EXEC, будет отменена, и будет возвращен нуль-массовый ответ, чтобы уведомить вызывающую сторону о том, что выполнение транзакции не удалось.