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

Editor to share with you whether the distributed lock in redis is optimistic. I hope you will learn a lot after reading this article. Let's discuss it together.

To put it simply, Redis uses optimistic locks, which are simpler to implement than pessimistic locks and perform better in some scenarios. As a lightweight and fast caching engine, rather than a fully functional relational database, Redis does not need to use pessimistic locks, nor can it bear the cost of using pessimistic locks.

Optimistic lock (Optimistic Lock), as the name implies, 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 you update it, you can use mechanisms such as version number to determine whether others have updated the data during the second period. Optimistic locks are suitable for multi-read applications, which can improve throughput.

Optimistic locking policy: the submitted version must be greater than the current version of the record to perform the update

Redis only provides very limited support for transactions, but it's more of an attempt to get around the problem.

First, Redis is for a set of operations in the same transaction, instead of being executed immediately, it is put into a queue, and when executed to EXEC, it is executed together. Transaction execution is globally exclusive, that is, only one transaction is executed at a time and cannot be interrupted by other transactions. Redis avoids race condition in this simplest and worst-performing way.

Second, in a Redis transaction, if one or more operations fail, the other operations will still succeed, that is, there is no rollback mechanism at all.

This approach brings a lot of serious problems, one of which is that it is impossible to read a value before relying on it, because putting it in a transaction will be executed at the same moment, and not in the same transaction will lead to race condition. The solution is to use WATCH, which monitors one or more variables, and if the value of the variable is modified by another transaction after calling WATCH and before the transaction commits, the entire transaction will fail. This is similar to CAS (Compare and Set) in the operating system. I don't know exactly how WATCH is implemented, 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, performance can be very poor when there are a large number of concurrent writes to the same variable, because the variables monitored by WATCH have been modified each time the transaction is committed, resulting in multiple commit failures. However, Redis is already a KV-type caching engine that deals with scenarios where there are a lot of reads and few writes, and there is no requirement for consistency.

After reading this article, I believe you have a certain understanding of whether the distributed lock in redis is optimistic. If you want to know more about it, welcome to follow the industry information channel. Thank you for your reading!

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.