Pen name: haibiscuit
Blog Park: https://www.cnblogs.com/haibiscuit/
Git address: https://github.com/haibiscuit?tab=repositories (welcome star)
The project address: https://github.com/haibiscuit/StudyBook
Respect the author's labor achievements, please do not reprint without permission
Foreword:
I just had an interview, and of course I hung up, so I wrote this article to suppress myself and smooth my aggrieved heart.
text:
One: Problems faced by distributed locks
1.1 The lock needs to be unique
1.2 The lock needs to have a timeout period to prevent deadlock
1.3 The creation of locks and the setting of lock timeouts need to be atomic
1.4 Lock timeout
1.5 The problem of reentrant locks
1.6 The problem of distributed locks in the cluster
1.7 Other issues to consider for redis distributed locks
Two: Explanation and solutions of problems faced by distributed locks
2.1 The lock needs to be unique
Explanation of the problem:
First of all, the problem to be solved by distributed locks is that the same resource is accessed and operated by multiple processes in a distributed environment. Since it is the same resource, you must definitely consider data security issues. In fact, the principle of locking and unlocking under a single process is Similarly, in a single process, multiple threads need to consider the access and modification of the same variable.In order to ensure that the same variable is not accessed by multiple threads at the same time, to modify the variable in order, it is necessary to lock when accessing the variable. The lock can be a heavyweight lock or an optimistic lock based on cas.
solution:
Use the redis command setnx (set if not exist), which can only be occupied by a client.If a redis instance has a unique key, if you want to set a value on the key, it will be rejected.
2.2 The lock needs to have a timeout period to prevent deadlock
Explanation of the problem:
Redis needs the operation of the client to release the lock.If the client suddenly hangs at this time, there is no operation to release the lock.It also means that other clients want to re-lock, but they cannot add the problem.
solution:
Therefore, in order to avoid the problem that the client hangs or the client cannot release the lock normally, it is necessary to add a timeout to the lock while adding the lock.
That is, the operations of adding a lock and adding a timeout to the lock are as follows:
> setnx lockkey true #Lock operation
ok
> expire lockkey 5 #Add a timeout to the lock
... do something critical ...
> del lockkey #release lock
(integer) 1
2.3 The creation of locks and the setting of lock timeouts need to be atomic
Explanation of the problem:
Through the setting of 2.3 lock and timeout time, you can see that setnx and expire require two commands to complete the operation, that is, two RTT operations are required.If between the two commands of setnx and expire, the client suddenly hangs, which When the lock cannot be released, and the problem of deadlock is returned.
solution:
Use the set extended command
as follows:
> set lockkey true ex 5 nx #Lock, expiration time 5s
ok
... do something critical ...
>del lockkey
The above set lockkey true ex 5 nx command can complete the two operations of setnx and expire at one time, which is to solve the atomicity problem.
2.4 Lock timeout
Explanation of the problem:
Although the timeout is added to the lock above, the client cannot necessarily complete the scheduled task within the timeout, so even if the current client does not complete the task, other clients will successfully set the lock at this time The same resource will face the problem of multiple clients operating simultaneously.
solution:
The client can perform scheduled tasks after the lock is successfully set, use the lua script to delete the lock and reset the lock and timeout before the lock times out.
Of course, why do you use lua to complete the operation here? In fact, like the atomic problem above, between deleting the lock and resetting the lock and the lock timeout, you may face other clients occupying the lock resources, and lua has The atomic feature, the two operations of deleting the lock and re-locking are either completed or not completed.
2.5 The problem of reentrant locks
Explanation of the problem:
We talked about above.In order to ensure that the lock is unique, we need to use setnx.Later, in order to set it with the timeout, we chose the set command.
During the lock we want, the client who owns the lock wants to obtain the lock again, which is the lock reentry. Of course, the problem here is similar to the 2.5 problem.
solution:
Similarly, we can choose to use the lua script to delete and set the lock again.
2.6 The problem of distributed locks in a cluster
Explanation of the problem:
This problem will occur in the redis cluster solution. In fact, in order to ensure the high availability and access performance of redis, the master node and slave node of redis will be set up.The master node is responsible for write operations, and the slave nodes are responsible for read operations. It means that all our locks must be written in the main redis server instance.If the main redis server goes down, resources are released (when there is no persistence, if persistence is added, this problem will be more complicated). At the time, the data of the redis master node is not copied to the slave server.At this time, other clients will take the opportunity to acquire the lock, and the client that previously had the lock may still be operating on the resource.At this time, multiple clients will be the same. The problem of resource access and operation.
solution:
This issue is prepared to be discussed separately in writing because it is not clear in one or two sentences.
2.7 Other issues to consider for redis distributed locks
The above discusses the problems that redis will encounter in business logic, and the solution may be limited to the solution I discussed above.
Of course, there is logic that needs to be selected according to the programmer's own scene.
E.g:
(1) When setting the key, where to get the key resource
Among them, the problem of multi-client resource consensus is involved. The simple analysis is how do you determine that when multiple clients lock the same resource, the key needs to be consistent with multiple clients, otherwise, how can I guarantee The uniqueness of the key in multiple clients.
(2) When the lock is released, it can only be released by the client that owns the lock resource
Of course, this problem is due to the incorrect writing of your locking and unlocking logic. According to the above analysis, as long as you solve all the above problems with redis distributed locks, the problem of client lock release is generally not encountered.
However, this is also a matter of detail, which needs to be considered in the business logic
Three: summary
The problem of redis distributed locks in the cluster, I will talk about it in another article
I hope my job stabilizes quickly, come on, cock