SoFunction
Updated on 2025-03-02

Redis: Solutions to problems that need to be considered when implementing distributed locks

introduction

Multiple nodes in distributed systems often need to conduct concurrent access to shared resources. Without an effective coordination mechanism, it may lead to data competition, resource conflict and other problems. Distributed locks came into being, and it is a mechanism that ensures that multiple nodes can safely access shared resources in a distributed environment. In Redis, using its atomic operation and high performance features have become a common solution to implement distributed locks.

However, using Redis to implement distributed locks is not a simple process. Developers need to consider a variety of issues, such as lock competition, lock release, timeout management, network partitioning, etc. This article will explore these issues in detail and provide solutions and code examples to help developers implement distributed locks correctly and safely using Redis.

Part 1: What is distributed lock?

1.1 Definition of distributed locks

Distributed locking is a coordination mechanism that ensures that multiple processes or threads in a distributed system can safely access shared resources. With distributed locking, it is possible to ensure that only one node can operate on a resource at the same time, thereby avoiding data competition or resource conflict.

1.2 Features of distributed locks

  • Mutual Exclusion: Only one client can hold the lock at the same time.
  • Lock timeout: The client cannot hold the lock for an infinite time, and the lock's automatic release mechanism must be set to prevent deadlocks.
  • Reentrability: In some scenarios, the same client is allowed to acquire the lock multiple times without causing the lock to fail.
  • Fault tolerance: Even if some nodes fail, the lock mechanism can still ensure the normal operation of the system.

1.3 Application scenarios of distributed locks

  • Inventory deductions in e-commerce systems: When multiple users purchase the same item at the same time, it is necessary to ensure the correct deduction of inventory through distributed locks.
  • Generation of unique order numbers in order system: Ensure that in high concurrency scenarios, no duplicate order numbers are generated.
  • Timed task scheduling: Ensure that at the same time, only one node is performing the timing task.

Part 2: The basic principle of Redis implementing distributed locks

2.1 Atomic operation of Redis

Redis supports a variety of atomic operations, which makes it ideal for implementing distributed locks.SETNX(set if not exists) is one of the common atomic operations. It ensures that the key is set successfully only if the key does not exist.

// Use SETNX to implement distributed locksboolean acquireLock(Jedis jedis, String lockKey, String clientId, int expireTime) {
    String result = (lockKey, clientId, ().nx().px(expireTime));
    return "OK".equals(result);
}

In the above code,SETNXThe following logic is implemented:

  • If the lock key does not exist, set the lock and return "OK", indicating that the lock is acquired successfully.
  • If the lock key already exists, a null value is returned, indicating that the lock has failed to acquire.

2.2 Automatic release mechanism of lock

To avoid deadlock problems caused by the client not actively releasing the lock for some reason (such as a downtime or a network failure), the timeout time of the lock is usually set when acquiring the lock. This can be done through RedisPXParameter implementation, which indicates the automatic expiration time of the lock.

("lockKey", "client1", ().nx().px(5000));  // Lock automatically5000Expiration in milliseconds

2.3 Basic process of Redis distributed lock

Client usageSETNXThe command attempts to acquire the lock. If the lock is acquired successfully, the client can perform resource operations. After the client operation is completed, theDELCommand to release the lock. If the client fails during operation, the lock will be automatically released after the specified timeout time to prevent deadlock.

Part 3: Frequently Asked Questions about Redis Implementing Distributed Locks

3.1 Lock release problem

question: The client needs to release the lock after executing the business logic, but it is called directlyDELThe command may accidentally delete locks from other clients. Specifically, after client A acquires the lock, if the execution time is too long for some reason, the lock will automatically expire and release, while client B acquires the lock. If client A continues to execute and callsDELRelease the lock, then the lock of client B may be deleted by mistake.

Solution: In order to avoid accidentally deleting locks from other clients, the client ID should be saved when acquiring the lock. When releasing the lock, first check whether the holder of the current lock is himself. If yes, delete the lock, otherwise no operation will be done.

Code example: Verify the holder when releasing the lock

boolean releaseLock(Jedis jedis, String lockKey, String clientId) {
    String lockValue = (lockKey);
    if ((lockValue)) {
        (lockKey);  // Only when the current client holds the lock will the lock be released        return true;
    }
    return false;
}

To ensure the atomicity of the operation, it is best to use Redis's Lua script to accomplish this logic:

-- Lua script：Ensure the atomicity of the release lock
if ("get", KEYS[1]) == ARGV[1] then
    return ("del", KEYS[1])
else
    return 0
end

Example of calling a Lua script using Jedis:

String luaScript = "if ('get', KEYS[1]) == ARGV[1] then return ('del', KEYS[1]) else return 0 end";
Object result = (luaScript, (lockKey), (clientId));

3.2 Lock timeout problem

question: Setting the timeout time of the lock can prevent deadlock problems, but if the client's business logic execution time exceeds the lock's expiration time, it will cause the lock to be automatically released by Redis when the business logic has not been executed. Other clients may acquire the lock after the lock is released, which causes multiple clients to operate shared resources at the same time, which will cause concurrency problems.

Solution 1: Set the timeout reasonably

It is necessary to estimate the maximum execution time of the business logic based on the business scenario, and reasonably set the timeout time of the lock. If the execution time cannot be accurately predicted, the lock holding time can be extended by refreshing the lock regularly.

Solution 2: Lock Renewal

During the execution of business logic, the remaining time of the lock is regularly checked, and the validity period of the lock is automatically extended when the lock is about to expire. This allows a background thread to periodically refresh the expiration time of the lock.

ScheduledExecutorService scheduler = (1);
void acquireLockWithRenewal(Jedis jedis, String lockKey, String clientId, int expireTime) {
    // Get the lock    boolean acquired = acquireLock(jedis, lockKey, clientId, expireTime);
    if (acquired) {
        // Renew the contract regularly to ensure that the lock does not expire automatically        (() -> {
            if (((lockKey))) {
                (lockKey, expireTime);
            }
        }, expireTime / 2, expireTime / 2, );
    }
}

3.3 Redis downtime problem

question: If the Redis node goes down or is unavailable, all lock information will be lost, resulting in multiple clients operating shared resources at the same time in the system, and the mutual exclusion of distributed locks cannot be guaranteed.

Solution: Master-slave copy and sentinel mode

To solve the lock loss problem caused by Redis downtime, you can use Redis's high availability architecture, such as master-slave replication or Sentinel. By building a highly available Redis cluster, we ensure that even if a node goes down, the system can automatically switch to the backup node and continue to provide distributed lock services.

3.4 Network partitioning issues

question: In a distributed environment, network partitioning (network isolation) may cause some clients to fail to communicate with Redis normally. In this case, some clients may mistakenly believe that they have successfully acquired the lock, while in fact other clients may also acquire the same lock at the same time, thus breaking the mutex of the lock.

Solution: Distributed lock based on Redlock algorithm

In order to ensure the reliability of distributed locks under network partitions, the Redlock algorithm proposed by Redis can be used. Redlock acquires locks on multiple Redis instances at the same time and determines the effectiveness of the lock based on the success of more than half of the instances, so that when network partitions or some nodes are down, the reliability of distributed locks can still be guaranteed.

Basic steps of Redlock algorithm：

  • The client requests to obtain the lock from N independent Redis nodes (recommended N=5).
  • The client sets the same lock timeout for each Redis node and ensures that the time window for acquiring the lock is short (less than the lock timeout).
  • If the client is in most

(That is, it exceeds N/2+1) If the lock is successfully acquired on the Redis node, it is considered that the lock is successfully acquired.
4. If the lock acquisition fails, the client needs to send a release lock request to all nodes that have successfully locked it.

Implementation diagram of Redlock algorithm

+-----------+      +-----------+      +-----------+
|  Redis1   |      |  Redis2   |      |  Redis3   |
+-----------+      +-----------+      +-----------+
      |                   |                   |
      v                   v                   v
Acquisition of lock successfully           Acquisition of lock successfully          Failed to acquire the lock

The Java implementation of the Redlock algorithm can be used by the officialRedissonlibrary.

Part 4: Performance optimization of Redis distributed locks

4.1 Reduce lock holding time

When designing distributed locks, the lock holding time should be minimized. The shorter the lock is held, the higher the concurrency of the system. Therefore, the execution of business logic should be simplified as much as possible, and operations that do not require locking are removed from the locking area.

4.2 Limit the granularity of the lock

By controlling the granularity of the lock, the contention of the lock can be reduced. The smaller the granularity of the lock, the fewer the locked resources and the fewer the competing clients. For example, when processing product inventory, you can set up an independent distributed lock for each product instead of a global lock for the entire inventory.

4.3 Combination of batch operation and distributed lock

In some business scenarios, the frequency of lock acquisition can be reduced through batch operations. For example, in an e-commerce system, when a user places an order, he can first write the order information into the queue or cache it, and then process the orders in the queue through batch tasks to reduce the competition for locks.

Part 5: Complete Example of Redis Distributed Lock

Here is an example of a complete Redis distributed lock that combines the acquisition, release and renewal mechanisms of the lock.

import ;
import ;
import ;
import ;
import ;
import ;
public class RedisDistributedLock {
    private Jedis jedis;
    private String lockKey;
    private String clientId;
    private int expireTime;
    private ScheduledExecutorService scheduler;
    public RedisDistributedLock(Jedis jedis, String lockKey, int expireTime) {
         = jedis;
         = lockKey;
         = ().toString();
         = expireTime;
         = (1);
    }
    // Get the lock    public boolean acquireLock() {
        String result = (lockKey, clientId, ().nx().px(expireTime));
        if ("OK".equals(result)) {
            // Turn on the scheduled task and automatically renew the lock            (() -> renewLock(), expireTime / 2, expireTime / 2, );
            return true;
        }
        return false;
    }
    // Renewal lock    private void renewLock() {
        if (((lockKey))) {
            (lockKey, expireTime);
        }
    }
    // Release the lock    public boolean releaseLock() {
        String luaScript = "if ('get', KEYS[1]) == ARGV[1] then return ('del', KEYS[1]) else return 0 end";
        Object result = (luaScript, (lockKey), (clientId));
        return "1".equals(());
    }
    public static void main(String[] args) throws InterruptedException {
        Jedis jedis = new Jedis("localhost", 6379);
        RedisDistributedLock lock = new RedisDistributedLock(jedis, "myLock", 5000);
        // Try to acquire the lock        if (()) {
            ("Acquiring the lock successfully!");
            // Simulate business operations            (3000);
            // Release the lock            if (()) {
                ("Releasing the lock successfully!");
            }
        } else {
            ("Capturing the lock failed!");
        }
        ();
    }
}

Code explanation：

  • acquireLock()Method is used to acquire the lock, and the validity period of the lock is passedpx(expireTime)Settings, after successful acquisition, start a timed task for renewal of locks.
  • releaseLock()Methods Use Lua scripts to ensure that only clients holding the lock can release the lock, and avoid accidentally deleting locks from other clients.
  • Passing timed tasksrenewLock()To regularly extend the validity period of the lock to ensure that the lock does not expire during business operations.

Part 6: Summary

As a high-performance memory database, Redis is widely used in the implementation of distributed locks due to its support for atomic operations and extremely high throughput. However, when using Redis to implement distributed locks, developers need to consider multiple issues, including lock acquisition and release, timeout processing, downtime fault tolerance, network partitioning, etc. Through reasonable design and optimization, the stability and security of Redis distributed locks in high concurrency environments can be ensured.

This article analyzes the common problems and solutions of Redis distributed locks in detail, and explains how to correctly implement lock acquisition, release, renewal mechanisms such as contracts and other mechanisms based on code examples. Developers can choose the appropriate solution based on actual business needs, and combine Redis's high availability architecture to ensure the stable operation of the system in a distributed environment.

By rationally using Redis distributed locks, we can ensure secure access to shared resources in complex distributed systems, thereby improving system stability and performance.

This is the article about the issues that need to be considered when implementing distributed locks in Redis. For more related content on Redis distributed locks, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!