Implementation of redis distributed lock

Redis The implementation of distributed lock understands the basic concepts

Three core elements of distributed lock implementation ：

Lock

The easiest way is to use setnx command . key It's the only sign of the lock , Name it by business . For example, if you want to give a commodity Lock the seckill activity , You can give key Name it “lock_sale_ goods ID” .

When a thread executes setnx return 1 , explain key It didn't exist , The thread successfully got the lock ; When a thread executes setnx return 0 , explain key Already exist , The thread failed to grab the lock .

Unlock

If you lock it, you have to unlock it . When the thread that gets the lock finishes executing the task , Need to release lock , So that other threads can enter . The simplest way to release the lock The single way is to execute del Instructions .

After releasing the lock , Other threads can continue to execute setnx Command to get the lock .

Lock timeout

What do you mean by lock timeout ？ If a locked thread hangs up during the execution of a task , There's no time to explicitly release the lock , This capital The source will be locked forever （ Deadlock ）, Other threads don't want to come in any more . therefore , setnx Of key A timeout must be set , To ensure that even if not explicitly released , This lock should also be released automatically after a certain time . setnx Timeout parameter is not supported , So you need the amount External instructions expire .

The problem is

setnx and expire Non atomicity of

When a thread executes setnx , Success got the lock , setnx Just executed successfully , It hasn't been implemented yet expire Instructions , node 1 hang It fell off .

have access to set (key, value, time, NX), This can replace setnx Instructions .

del Cause false deletion

If a thread succeeds in getting a lock , And the set timeout is 30 second . For some reason, threads A It's very slow , After that 30 Seconds didn't finish , At this time, the lock will be released automatically after expiration , Threads B Got the lock. . And then , Threads A Finished the mission , Threads A Pick up Try to execute del Command to release the lock . But this time the thread B We're not done yet , Threads A actually Delete the thread B Lock added .

How to avoid this situation ？

Can be in del Make a decision before releasing the lock , Verify whether the current lock is a lock added by itself . As for the concrete realization , It can be locked It's time to put the current thread ID treat as value , And verify... Before deleting key Corresponding value Is it my own thread ID.

The above method is two independent operations , It's not atomic .

We can let the thread obtaining the lock open a guard thread , Used for locks that are about to expire “ life ”.

When it's past 29 second , Threads A We're not done yet , At this time, the daemons will execute expire Instructions , For this lock “ The lives ”20 second . keep Thread protector from 29 Start execution in seconds , Every time 20 Once per second .

When a thread A Finish the task , Will explicitly turn off the daemons .

If node 1 A sudden power failure , Because of the thread A In the same process as the daemons , The daemons will also stop . This lock has expired Hou , No one gave it a life , It's automatically released .