Redis transaction mechanism, in MySQL and other databases, a transaction represents a set of actions, which are either all executed or not executed at all. This article mainly introduces the transaction mechanism and optimistic locking in redis. The analysis of Redis optimistic locking through transaction execution has certain reference value. Friends who need it can learn about it. I hope it can help everyone.
Redis’ current support for things is relatively simple. Redis can only guarantee that commands in a transaction initiated by a client can be executed continuously without inserting other client commands in the middle. When a client issues a multi command in a link, the link will enter a transaction context. Subsequent commands of the connection will not be executed immediately, but will be placed in a queue first. When the exec command is executed, redis will execute it sequentially. All commands in the queue.
Multi 开启事务: 127.0.0.1:6379[1]> multi #开启事务 OK 127.0.0.1:6379[1]> set age 15 #数据操作命令 QUEUED 127.0.0.1:6379[1]> set age 20 #数据操作命令 QUEUED 127.0.0.1:6379[1]> exec #执行事务 1) OK 2) OK 127.0.0.1:6379[1]> get age "20" Discard:取消事务,该命令实际是清空事务队列中的命令并退出事务上下文,也就是事务回滚。 127.0.0.1:6379[1]> get age "20" 127.0.0.1:6379[1]> multi OK 127.0.0.1:6379[1]> set age 25 QUEUED 127.0.0.1:6379[1]> set age 30 QUEUED 127.0.0.1:6379[1]> discard #清空事务队列 OK 127.0.0.1:6379[1]> get age "20"
Attention to redis transaction issues: Usually if a transaction fails in the transaction queue, the entire transaction will be rolled back, but other transaction commands in redis will not be rolled back.
Optimistic locking: Redis is mostly implemented based on the recording mechanism of data version (version). That is to add a version identifier to the data. In a version solution based on a database table, this is usually achieved by adding a version field to the database table. When reading data, read this version number together, and add 1 to this version number when updating later. 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 greater 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 will monitor the given key. If the monitored key has changed since calling watch during exec, the entire transaction will fail. You can also call watch multiple times to monitor multiple keys, so that optimistic locking is added to the specified transaction key. Note that the watch key is valid for the entire link, and the same is true for transactions. If the link is broken, both the watch and the transaction are automatically cleared. Of course, the exex, discard, and unwatch commands will automatically clear all monitoring in the link.
Implementation of optimistic locking in redis:
Assuming there is an age key, we open two sessions to assign values to age.
session1:
127.0.0.1:6379> get age "10" 127.0.0.1:6379> watch age #打开对age键的监控(监控其他操作是否对age键有修改操作) OK 127.0.0.1:6379> multi #开启事务上下文 OK
session2:
127.0.0.1:6379> set age 20 OK 127.0.0.1:6379> get age "20"
Directly operate age in session2
Look at session1 again:
127.0.0.1:6379> set age 30 #在session2中操作age后,我们在session1中继续操作age QUEUED 127.0.0.1:6379> exec #执行事务 返回nil 事务执行不成功。 (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 already smaller than the data version in the database. This is optimistic locking in redis.
Related recommendations:
A brief introduction to the transaction mechanism in MySQL
In-depth understanding of the transaction mechanism in MySQL_MySQL
redis Optimistic lock practice flash sale
The above is the detailed content of Methods to implement transaction mechanism and optimistic locking in redis. For more information, please follow other related articles on the PHP Chinese website!