Redis transaction and optimistic lock

Preface

• Business

① Atomicity （atomicity）. A transaction is an indivisible unit of work , The operations included in the transaction either do , Either not .
② Uniformity （consistency）. The transaction must be to change the database from one consistency state to another . Consistency is closely related to atomicity .
③ Isolation, （isolation）. The execution of one transaction cannot be interfered by other transactions . That is, the operations and data used within a transaction are isolated from other concurrent transactions , Transactions that execute concurrently cannot interfere with each other .
④ persistence （durability）. Permanence is also called permanence （permanence）, Once a transaction is committed , Its changes to the data in the database should be permanent . Subsequent operations or failures should not have any impact on it .
stay Redis There is no concept of transactions without isolation levels ！
stay Redis A single imperative guarantees atomicity , But transactions don't guarantee atomicity ！

• Optimism lock

① When concurrency may occur in a program , It is necessary to ensure the accuracy of data in the case of concurrency , This ensures that when the current user operates with other users , The result obtained is the same as when he operated alone .
② No concurrency control , It may cause dirty reading 、 Unreal reading and non repeatable reading .
stay Redis It can be realized Optimism lock Of ！

One 、Redis How to implement transactions ？

① Normal execution of business

127.0.0.1:6379> multi  # Open transaction 
OK
127.0.0.1:6379> set name dingyongjun  # Add data 
QUEUED
127.0.0.1:6379> set age 26  # Add data 
QUEUED
127.0.0.1:6379> set high 172  # Add data 
QUEUED
127.0.0.1:6379> exec   Perform transactions 
1) OK
2) OK
3) OK
127.0.0.1:6379> get name  # Data acquisition success , Prove the successful execution of the transaction 
"dingyongjun"
127.0.0.1:6379> get age
"26"

② Give up the business

127.0.0.1:6379> multi  # Open transaction 
OK
127.0.0.1:6379> set name dingyongjun  # Add data 
QUEUED
127.0.0.1:6379> set age 26  # Add data 
QUEUED
127.0.0.1:6379> discard  # Give up the business 
OK
127.0.0.1:6379> get name  # Will not perform the add operation in the transaction 
(nil)

③ Compile time exception , Something is wrong with the code , Or there's a problem with the command , All orders will not be executed

127.0.0.1:6379> multi  # Open transaction 
OK
127.0.0.1:6379> set name dingyongjun  # Add data 
QUEUED
127.0.0.1:6379> set age 23  # Add data 
QUEUED
127.0.0.1:6379> getset name  # Enter a wrong command , At this time, it has been reported wrong , But this is still in the queue of transactions 
(error) ERR wrong number of arguments for 'getset' command
127.0.0.1:6379> set high 173  # Add data 
QUEUED
127.0.0.1:6379> exec  # Perform transactions , Report errors , And all commands will not be executed 
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get name  # Get data is empty , Prove that it has not been implemented 
(nil)

④ Runtime exception , Except that syntax errors are not executed and exceptions are thrown , Other correct commands can be executed normally

127.0.0.1:6379> multi  # Open transaction 
OK
127.0.0.1:6379> set name dingyongjun  # Add string data 
QUEUED
127.0.0.1:6379> incr name  # Perform auto increment operation on string data 
QUEUED
127.0.0.1:6379> set age 23  # Add data 
QUEUED
127.0.0.1:6379> get age  # get data 
QUEUED 
127.0.0.1:6379> exec  # Perform transactions . Although an error is reported when the string data is auto incremented , But other commands can be executed normally 
1) OK
2) (error) ERR value is not an integer or out of range
3) OK
4) "23"
127.0.0.1:6379> get age  # Data acquisition success 
"23"

⑤ summary ： It can be concluded from the above ,Redis It supports single command transactions , But transactions do not guarantee atomicity ！

Two 、Redis How to achieve optimistic lock ？

①watch（ monitor ）

127.0.0.1:6379> set money 100  # Add money 100
OK
127.0.0.1:6379> set cost 0  # Add expenses 0
OK
127.0.0.1:6379> watch money  # Monitor money 
OK
127.0.0.1:6379> multi  # Open transaction 
OK
127.0.0.1:6379> DECRBY money 30  # money -30
QUEUED
127.0.0.1:6379> incrby cost 30  # cost +30
QUEUED
127.0.0.1:6379> exec  # Perform transactions , success ！ At this time, the data can be successful only if there is no change 
1) (integer) 70
2) (integer) 30

② Multithreaded testing watch
# Threads 1

# Threads 1
127.0.0.1:6379> set money 100  # Add money 100
OK
127.0.0.1:6379> set cost 0  # Add expenses 0
OK
127.0.0.1:6379> watch money  # Turn on Monitoring （ Optimism lock ）
OK 
127.0.0.1:6379> multi  # Open transaction 
OK
127.0.0.1:6379> DECRBY money 20  # money -20
QUEUED
127.0.0.1:6379> INCRBY cost 20   # cost +20
QUEUED
# Don't execute here , First execution thread 2 To modify the monitored value 
127.0.0.1:6379> exec  # Error report in execution , Because we watched money This value , If the transaction wants to operate on this value 
# The monitor will judge whether this value is normal , If there is a change , Transaction execution failed ！
(nil)

# Threads 2

# Threads 2, This operation is executed before the transaction is executed 
127.0.0.1:6379> INCRBY money 20  # money +20
(integer) 120

③ summary ： The difference between optimistic lock and pessimistic lock .
Pessimistic locking ：  There's always a problem , So keep watching , Before the current step is completed , Don't let any thread execute , It's a waste of performance ！ Generally not used ！
Optimism lock ：  Only judge when updating the data , Has anyone modified the monitored data during this period , If not, carry out the business normally , Otherwise, the execution fails ！