Redis transactions
Any database must have its own transaction control mechanism. Redis transaction can execute multiple commands at a time, and its essence is a collection of commands. All commands in a transaction are serialized, and the commands in the queue are executed sequentially during the transaction. Command requests submitted by other clients are not executed until the transaction completes.
In summary: Redis transaction is a one-time, sequential, exclusive execution of a series of commands in a queue, so redis actual notes you have to read first!
Redis transactions differ from other database transactions:
1. Redis transaction is divided into three stages: start transaction, order to join the queue, and execute transaction.
2, redis transactions do not have the concept of isolation level: redis before sending the exec command, the command operation was placed into the queue cache, will not be the actual execution, so can’t similar relational data, the query has changed in the transaction, the transaction of the client can’t query to the data within a transaction.
Redis transactions do not guarantee atomicity: Redis transactions only guarantee that all commands will be executed if they are formatted correctly, or none will be executed at all. However, the whole transaction is not guaranteed atomicity, and there is no rollback. If any command in the transaction fails to execute, the remaining commands will still execute.
Redis command syntax:
Watch key1 key2, etc. : Monitor one or more keys. If the KEY value is changed by other commands during transaction execution, the transaction will be interrupted and all transactions will not be executed. Redis completes optimistic locking of transactions through this mechanism.
2. Multi: Specifies the start of a Redis transaction.
3, exec: used to specify that the Redis transaction starts to execute (sequential, one-time execution of all commands in the transaction), once the exec is executed, the previously added monitoring lock will be cancelled.
Discard: Used to cancel a transaction. Discard all commands in the transaction.
5. Unwatch: Cancel the monitoring of the key in Watch.
Here we analyze the execution process of redis transaction in detail through examples:
Case 1, Redis normal transaction process:
multi
set key1 hello
set key2 free
set key3 world
get key2
exec
Copy the code
Example 2: Cancel the transaction as follows:
multi
set key1 hello_1
set key2 free_1
set key3 world_1
discard
get key3
Copy the code
Example 3: If a command in a redis transaction fails (i.e., no command exists, not syntax error), none of the commands in the transaction will be executed.
multi
set key1 hello_1
setok key2 free_1
set key3 world_1
get key3
exec
Copy the code
Example 4: a command with syntax error exists in redis transaction, and other commands are executed as usual when executing exec. The code is as follows:
multi
incr key1
set key2 free_1
set key3 world_1
get key3
exec
Copy the code
Case 5, use watch to monitor the change of a key value to do the optimistic lock of Redis transactions. There’s $100 in the simulated KEYA account, $20 in the simulated KEYB account, and then A transfers $50 to B.
First add the test data as follows:
set keya 100
set keyb 20
watch keya
multi
decrby keya 50
incrby keyb 50
exec
get keya
Copy the code
Then, we open the second client, and before the transaction execution (exec), reduce 50 yuan for account A in advance to see if the optimistic lock mechanism of Watch takes effect. The code is as follows:
When a Redis transaction commits, if the watch command changes the value of the monitoring key while the transaction is in the cache queue, none of the commands in the transaction will be executed. A message is displayed indicating that the transaction consumer failed to execute the transaction.