Redis from 0 to master - transaction

Transaction

redis transaction essence: a set of orders! All commands in a business will be serialized, and in the transaction execution process, they will be executed in sequence.

One-time, sequential, exclusive! Execute some columns command!

------ Queueset set set Execute ------

Reed does not have the concept of the level! All commands are not directly executed in transactions! Only when you initiate an execution command! Exec redis single command to save atomic, but transactions do not guarantee atomicity!

Redis business:

  • Open a transaction (MULTI)
  • Command into the team (…)
  • Execute a transaction (Exec)

Normal implementation!

127.0.0.1:6379> multi # Open transaction OK #Command into the team127.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 # Executive transaction1) OK
2) OK
3) "v2"
4) OK

Abandon business! (Discard)

127.0.0.1:6379> multi # Open transaction OK127.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 # Cancel the transaction OK127.0.0.1:6379> get k4 # The command in the transaction queue will not be executed! (NIL)

Compile type exception (code has problems! Command is wrong!), All commands in transactions 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 command (error) Err WRONG NUMBER OF Argumentsfor '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 # Executive transaction badge! (Error) Execabort Transaction Discarded Because of Previous Errors.127.0.0.1:6379> get k5 # All commands will not be executed! (NIL)

Runtime exception (1/0), if there is a syntax in the transaction queue, then the command is executed, the other commands can be performed normally, the error 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 # Failure to execute! Queued127.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 # Although the first command is wrong,It is still working properly!2) OK
3) OK
4) "v3"
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379> get k3
"v3"

Monitor! Watch (interview us!)

Pessimism:

  • Very pessimism, think when it will come out, no matter what you do, you will lock!

Optimistic lock:

  • Very optimistic, think when it doesn’t have problems, so I will not lock! – – When updating the data, it is judged that there is someone modified this data during this time.
  • Get Version
  • Compare Version when updating

Repeeds

Successful implementation

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 # Monitor MoneyObject OK127.0.0.1:6379> multi # The transaction ends normally, there is no change during the data period, this time is successful! OK127.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) (integer) 20

Test multithreading modification value, use Watch to do redis’s optimism!

127.0.0.1:6379> watch money # Monitor Money OK127.0.0.1:6379> multi
OK
127.0.0.1:6379> DECRBY money 10
QUEUED
127.0.0.1:6379> INCRBY out 10
QUEUED
127.0.0.1:6379> exec # Before executing, another thread modified our value, this time, it will cause transaction execution.Lost! (NIL)

If the modification fails, get the latest value is good.

image.png