Master the correct posture of Redis distributed lock

Distributed locking is a way to control synchronous access to shared resources between distributed systems. In distributed systems, they often need to coordinate their actions. If different systems or hosts on the same system share one or a group of resources, the access to these resources must be mutually exclusive to prevent interference and ensure consistency. In this case, distributed locks are required

There are three ways to implement distributed locks:

• Implement distributed lock based on database
• Distributed lock based on cache (Redis)
• Distributed lock based on Zookeeper

Today, we will focus on distributed locking based on Redis implementation

Set the value of key to value if and only if the key does not exist. If the given key already exists, SETNX does nothing. Setnx: This parameter is set only when the key does not exist and no operation is performed

Lock:

SET orderId driverId NX PX 30000 If the preceding command is executed successfully, the client successfully obtains the lock, and then can access the shared resource. If the preceding command fails to be executed, the lock fails to be obtained.

Release the lock: the key, determine whether you put the lock.

GrabService:

public interface GrabService {

    /** ** **@param orderId
     * @param driverId
     * @return* /
    public ResponseResult grabOrder(int orderId, int driverId);
}
Copy the code

GrabRedisLockServiceImpl:

@Service("grabRedisLockService")
public class GrabRedisLockServiceImpl implements GrabService {

	@Autowired
	StringRedisTemplate stringRedisTemplate;
	
	@Autowired
	OrderService orderService;
	
    @Override
    public ResponseResult grabOrder(int orderId , int driverId){
        / / to generate the key
    	String lock = "order_"+(orderId+"");
    	/* * If the lock has not been released, e.g., the business logic has been executed halfway, the o&M service has been restarted, or the server has been hung, finally, what can be done? * Add timeout */
// boolean lockStatus = stringRedisTemplate.opsForValue().setIfAbsent(lock.intern(), driverId+"");
// if(! lockStatus) {
// return null;
/ /}
    	
    	/* * Case 2: if the timeout period is added, it will not be added. Operation and maintenance restart */
// boolean lockStatus = stringRedisTemplate.opsForValue().setIfAbsent(lock.intern(), driverId+"");
// stringRedisTemplate.expire(lock.intern(), 30L, TimeUnit.SECONDS);
// if(! lockStatus) {
// return null;
/ /}
    	
    	/* * case 3: The timeout should be added once, instead of 2 lines, * */
    	boolean lockStatus = stringRedisTemplate.opsForValue().setIfAbsent(lock.intern(), driverId+"".30L, TimeUnit.SECONDS);
    	if(! lockStatus) {return null;
    	}
    	
    	try {
			System.out.println("Users."+driverId+"Execute order snatching logic");
			
            boolean b = orderService.grab(orderId, driverId);
            if(b) {
            	System.out.println("Users."+driverId+"Win the order.");
            }else {
            	System.out.println("Users."+driverId+"Failed to get the order"); }}finally {
        	/** * This type of release lock may release someone else's lock. * /
// stringRedisTemplate.delete(lock.intern());
        	
        	/** * The following code to avoid releasing someone else's lock */
        	if((driverId+"").equals(stringRedisTemplate.opsForValue().get(lock.intern()))) { stringRedisTemplate.delete(lock.intern()); }}return null; }}Copy the code

One might ask here, what happens if my business takes longer to execute than the lock is released? We can use a daemon thread, as long as we have the current thread is holding the lock, when the 10 s, daemon thread automatically overtime on this thread for operation, will continue on the 30 s of the expiration time, until the lock is released, is not in the contract, open a child thread, the time is N, every N / 3, N on to continue

Focus:

1. Key is our target to lock, such as the order ID.

2. DriverId is our commodity ID, which is guaranteed to be unique among all lock requests from all clients for a long enough period of time. That is, an order is grabbed by a user.

3. NX indicates that the SET will succeed only if the orderId does not exist. This ensures that only the first client can acquire the lock, and no other client can acquire the lock until it is released.

4. PX 30000 indicates that the lock has an automatic expiration time of 30 seconds. Of course, 30 seconds is just an example, and the client can choose the appropriate expiration time.

5. This lock must be set to an expiration time. Otherwise, when a client acquires a lock, if it crashes or is unable to communicate with the Redis node due to network partitioning, it will hold the lock forever, and other clients will never be able to acquire the lock. Antirez also emphasized this point in the later analysis, and called this expiration time the lock validity time. The client that acquires the lock must complete access to the shared resource within this time.

6. This operation cannot be split.

   SETNX orderId driverId EXPIRE orderId 30 Although these two commands have the same effect as one of the SET commands described in the previous algorithm, they are not atomic. If the client crashes after executing SETNX, there is no chance to execute EXPIRE, causing it to hold the lock forever. Cause a deadlock.

In view of the above two points, Antirez designed the Redlock algorithm. Antirez, the author of Redis, gave a better implementation, called Redlock, which is the official guidance specification of Redis for the implementation of distributed lock. Redlock’s algorithm is described on the Redis website: Redis. IO /topics/dist…

Purpose: Mutually exclusive access to shared resources

Therefore, Antirez proposed a new distributed lock algorithm, Redlock, which is based on N completely independent Redis nodes (N can be set to 5 under normal circumstances), meaning that N Redis data is not interconnected, similar to several strangers

Code implementation:

@Service("grabRedisRedissonRedLockLockService")
public class GrabRedisRedissonRedLockLockServiceImpl implements GrabService {

    @Autowired
    private RedissonClient redissonRed1;
    @Autowired
    private RedissonClient redissonRed2;
    @Autowired
    private RedissonClient redissonRed3;
    
    @Autowired
    OrderService orderService;

    @Override
    public ResponseResult grabOrder(int orderId , int driverId){
        / / to generate the key
        String lockKey = (RedisKeyConstant.GRAB_LOCK_ORDER_KEY_PRE + orderId).intern();
        / / red lock
        RLock rLock1 = redissonRed1.getLock(lockKey);
        RLock rLock2 = redissonRed2.getLock(lockKey);
        RLock rLock3 = redissonRed2.getLock(lockKey);
        RedissonRedLock rLock = new RedissonRedLock(rLock1,rLock2,rLock3);
    
        try {
        	 rLock.lock();
    		// By default, this code sets the key timeout time to 30 seconds, after 10 seconds, then delay
			System.out.println("Users."+driverId+"Execute order snatching logic");
			
            boolean b = orderService.grab(orderId, driverId);
            if(b) {
            	System.out.println("Users."+driverId+"Win the order.");
            }else {
            	System.out.println("Users."+driverId+"Failed to get the order"); }}finally {
        	rLock.unlock();
        }
        return null; }}Copy the code

The client running the Redlock algorithm performs the following steps to acquire the lock:

1. Gets the current time in milliseconds.
2. Execute to N Redis nodes in sequenceAcquiring a lockIn the operation. This fetch operation is the same as the previous one based on a single Redis nodeAcquiring a lockThe process is the same, including value driverId and expiration time (e.gPX 30000, i.e. the duration of the lock). To ensure that the algorithm can continue to run if a Redis node is unavailable, thisAcquiring a lockThe operation also has a time out that is much smaller than the duration of the lock (on the order of tens of milliseconds).
3. When a client fails to acquire a lock from a Redis node, it should immediately try the next Redis node. Failure here should include any type of failure, such as the Redis node being unavailable, or the lock on the Redis node being held by another client
4. Calculate how long it took to acquire the lock by subtracting the time recorded in step 1 from the current time. If the client successfully obtains the lock from most of the Redis nodes (>= N/2+1), for example, if three of the five machines are successfully locked, the lock is successfully added by default, and the total time consumed in obtaining the lock does not exceed the lock validity time, then the client considers the lock is successfully acquired. Otherwise, the lock fails to be obtained
5. If the lock is acquired successfully, the lock duration should be recalculated, which is equal to the original lock duration minus the lock duration calculated in step 3.
6. If the lock acquisition ultimately fails (perhaps because the number of Redis nodes acquiring the lock is less than N/2+1, or the entire lock acquisition process takes longer than the initial validity of the lock), the client should immediately initiate lock release for all Redis nodes (the Redis Lua script described earlier).

The process described above is to acquire the lock, but the process of releasing the lock is relatively simple: the client initiates the lock release operation to all Redis nodes, regardless of whether they were successful or not at the time of acquiring the lock.