“This is the third day of my participation in the Gwen Challenge in November. Check out the details: The last Gwen Challenge in 2021.”

The transaction

You either succeed at the same time or you fail at the same time, atomicity!

Redis single command is guaranteed atomicity, but things are not guaranteed atomicity!

The command is executed only when it is initiated

One-off, sequential and exclusive

Redis is what it is: a collection of commands! All commands in a transaction are serialized and executed in sequence during transaction execution

Redis transactions have no concept of isolation levels

All commands in a transaction are not executed directly, only

Redis transactions

Set key1 v1 execute transaction #exec execute transaction #discardCopy the code

example

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 k1
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) "v1"
127.0.0.1:6379> 
​
Copy the code

abnormal

Compiled exceptions (there is a problem with the code! Wrong command! None of the commands in the transaction will be executed!

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> setget k2
(error) ERR unknown command `setget`, with args beginning with: `k2`, 
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k3
(nil)
​
Copy the code

Run-time exception If syntax exists in the transaction queue, other commands can be executed normally when the command is executed. The error command throws an exception

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> incr k2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) (error) ERR value is not an integer or out of range
4) OK
127.0.0.1:6379> get k3
"v3"
127.0.0.1:6379> 
​
Copy the code

Redis implements optimistic locking (interview FAQ)

Redis implements optimistic locking (interview FAQ)

Pessimistic locks:

Lock everything you do

Optimistic locking:

Access to the version

It’s optimistic that there will be no problems at any time, so it won’t be locked. When updating data, judge whether the data has been modified during this period, Watch

Redis monitors tests

Unwatch gives up monitoring unlock

Watch Money re-monitored

If the transaction execution fails, it will be unlocked first, and the latest value will be obtained to monitor the execution of the transaction again. Exec compares whether the value monitored has been changed

Transaction executed successfully

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 out 20 QUEUED 127.0.0.1:6379> exec 1) (integer) 80 2) 6379 > 20 127.0.0.1 (integer) :Copy the code

Simulate two threads. One thread modifies the data in the transaction, and the transaction fails

Thread a

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 # 127.0.0.1:6379> Multi # enable transaction OK 127.0.0.1:6379> decrby money 20 QUEUED 127.0.0.1:6379> incrby out 20 QUEUED 127.0.0.1:6379> exec # 127.0.0.1:6379> unwatch # unlock OK 127.0.0.1:6379> watch money # re-execute transaction on lock OK 127.0.0.1:6379> multi OK 127.0.0.1:6379> decrby money 20 QUEUED 127.0.0.1:6379> incrby out 20 QUEUED 127.0.0.1:6379> Exec 1) (integer) 980 2) (integer) 20 127.0.0.1:6379>Copy the code

Thread 2

127.0.0.1:6379> set money 1000
OK
127.0.0.1:6379> 
Copy the code