Implementation of transaction mechanism and optimistic lock in redis

  • 2020-05-30 21:16:44
  • OfStack

Redis transaction mechanism

In other databases, such as MySQL, a transaction represents a set of actions that either all or none of the actions are executed.

Redis's current support for things is relatively simple. Redis can only guarantee that commands in a transaction initiated by client can be executed continuously without any other client commands being inserted. When an client issues an multi command in a link, this link will enter a transaction context. The subsequent commands of this connection will not be executed immediately, but will be placed in a queue first. When the exec command is executed, redis will execute all the commands in the queue in order.

Multi  Start transaction:[1]> multi # Open the transaction 
OK[1]> set age 15 # Data manipulation command 
QUEUED[1]> set age 20 # Data manipulation command 
QUEUED[1]> exec # Perform transactions 
1) OK
2) OK[1]> get age
Discard : cancels a transaction, which essentially empties the command in the transaction queue and exits the transaction context, i.e., transaction rollback.[1]> get age
"20"[1]> multi 
OK[1]> set age 25
QUEUED[1]> set age 30
QUEUED[1]> discard # Empty transaction queue 
OK[1]> get age

Note the redis transaction problem: normally if one transaction in the transaction queue fails, the entire transaction is rolled back, but other transaction commands are not rolled back in redis.

Optimistic locking: most of redis is implemented using the data version (version) logging mechanism. Add a version id to the data. In database table-based version solutions, 1 is usually achieved by adding an version field to the database table. This version 1 is read out with the data as it is read, and it is incremented by 1 when it is later updated. At this point, the version number of the submitted data is compared with the current version number of the corresponding record in the database table. If the submitted data version number is larger than the current version number of the database, it will be updated; otherwise, it will be considered as expired data.

watch monitoring: the watch command monitors a given key, and if the monitored key has changed since the watch call, the entire transaction will fail. You can also call watch to monitor multiple key multiple times, which adds an optimistic lock to the specified transaction key. Note that watch's key is valid for the entire link, as is the transaction. If the link is broken, monitoring and transactions are automatically cleared. Of course, the exex, discard, unwatch commands automatically clear all the monitoring in the link.

Implementation of optimistic locking in redis:

If we have one key of age, we turn on two session to assign age.

session1:> get age
"10"> watch age # Open to age Key monitoring (monitors whether other operations are correct age Key has modified operation) 
OK> multi # Enable transaction context 

session2:> set age 20
OK> get age

Directly operate age in session2

Then look at session1:> set age 30 # in session2 In the operation age After, we are in session1 Medium continue operation age
QUEUED> exec # Perform transactions   return nil  The transaction did not execute successfully. 
(nil)> get age

Here we find that the transaction failed because the data version in session1 is already smaller than the data version in the database. This is the optimistic lock in redis.

A hundred miles is half 910.


Above is this article about redis transaction mechanism and the realization of optimistic locking the entire contents of the, hope to be of service, interested friends can continue to see this site: sqlserver: query lock sql and unlock method, a few of the more important MySQL variables, MySQL main library binlog (master - log) relationship with from library relay - log code, etc., if there are any shortcomings, welcome message pointed out that this site will reply you in a timely and correct them, thank you friends support for this site!

Related articles: