Redis transactions

Redis The business of

What is it? ：

        Official website ：https://redis.io/topics/transactions

        You can execute more than one command at a time , The essence is a set of commands . All commands in a transaction are serialized , Serializing execution in sequence without being inserted by other commands

        Can be seen as , In a queue , Disposable 、 Sequence 、 To execute a series of orders exclusively

        It should be noted that , Even if a command fails , All other commands in the queue are processed ,Redis Does not stop processing commands . To put it bluntly, it is not atomic ;

How do you play? ：

Serial number	Command and description
1	DISCARD Cancel the business , Give up executing all commands within the transaction block .
2	EXEC Execute commands within all transaction blocks . Once implemented exec All the previously added monitoring locks will be cancelled （watch Monitored key）
3	MULTI Mark the beginning of a transaction block .
4	UNWATCH Cancel WATCH Command to all key Surveillance .
5	WATCH key [key ...] Watch one ( Or more ) key , If before the transaction is executed ( Or these ) key Altered by other orders , Then the business will be interrupted .

  example 1： Normal execution

  multi Start a transaction ,exec Execute all commands within the transaction , stay exec All previous operations have not been submitted , Cannot access when opening a new thread window

127.0.0.1:6379> keys *
1) "k2"
2) "k1"
127.0.0.1:6379> flushall
OK
127.0.0.1:6379> keys *
(empty list or set)
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> get k2
"v2"

  example 2： Give up execution

  multi Start a transaction ,discard Discard all commands within the transaction , All commands within a transaction are invalid

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k2 xiaoming
QUEUED
127.0.0.1:6379> discard
OK
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379> 

  example 3： All sit together

  multi Start a transaction , Just during compilation （ Grammatically ） There is one who reports an error , Then all commands in this transaction will fail to commit

127.0.0.1:6379> keys *
1) "k3"
2) "k2"
3) "k1"
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 vvvvv
QUEUED
127.0.0.1:6379> set k4 v4
QUEUED
127.0.0.1:6379> set k5 v5
QUEUED
127.0.0.1:6379> setsetset k6 v6
(error) ERR unknown command 'setsetset'
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> keys *
1) "k3"
2) "k2"
3) "k1"
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> 

  example 4： Enemy creditor

  multi Start a transaction , Just during compilation （ Grammatically ） No report error , Then the command in this transaction , The runtime error command will fail , Other commands will still succeed

127.0.0.1:6379> keys *
1) "k3"
2) "k2"
3) "k1"
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k22 v22
QUEUED
127.0.0.1:6379> get k4
QUEUED
127.0.0.1:6379> incr k1
QUEUED
127.0.0.1:6379> set k33 v33
QUEUED
127.0.0.1:6379> exec
1) OK
2) (nil)
3) (error) ERR value is not an integer or out of range
4) OK
127.0.0.1:6379> keys *
1) "k2"
2) "k3"
3) "k22"
4) "k33"
5) "k1"
127.0.0.1:6379> get k22
"v22"
127.0.0.1:6379> 

    therefore , Strictly speaking ,redis It doesn't support transactions , Or some support transactions

  watch monitor :

    example 1： Normal execution

127.0.0.1:6379> get k22
"v22"
127.0.0.1:6379> set balance 100
OK
127.0.0.1:6379> set debt 0
OK
127.0.0.1:6379> WATCH balance
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> decrby balance 20
QUEUED
127.0.0.1:6379> incrby debt 20
QUEUED
127.0.0.1:6379> EXEC
1) (integer) 80
2) (integer) 20
127.0.0.1:6379> 

example 2： Abnormal modification

Is in the process of a pair watch balance when , Process II （ Or threads ） Yes balance It's been modified , Then the transaction will fail

  Thread one

127.0.0.1:6379> WATCH balance
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> decrby balance 20
QUEUED
127.0.0.1:6379> incrby debt 20
QUEUED
127.0.0.1:6379> EXEC
(nil)
127.0.0.1:6379> clear
127.0.0.1:6379> get balance
"800"
127.0.0.1:6379> 

Thread two

127.0.0.1:6379> get balance
"80"
127.0.0.1:6379> set balance 800
OK
127.0.0.1:6379> 

 

unwatch Cancel

As mentioned above    Watch one ( Or more ) key , If before the transaction is executed ( Or these ) key Altered by other orders , Then the business will be interrupted

127.0.0.1:6379> watch balance
OK
127.0.0.1:6379> set balance 500
OK
127.0.0.1:6379> unwatch
OK
127.0.0.1:6379> get balance
"500"
127.0.0.1:6379> watch balance
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set balance 80
QUEUED
127.0.0.1:6379> set debt 20
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
127.0.0.1:6379> get balance
"80"
127.0.0.1:6379> 

Watch summary ：

• Watch Instructions , Like optimistic lock , Transaction commit , If Key The value of has been changed by another client , For example, a certain list Has been used by another client push/pop After that , The entire transaction queue will not be executed
• adopt WATCH The command monitors multiple... Before the transaction executes Keys, If in WATCH And then there's anything Key The value of has changed ,EXEC All transactions executed by the command will be discarded , At the same time return to Nullmulti- bulk Reply to notify the caller that the transaction failed
   

 

summary ：

In general, the transaction is divided into three phases ：

                    Turn on : With MULTI Start a transaction
                    The team : Queue multiple orders into a transaction , These orders will not be executed immediately , It is put in the transaction queue waiting for execution
                    perform : from EXEC Command triggers transaction
Three characteristics ：

1、 Separate isolation operation : All commands in the transaction are serialized 、 To execute in order . Transaction is in the process of execution , Will not be interrupted by command requests from other clients
2、 There is no concept of isolation level : The commands in the queue are not actually executed until they are submitted , Because no instruction is actually executed before the transaction is committed , There is no such thing as ” The query in a transaction needs to see the update in the transaction , Query outside the transaction cannot see " This is a big headache .
3、 There is no guarantee of atomicity : redis The same thing If a command fails to execute in the service , Subsequent orders will still be executed , No rollback