Redis Learning: Introduction to redis transactions

What it is

can execute multiple commands at one time, which is essentially a set of commands. All commands in a transaction will be serialized, serialized and executed in order without being inserted by other commands, and no blocking is allowed.
Execute multiple redis commands at one time.

What can be done

Execute a series of commands in a queue at one time, sequentially and exclusively.

How to play

The MULTI command is used to open a redis transaction. This command will always reply OK, (I don’t know if it can succeed. ), At this time, the user can execute multiple commands at once instead of executing one by one. redis will enqueue them, and all commands will be called by the EXEC command
DISCARD abandons the batch operation.

Recommended (free): redis tutorial

Common commands

##DISCARDCancel the transaction and abandon the execution of all commands within the transaction block. EXECExecute all commands within the transaction block. MULTIMarks the beginning of a transaction block. UNWATCHCancel the monitoring of all keys by the WATCH command. WATCH key [key …]Monitor one (or more) keys. If this (or these) keys are changed by other commands before the transaction is executed, Then the transaction will be interrupted.

Case

Normal execution

##Abandon transaction

All in a row


A mistake, all in a row, no execution

Enemy creditor

Regarding this problem, how to understand redis’s support for transactions
Redis partially supports transactions. In this part, the correct ones are executed, and the wrong ones are not executed.

case:watch monitoring

Pessimistic Lock/Optimistic Lock/CAS (Check and set)

Pessimistic Lock (Pessimistic Lock) , as the name suggests, it is very pessimistic. Every time you go to get the data, you think that others will modify it, so you will lock it every time you get the data. In this way, if others want to get the data, they will block until they get the lock. Many such lock mechanisms are used in traditional relational databases, such as row locks, table locks, read locks, write locks, etc., which are all locked before operations. Table lock: Lock the entire table. However, this table may have many pieces of data. At this time, a process needs to make large-scale changes, which will cause more and more threads to be queued.
Row Lock: Lock each record
Optimistic Lock

Optimistic Lock, as the name suggests, is very optimistic. Every time you go to get the data, you think that others will not modify it. , so it will not be locked, but when updating, it will be judged whether others have updated the data during this period. You can use mechanisms such as version numbers. Optimistic locking is suitable for multi-read application types, which can improve throughput. Optimistic locking strategy: The submitted version must be greater than the current version of the record before the update can be performed
Optimistic locking is not blindly optimistic. For example, Zhang San changed his WeChat account and Li Si changed his QQ account at the same time. At that time, the version number was all 1, and then Zhang San changed the WeChat account and submitted it. At this time, the version number changed from 1 to 2. Li Si also submitted it after changing it. At this time, it changed from 1 to 3, and an exception was reported. Restart Revise.
Optimistic locking is generally used at work

Initialize the available balance and debt of the credit card

No tampering, Monitor first and then enable multi to ensure that the two amount changes are within the same transaction

While monitoring, it was found that another transaction modified the shared data, causing the transaction execution to fail

Before modifying data, watch needs to be locked, otherwise an error will occur. If someone modifies my data, I will report an exception.

There is tampering

The key is monitored. If the key is modified, the execution of the subsequent transaction will be invalid

unwatch

Cancel the monitoring of all keys by the watch command

Once the exec is executed, the monitoring lock added before executing will be canceled

Summary

Watch instruction is similar to optimistic locking. When the transaction is submitted, if the value of Key has been changed by another client, for example, a list has been pushed/popped by another client, the entire transaction queue will not be executed.

Multiple Keys are monitored before transaction execution through the WATCH command. If the value of any Key changes after WATCH, the transaction executed by the EXEC command will be abandoned, and a Nullmulti-bulk response will be returned to notify the caller that the transaction execution failed.

3 Phase

• Open: Start a transaction with MULTI

• Enqueue: Enqueue multiple commands into the transaction. Receiving these commands does not It will be executed immediately, but placed in the transaction queue waiting for execution
• Execution: Transaction triggered by EXEC command

3 Features

Individual isolation operation: All commands in a transaction are serialized and executed sequentially. During the execution of the transaction, it will not be interrupted by command requests sent by other clients.

There is no concept of isolation level: the commands in the queue will not be actually executed until they are submitted, because no instructions will be actually executed before the transaction is submitted, so there is no "query within the transaction to see the transaction" The update in the redis cannot be seen when queried outside the transaction. This is a very troublesome problem.
Atomicity is not guaranteed: if a command fails to execute in the same redis transaction, subsequent commands will still be executed without a response. Roll
does not follow traditional ACID in AI

Command	Description

The above is the detailed content of Redis Learning: Introduction to redis transactions. For more information, please follow other related articles on the PHP Chinese website!