Redis implements distributed locks

Application scenarios

1. The seckill system is overbought and oversold
2. Massive access when cache fails （ Cache breakdown ）

Distributed locks

Distributed lock is the implementation of a lock that controls different processes in a distributed system to jointly access shared resources . Different hosts share a critical resource , It is often necessary to prevent mutual interference through mutual exclusion , Guarantee consistency .

Distributed lock features

1. Mutually exclusive ： Anytime , Only one client can hold the lock
2. Lock timeout release ： Prevent unnecessary waste of resources , Avoid deadlock
3. Reentrancy ： After a thread acquires the lock , The request can be locked again
4. High performance and high availability ： The cost of locking and unlocking should be minimized , At the same time, ensure high availability , Avoid distributed lock failures
   Security ： The lock can only be removed by the client holding it , Cannot be deleted by other clients

Achieve one ：SETNX + EXPIRE

adopt SETNX Get the lock , Obtain the lock and then use EXPIRE Set expiration time , Prevent the lock from forgetting to release .

if（jedis.setnx(key_resource_id,lock_value) == 1）{
     // Lock 
    expire（key_resource_id,100）; // Set expiration time 
    try {
    
        do something  // Business request 
    } catch() {
    
  	}
  	finally {
    
       jedis.del(key_resource_id); // Release the lock 
    }
}

It's not atomic
SETNX And EXPIRE It's two orders , It's not atomic . If the system makes an error after obtaining the lock , unexecuted EXPIRE, Expiration time is not set , The lock will never be released ！ Cause a deadlock .
Lock expired release
When the business is too long , I haven't finished my business yet , The lock has expired , At this time, other threads may acquire locks , If the business is processed at this time, the lock will be deleted .（ That is, one thread releases the lock held by another thread , At this time, another thread business may not have been processed ）

Achieve two ：SETNX (value by Specific expiration time )

In order to solve the problem of realizing one middle The abnormal lock cannot be released , You can put the expired time into value in , If the lock acquisition fails, remove value check

long expires = System.currentTimeMillis() + expireTime; // system time + Set expiration time 
String expiresStr = String.valueOf(expires);
 
//  If the current lock does not exist , Returns lock successfully 
if (jedis.setnx(key_resource_id, expiresStr) == 1) {
    
        return true;
} 
//  If the lock already exists , The expiration time of the lock acquired 
String currentValueStr = jedis.get(key_resource_id);
 
//  If you get the expiration time , Less than the current system time , Indicates that it has expired 
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
    
 
     //  Lock expired , Gets the expiration time of the last lock , And set the expiration time of the current lock （ Don't understand redis Of getSet Little friend of command , You can go to the official website ）
    String oldValueStr = jedis.getSet(key_resource_id, expiresStr);
     
    if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
    
         //  Consider the case of multi-threaded concurrency , Only one thread has the same set value as the current value , It can be locked 
         return true;
    }
}
         
// Other situations , All return to lock failure 
return false;
}

1. Time synchronization of each client is required
2. The lock may expire and be occupied by other clients , But it is released by the current client

Realization three ：Lua Scripts guarantee atomicity

The same principle is implemented , But by Lua Scripts guarantee atomicity

//LUA Script 
if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then
   redis.call('expire',KEYS[1],ARGV[2])
else
   return 0
end;
 
// Lock 
String lua_scripts = "if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then" +
            " redis.call('expire',KEYS[1],ARGV[2]) return 1 else return 0 end";   
Object result = jedis.eval(lua_scripts, Collections.singletonList(key_resource_id), Collections.singletonList(values));
// Judge success 
return result.equals(1L);

Realize four ：SET EX PX NX

SET key value [EX seconds] [PX milliseconds] [NX|XX]
NX： Express key When it doesn't exist , can set success , That is to say, only the first client request can obtain the lock , Other clients can only wait for the lock to be released , To get .
EX seconds： Set up key The expiration time of , The unit of time is seconds .
PX milliseconds： Set up key The expiration time of , The unit is millisecond
XX： Only when the key Set the value... When it exists

if（jedis.set(key_resource_id, lock_value, "NX", "EX", 100s) == 1）{
     // Lock 
    try {
    
        do something  // Business processing 
    }catch(){
    
  }
  finally {
    
       jedis.del(key_resource_id); // Release the lock 
  }
}

Realize five ： Add a unique check value

SET EX PX NX + Verify unique random values , Release the lock again

The lock may be accidentally deleted by another thread , Then we will give value Value sets a random number that marks the current thread as unique , When deleting , Check it out , No OK Yes

if（jedis.set(key_resource_id, uni_request_id, "NX", "EX", 100s) == 1）{
     // Lock 
    try {
    
        do something  // Business processing 
    }catch(){
    
   }
   finally {
    
       // Judge whether it is the lock added by the current thread , Just released 
       if (uni_request_id.equals(jedis.get(key_resource_id))) {
    
        jedis.del(lockKey); // Release the lock 
        }
    }
}

It is not atomic to judge whether the lock added and released for the current thread . Maybe this lock no longer belongs to the current client ！ It can also be done through Lua Scripts instead of atomic operations .

if redis.call('get',KEYS[1]) == ARGV[1] then 
   return redis.call('del',KEYS[1]) 
else
   return 0
end;

Realize six ：Redisson

Check every once in a while if the lock still exists , If it exists, the expiration time of the lock will be extended , Prevent lock expiration and early release .

Redisson This process is realized , Schematic diagram is as follows

As long as the thread succeeds in locking , Will start a watch dog watchdog , It's a background thread , Every time 10 Second check , If the thread 1 And hold the lock , Then it will keep extending the lock key Survival time . therefore ,Redisson It solves the problem that the lock is released after expiration but the business is not completed .

Realize seven ： Multi machine implementation Redlock

in the light of Redis colony

If a thread is in Redis Of master The lock is held on the node , But locked key It's not synced to slave node . Just then ,master Node failure , One slave The node will be upgraded to master node . Thread two can get the same key It's my lock , But thread one has got the lock , The security of the lock is gone .

To solve this problem ,Redis An advanced distributed lock algorithm is proposed ：Redlock. Let's assume that there are 5 individual Redis master node , stay 5 Run these on servers Redis example , As shown in the figure below ：

be RedLock The implementation steps are as follows ：

• In order to 5 individual master Node request lock .
• Judge according to the set timeout , Do you want to skip the master node .
• If greater than or equal to 3 Nodes （N/2+1, Here is 5/2+1=3 Nodes ） Locking success , And the use time is less than the validity period of the lock , You can confirm that the locking is successful .
• If the lock acquisition fails , Unlock ！