Shulou(Shulou.com)06/01 Report--

Redis transaction mechanism

In other databases such as MySQL, a transaction represents a set of actions that are either performed or not performed at all.

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, and the subsequent commands of the connection are not executed immediately, but are first placed in a queue. When the exec command is executed, redis executes all the commands in the queue sequentially.

Multi Open transaction: 127.0.0.1 set age 6379 [1] > get age # Open transaction OK127.0.0.1:6379 [1] > set age 15 # data Operation Command QUEUED127.0.0.1:6379 [1] > set age 20 # data Operation Command QUEUED127.0.0.1:6379 [1] > exec # execute transaction 1) OK2 [1] > get age "20" Discard: cancel transaction This command is actually emptying the command in the transaction queue and exiting the transaction context, that is, transaction rollback. 127.0.0.1 get age [1] > multi OK127.0.0.1:6379 [1] > set age 25QUEUED127.0.0.1:6379 [1] > set age 30QUEUED127.0.0.1:6379 [1] > discard # clear transaction queue OK127.0.0.1:6379 [1] > get age "20"

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

Optimistic locking: redis is mostly implemented based on the data version (version) recording mechanism. That is, add a version ID to the data, which is generally achieved by adding a version field to the database table in the version solution based on the database table. When reading the data, read out the version number together, and then add 1 to the version number when it is updated. At this point, compare the version number of the submitted data with the current version number of the corresponding record in the database table, and update it if the submitted data version number is greater than the current version number of the database, otherwise it is considered to be out-of-date data.

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

Implementation of optimistic locks in redis:

Suppose you have a key of age, and we open two session to assign values to age.

Session1:

127.0.0.1 get age 6379 > age "10" 127.0.0.1 get age 6379 > multi # Open the monitoring of the age key (monitor whether other operations modify the age key) OK127.0.0.1:6379 > multi # enable transaction context OK

Session2:

127.0.1 6379 > set age 20OK127.0.0.1:6379 > get age "20"

Operate age directly in session2

Take a look at session1:

127.0.0.1 set age 6379 > ageQUEUED127.0.0.1:6379 30 # after operating age in session2, we continue to operate ageQUEUED127.0.0.1:6379 > exec # in session1 to execute the transaction returned unsuccessful execution of the nil transaction. (nil) 127.0.0.1 6379 > get age "20"

Here we find that the transaction cannot be executed successfully because the data version in session1 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.

Summary

These are all the contents of this article about the transaction mechanism and the implementation of optimistic locks in redis. I hope it will be helpful to all of you. Interested friends can continue to refer to this site: sqlserver: query locking sql and unlocking methods, several more important MySQL variables, detailed explanation of the relationship code between MySQL master library binlog (master-log) and slave library relay-log, etc. If there are any deficiencies, welcome to leave a message and point out that the editor will reply you in time and correct them. Thank you for your support to this site!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.