Article Directory
Redis transaction introduction
Redis single command guarantees atomicity, but transaction does not guarantee atomicity. The
essence of Redis transaction: a set of commands. All commands in a transaction will be serialized. During the execution of the transaction, they will be executed in order, which is one-off, sequential, and exclusive
Redis transaction steps
Open the transaction,
order to join the team,
execute the transaction
Normal execution
127.0.0.1:6379> multi #开启事务
OK #命令入队
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> exec #执行事务
1) OK
2) OK
3) "v2"
4) OK
Cancellation of the transaction
127.0.0.1:6379> multi #开启事务
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k4 v4
QUEUED
127.0.0.1:6379> discard #取消事务
OK
127.0.0.1:6379> get k4 #事务队列中命令都不会被执行
(nil)
Compilation type exception (the code is wrong, the command is wrong), the commands in the transaction will not be executed
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> getset k3
(error) ERR wrong number of arguments for 'getset' command
127.0.0.1:6379> set k4 v4
QUEUED
127.0.0.1:6379> set k5 v5
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k5
(nil)
Runtime exceptions, if there is grammaticality in the transaction queue, other commands can be executed normally when the command is executed, and the wrong command throws an exception
127.0.0.1:6379> set k1 "v1"
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr k1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> get k3
QUEUED
127.0.0.1:6379> exec
1) (error) ERR value is not an integer or out of range
2) OK
3) OK
4) "v3"
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379> get k3
"v3"
Redis monitoring (act as an optimistic lock, compare whether there are changes when modifying)
Normal execution
The transaction ends normally, there is no change during the data execution, single thread
127.0.0.1:6379> set money 100
OK
127.0.0.1:6379> set out 0
OK
127.0.0.1:6379> watch money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby money 20
QUEUED
127.0.0.1:6379> incrby money 20
QUEUED
127.0.0.1:6379> exec
1) (integer) 80
2) (integer) 100
Test multi-threaded change value
127.0.0.1:6379> watch money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby money 10
QUEUED
127.0.0.1:6379> exec
(nil)
Operate on another client before the above transaction is executed
127.0.0.1:6379> incrby money 1000
(integer) 1100
The final transaction will fail
Next, first unlock, re-monitor and then execute the transaction
127.0.0.1:6379> unwatch
OK
127.0.0.1:6379> watch money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby money 100
QUEUED
127.0.0.1:6379> incrby money 1
QUEUED
127.0.0.1:6379> exec
1) (integer) 1000
2) (integer) 1001
reference
https://www.bilibili.com/video/BV1S54y1R7SB