Redis transaction

Redis Concept of transactions ：

Redis The essence of a transaction is a set of commands . Transactions support multiple commands at a time , All commands in a transaction will be sequenced
turn . In the transaction execution process , The commands in the queue will be executed serially in order , Command requests submitted by other clients will not be inserted into the event
Service execution command sequence .
To sum up ：redis Business is a one-off 、 Sequence 、 Exclusive execution of a series of commands in a queue .

Redis Transactions have no concept of isolation levels ：

Bulk operation is sending EXEC The command is put into the queue cache , It's not actually executed ！

Redis There is no guarantee of atomicity ：

Redis in , A single command is executed atomically , But transactions don't guarantee atomicity , And there is no rollback . The execution of any command in the transaction failed , Its
The remaining orders will still be executed .

Redis The three stages of the transaction ：

• Start business
• Order to join the team
• Perform transactions

Redis Transaction related orders ：

watch key1 key2 … # Monitor one or more key, If before the transaction is executed , Under surveillance key Changed by other orders , be The business was interrupted （ Like optimistic lock ） multi # Mark the beginning of a transaction block （ queued ） exec # Execute all transaction block commands （ Once executed exec after , All the previous monitoring locks will be cancelled ） discard # Cancel the business , Discard all commands in the transaction block unwatch # Cancel watch For all key Monitoring of

practice

Normal execution

Give up the business

If there are command errors in the transaction queue （ Be similar to java Compiler error ）, execute EXEC On command , Not all commands
perform

If there is a syntax error in the transaction queue （ Be similar to java Of 1/0 Run time exception for ）, execute EXEC On command , Other correct
The command will be executed , An error command throws an exception .

Watch monitor

Pessimistic locking ：

Pessimistic locking (Pessimistic Lock), seeing the name of a thing one thinks of its function , Is very pessimistic , Every time I go to get the data, I think others will modify it , So every time I was in
It's always locked when I get the data , So people who want to get this data will block Until it gets the lock . In traditional relational databases
Many of these locking mechanisms are used , For example, line locks. , Table lock, etc. , Read the lock , Write locks, etc. , Lock before operation .

Optimism lock ：

Optimism lock (Optimistic Lock), seeing the name of a thing one thinks of its function , Is very optimistic , Every time I go to get the data, I think other people won't modify it , So not
locked . However, when updating, we will judge whether others have updated this data during this period , You can use mechanisms like version numbers , Happy
Watch lock is suitable for multi read application types , This can improve throughput , Optimistic locking strategy ： The submitted version must be greater than the current version of the record to
Perform the update .
test ：
1、 Initialize credit card available balance and outstanding amount

127.0.0.1:6379> set balance 100
OK
127.0.0.1:6379> set debt 0 OK

2、 Use watch testing balance, During the course of business balance Data unchanged , Transaction executed successfully

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

3、 Use watch testing balance, During the course of business balance Data changes , Transaction execution failed ！

#  Window one  
127.0.0.1:6379> watch balance 、
OK127.0.0.1:6379> MULTI #  After execution , Execute window 2 code test  
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 #  Modification failed ！ 
(nil)
#  Window two  
127.0.0.1:6379> get balance 
"80" 
127.0.0.1:6379> set balance 200 
OK
#  Window one ： Give up monitoring after a problem occurs , Then start again ！ 
127.0.0.1:6379> UNWATCH #  Give up surveillance  
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 #  success ！ 
1) (integer) 180 
2) (integer) 40

explain ：
Once implemented EXEC After opening the execution of the transaction , No matter the transaction is executed successfully , WARCH Monitoring of variables will be cancelled .
So when the transaction fails , It needs to be re executed WATCH Commands monitor variables , And open a new transaction to operate .

Summary

watch Instructions are similar to optimistic locks , At transaction commit , If watch Monitoring multiple KEY In any of the KEY The value of has been changed by another client , Then use EXEC When the transaction is executed , The transaction queue will not be executed , At the same time return to Nullmulti-bulk Reply to notify the caller that the transaction failed .