Is the distributed lock of redis an optimistic lock?

To put it simply, Redis uses optimistic locking, which is simpler to implement than pessimistic locking and has better performance in some scenarios. As a lightweight and fast caching engine, Redis is not a full-featured relational database. It is neither necessary nor affordable to use pessimistic locks.

Optimistic Lock, as the name suggests, is very optimistic. Every time you go to get the data, you think that others will not modify it, so you will not lock it. , but when updating, you can check whether others have updated this data during the update. You can use mechanisms such as version numbers. Optimistic locking is suitable for multi-read application types, which can improve throughput.

Optimistic locking strategy: The submitted version must be greater than the current version of the record before updates can be performed (recommended learning: Redis video tutorial)

Redis only provides very limited support for transactions , actually more of an attempt to get around the problem.

First of all, Redis does not execute a set of operations in the same transaction immediately, but puts them into a queue. When EXEC is executed, they are executed together. Transaction execution is globally exclusive, that is, only one transaction is executed at the same time and cannot be interrupted by other transactions in the middle. Redis uses this simplest and worst-performing way to avoid race conditions.

Secondly, in a Redis transaction, if one or more operations fail, other operations will still succeed, which means that it has no rollback mechanism at all.

This method will bring about many serious problems. One of them is that it is impossible to read a certain value first and then perform operations that depend on this value, because if it is placed in a transaction, it will be read at the same moment. Execution, not placing it in the same transaction will lead to race conditions. The solution is to use WATCH, which will monitor one or more variables. If the value of the variable is modified by another transaction after calling WATCH and before the transaction is committed, the entire transaction will fail. This is similar to CAS (Compare and Set) in operating systems. I don't know how WATCH is implemented specifically, but I speculate that it monitors the version number of the specified variable.

Even with WATCH, Redis transactions are severely restricted. First, it does not achieve consistency when reading data, because WATCH does not work for read operations. Second, it does not support rollback. Third, when there are a large number of concurrent write operations on the same variable, the performance will be very poor, because each time a transaction is submitted, the variables monitored by WATCH have been modified, causing the transaction to fail to submit multiple times. However, Redis is originally a KV type cache engine. It has to deal with scenarios of large amounts of reading and small amounts of writing, and there is no requirement for consistency.

For more Redis-related technical articles, please visit the Introduction to Using Redis Database Tutorial column to learn!

The above is the detailed content of Is the distributed lock of redis an optimistic lock?. For more information, please follow other related articles on the PHP Chinese website!