Transaction Mechanism and Optimistic Lock Implementation in redis


Redis transaction mechanism

In other databases such as MySQL, transactions represent a set of actions that are either fully executed or not executed.

Redis’s current support for things is relatively simple. Redis can only guarantee that commands in a client-initiated transaction can be executed continuously without inserting other client commands in the middle. When a client issues a multi command in a link, the link enters a transaction context. The subsequent commands of the connection are not executed immediately, but first placed in a queue. When exec commands are executed, redis executes all the commands in the queue sequentially.

Multi opens transactions: [1]> multi # Open transaction
OK [1]> set age 15 # data operation command
QUEUED [1]> set age 20 # data operation command
QUEUED [1]> exec # Execution transaction
1) OK
2) OK[1]> get age
Discard: Cancel a transaction. This command actually empties the command in the transaction queue and exits the transaction context, that is, transaction rollback.[1]> get age
"20"[1]> multi 
OK[1]> set age 25
QUEUED[1]> set age 30
QUEUED[1]> discard # Clean-up transaction queue
OK[1]> get age

Note the redis transaction problem: Usually if one transaction fails in the transaction queue, the whole transaction will roll back, but other transaction commands will not roll back in redis.

Optimistic lock:Redis are mostly based on data version recording mechanism. That is to say, adding a version identifier to the data. In the version solution based on database tables, it is usually realized by adding a version field to the database tables. When reading the data, read the version number together, and then add 1 to the version number when updating. At this time, the version number of the submitted data is compared with the current version number of the corresponding record in the database table. If the version number of the submitted data 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 when exec changes the monitored key from calling watch, the entire transaction fails. You can also call watch to monitor multiple keys multiple times, thus optimizing the lock on the specified transaction key. Note that the watch key is valid for the entire link, as is the transaction. If the link is disconnected, monitoring and transactions are automatically cleared. Of course, exex, discard, unwatch commands automatically clear all monitors in the link.

The realization of optimistic lock in redis:

Assuming that there is a key of an age, we open two sessions to assign an age.

session1:> get age
"10" > watch age # Open the monitoring of age keys (monitor whether other operations modify age keys)
OK > multi # Open Transaction Context

session2:> set age 20
OK> get age

Direct operation age in session 2

Look at session 1 again: > set age 30 # After operating age in session 2, we continue to operate age in session 1.
QUEUED > exec # Execution transaction returned to nil transaction execution was unsuccessful.
(nil)> get age

Here we find that the transaction cannot be successfully executed because the data version in session 1 is smaller than the data version in the database.This is the optimistic lock in redis.

The last leg of a journey marks the halfway point.


The above is all about the transaction mechanism and optimistic lock implementation in redis. I hope it will be helpful to you. Interested friends can continue to refer to this site: sqlserver: Query Lock SQL and unlock method, several more important MySQL variables, master-log and relay-log relational code of MySQL master-log and slave libraries. Detailed explanation and so on, if there are deficiencies, welcome to leave a message pointing out that Xiaobian will reply to you in time and make corrections, thank friends for their support of the site!