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

This article mainly explains "Redis to achieve distributed lock scheme", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let Xiaobian take you to learn "Redis to achieve distributed lock scheme"!

In actual project development, we often encounter such a business scenario: if the same machine has multiple threads robbing the same shared resource, the same thread will execute many times and an exception will occur. In this case, non-thread safety will occur. Our solution is usually to use locks. But what if there are multiple machines? At this time we usually use distributed locks to solve the synchronization problem of shared resources in distributed environments. Redis, zookeeper, etc. are common in implementing distributed locks. Today, we mainly talk about how to use Redis to implement distributed locks.

The solution of using Redis to implement distributed locks is actually very simple. First, we first implement a solution one: each time the request is executed, the machine first queries Redis whether there is a distributed lock key. If there is no lock key, the lock is taken as the key, and the value is written to Redis as a random number, and then the request is executed.

The solution looks very simple, but such processing logic inevitably has two fatal bugs: First, if a process successfully obtains a lock, but at this time the machine fails, the distributed lock is not released, resulting in deadlock. Second, if two machines query Redis at the same time, they both find that Redis does not have a lock key, so they both successfully obtain the lock.

At this point we can deal with improvement scheme one implementation scheme two: Redis has a command that provides an atomic write operation: setnx, setnx only allows the key value to be set if the lock key does not exist, so the problem that the same lock may be acquired by different machines at the same time can be solved, and the setnx command can set the timeout time of the key value, so when writing the lock key, you can set a timeout time for the lock. If the lock is not released after the timeout time, it will be released. Then other machines can continue to write the key possession lock to execute the corresponding request after the key is released. In this way, the problem that the lock cannot be released in time due to machine downtime is also solved.

But this creates another potential problem: if a machine performs a time-consuming operation, the timeout period elapses before the request is completed, the lock will be released and occupied by a new machine. When the time-consuming task is completed, the lock will be released, not its own lock but a lock already occupied by another machine.

At this time, we can make appropriate modifications to the scheme to become scheme 3: when a machine owns the lock and sets the key in Redis, set the value to a random number, and add one step before the request is processed and the lock needs to be released: Judge whether the value of key is equal to the random number set before. If it represents the owner of the lock or himself, the lock release operation can be executed. Otherwise, it represents that the lock has been occupied by others and the lock release operation cannot be executed. In this way, the problem that the lock of others may be released by mistake can be solved. However, since querying and releasing locks are non-atomic, one scenario may arise: When querying the key, we find that the value of the key is consistent with the machine itself. However, before the lock is released urgently, the lock expires and is released. At this time, executing the lock release operation will result in the release of locks owned by other machines. Therefore, we need to further improve Scheme 3. That is, we must ensure that the two steps of querying the lock and releasing the lock must be atomic. At this time, we need to use another method: Jedis is introduced, and Lua script is used to write the logic of querying lock and releasing lock into script. Therefore, when Redis executes Lua script, all commands of other machines must wait until Lua script execution ends, so it is impossible for other machines to occupy the query lock before it is released.

Here we have introduced how to use Redis to implement distributed locks, but this is based on stand-alone deployment. If Redis is deployed using multiple machines, each master node has child nodes. Since Redis master-slave replication is asynchronous operation, the above scheme will definitely have problems. Multi-machine deployment can use Redison to implement distributed locks. This is an official component. If you are interested, you can read the following file:

https://github.com/redisson/redisson

At this point, I believe that everyone has a deeper understanding of "the scheme of realizing distributed locks with Redis". It is advisable to actually operate it! Here is the website, more related content can enter the relevant channels for inquiry, pay attention to us, continue to learn!

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.