A method of implementing transaction mechanism and optimistic locking in Redis

The Redis transaction mechanism, in other databases such as MySQL, represents a set of actions that are either all executed or not executed. This paper mainly introduces the transaction mechanism in Redis and the related content of optimistic lock, through the execution of the transaction to analyze the Redis optimistic lock, has a certain reference value, the need for friends can understand, hope to help everyone.

Redis's current support for things is relatively straightforward. Redis can only guarantee that commands in one client-initiated transaction can be executed consecutively, and no other client commands will be inserted in the middle. When a client issues a multi command in a link, the link goes into a transaction context, and the subsequent command of the connection is not executed immediately, but is placed first in a queue, and Redis executes all commands in the queue sequentially when the EXEC command is executed.

Multi Open transaction:127.0.0.1:6379[1]> Multi #开启事务OK127 .0.0.1:6379[1]> set age #数据操作命令QUEUED127 .0.0.1:6379[1]> set Age #数据操作命令QUEUED127 .0.0.1:6379[1]> exec #执行事务1) OK2) ok127.0.0.1:6379[1]> get Age "Discard: Cancel Transaction, The command actually empties the command in the transaction queue and exits the transaction context, which is the transaction rollback. 127.0.0.1:6379[1]> get Age "a" 127.0.0.1:6379[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 #清空事务队列OK127 .0.0.1:6379[1]> get age "20"

Note Redis transaction issues: In general, if one transaction fails in the transaction queue, the entire transaction is rolled back, but the other transaction commands in Redis are not rolled back.

Optimistic locking: Most Redis is implemented based on the record mechanism of the data version (versions). is to add a version identity to the data, which is typically done by adding a version field to the database table in the versioning solution based on the database table. When the data is read, this version number is read together, and then the version number is added 1 after the update. At this point, the version number of the submitted data is compared to the current version number of the corresponding record in the database table, and if the submitted data version number is greater than the current version number of the database, it is updated, otherwise it is considered to be outdated data.

Watch monitoring: The watch command monitors the given key, and the entire transaction fails if the monitored key has changed since the call to watch. You can also call watch to monitor multiple keys several times, so that the specified transaction key is optimistic about locking. Note that watch key is valid for the entire link, and the transaction is the same. If the link is broken, both monitoring and transactions are automatically cleared. Of course, the Exex, discard, unwatch commands automatically clear all the watches in the link.

The implementation of optimistic locking in Redis:

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

Session1:

127.0.0.1:6379> get Age "ten" 127.0.0.1:6379> Watch Age #打开对age键的监控 (monitor if other actions have modified the age key) ok127.0.0.1:6379> Multi #开启事务上下文OK

Session2:

127.0.0.1:6379> set age 20ok127.0.0.1:6379> get age "20"

Operate the age directly in the Session2

See Session1 again:

127.0.0.1:6379> Set Age #在session2中操作age后, we continue operations in Session1 agequeued127.0.0.1:6379> exec #执行事务 return nil transaction execution is unsuccessful. (nil) 127.0.0.1:6379> get age "20"

Here we find that the transaction cannot be performed successfully because the version of the data in Session1 is already smaller than the version of the data in the database. This is the optimistic lock in Redis.