Redis05: redis transactions

1、Redis Business profile

Redis The transaction allows a set of commands to be executed in a single step , And it can ensure that all commands in a transaction are serialized , Then execute in order ; In a Redis Transaction ,Redis Or execute all the commands in it , Or nothing . namely Redis Transactions should be able to ensure serialization and atomicity .

-----  queue  set set set……  perform -----

From input Multi Command start , All the entered commands will enter the command queue in turn , But will not execute , Until input Exec after ,Redis The previous commands in the command queue will be executed successively .

In the process of team formation, you can go through discard To give up team building .

Redis Transactions have no concept of isolation levels ：

All commands are in a transaction , Not directly executed , Only when an execution command is initiated ！

Redis Business ：

• Open transaction （multi）
• Order to join the team （）
• Perform transactions （exec）

2、Redis Common commands

（1）multi

 grammar ：multi
 function ： Used to mark the beginning of a transaction block .Redis The subsequent commands will be put into the queue one by one , And then you can use it EXEC The command executes the command sequence atomically .
 Return value ： Open successfully and return OK

Example 1： Normal execution of business

127.0.0.1:6379> multi  # Open transaction 
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  # Perform transactions （ When the transaction is executed, it means that the transaction has ended , It must be reopened later ）
1) OK
2) OK
3) "v2"
4) OK
127.0.0.1:6379> 

（2）exec

 grammar ：exec
 function ： Execute all previously queued commands in a transaction , Then restore the normal connection state .
	-  If an error is reported in the process of pushing the command into the queue , Then the commands in the whole queue will not be executed ,		 Error in execution result ;
	-  If it's normal in the process of pressing the queue , An error is reported for a command in the execution queue , Will only affect 		 The execution result of this command , Other commands operate normally ;
	-  When using WATCH On command , Only if the monitored key has not been modified ,EXEC Orders will be executed 		 Execute commands in transactions ; And once implemented exec command , All the previously added watch Monitor all 	   Cancel .
 Return value ： The return value of this command is an array , Each of these elements is the return value of each command in the atomized transaction .  When using WATCH On command , If the transaction execution aborts , that EXEC The command will return a Null value .

Wrong handling of transactions 1：

• There was a report error on a command in the team , During execution, all queues of the whole are cancelled

Example 2： Compiler exception （ Something is wrong with the code ！ There was a mistake in the order ！）, All commands in the transaction will not be executed

127.0.0.1:6379> multi  # Open transaction 
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  # Wrong command 
(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  # The execution is wrong 
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k4  # All orders will not be executed 
(nil)
127.0.0.1:6379> 

Wrong handling of transactions 2：

• If an error is reported in a command during execution , Only the wrong command will not be executed , And other orders will be executed , No rollback .

Example 3： Runtime exception , If there are syntax errors in the transaction queue , So when the command is executed , Other commands can be executed normally

127.0.0.1:6379> set k1 "v1"
OK
127.0.0.1:6379> multi  # Open transaction 
OK
127.0.0.1:6379> incr k1  # Fail when you can 
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 # Although the first order is wrong , But it is still normal and successful 
1) (error) ERR value is not an integer or out of range
2) OK
3) OK
4) "v3"
127.0.0.1:6379> 

（3）discard

 grammar ：discard
 function ： Clear all previously queued commands in a transaction , And end the transaction .
 If used WATCH command , that DISCARD The command will cancel the monitoring of all keys currently connected to the monitoring .
 Return value ： Clear successfully , return OK.

Example 4： Give up the business

127.0.0.1:6379> multi  # Open transaction 
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> DISCARD  # Cancel the business 
OK
127.0.0.1:6379> get k2  # None of the commands in the transaction queue will be executed 
(nil)
127.0.0.1:6379> 

（4）watch

 grammar ：watch key [key …]
 function ： When a transaction needs to be executed conditionally , Use this command to set the given key to be monitored . If monitored key When the value is modified outside this transaction , Then the instructions of the firm will not be executed .Watch The command is equivalent to an optimistic lock in a relational database .
 Return value ： Monitoring successful , return OK.

Pessimistic locking ：

• Very pessimistic , There are always problems , Whatever you do, you'll lock it

Optimism lock ：

• Very optimistic. , There will be no problem at any time , All will not be locked , When you update the data, judge , Whether someone has modified the data during this period ！
• obtain version
• When updating, compare version

Example 5： Normal execution succeeded

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 money object 
OK
127.0.0.1:6379> multi  # The transaction is executed normally , No changes have occurred during the data , At this time, the implementation will be successful ！
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) (integer) 20
127.0.0.1:6379> 

Example 6： Multithreaded execution , Execution failure

# Threads 1 =================================
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 money object 
OK
127.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 # Perform before , Another thread modified the data , At this time, the transaction execution will fail 
(nil)
127.0.0.1:6379> 

# Threads 2 ================================
[[email protected] ~]$ cd /usr/local/bin
[[email protected] bin]$ redis-cli -p 6379
127.0.0.1:6379> clear
127.0.0.1:6379> get money
"100"
127.0.0.1:6379> set money 1000
OK
127.0.0.1:6379> 

（5）unwatch

 grammar ：unwatch
 function ： Clear all previously monitored keys for a transaction .
	   If in watch After the command, you call EXEC or DISCARD command , So you don't have to call it manually UNWATCH command .
 Return value ： Clear successfully , return OK.

Example 7： Unlock and then lock

127.0.0.1:6379> get money
"1000"
127.0.0.1:6379> UNWATCH # If transaction execution fails , Just unlock 
OK
127.0.0.1:6379> WATCH money  # Get the latest value , Watch again 
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> DECRBY money 1
QUEUED
127.0.0.1:6379> INCRBY out 1
QUEUED
127.0.0.1:6379> exec # Compare the monitored values , If there is a change, the implementation is successful ！
1) (integer) 999
2) (integer) 1
127.0.0.1:6379> 

3、Redis Three characteristics of transaction

• Separate isolation operation ：
  • All commands in the transaction are serialized 、 Execute in sequence . The transaction is in progress , Will not be interrupted by command requests from other clients , Unless used watch Commands monitor certain keys .
• 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
• The atomicity of transactions is not guaranteed ：
  • redis If a command fails in the same transaction , Subsequent orders may still be executed ,redis The transaction was not rolled back .Redis Function simplification has been carried out inside the system , This ensures faster running speed , because Redis The ability to roll back transactions is not required .