Distributed locks generally have three implementation methods:
1. Database optimistic lock;
2. Redis-based distributed lock;
3. Distributed lock based on ZooKeeper.
This article will introduce the second way to implement distributed locks based on Redis. Although there are various blogs on the Internet that introduce the implementation of Redis distributed locks, their implementations have various problems. In order to avoid misleading readers, this blog will introduce in detail how to correctly implement Redis distributed locks.
Reliability
First of all, in order to ensure that the distributed lock is available, we must at least ensure that the lock implementation meets the following four conditions at the same time:
1. Mutual exclusivity. At any time, only one client can hold the lock.
2. No deadlock will occur. Even if a client crashes while holding the lock without actively unlocking it, it is guaranteed that other clients can subsequently lock it.
3. Fault-tolerant. As long as most Redis nodes are running normally, the client can lock and unlock.
4. To untie the bell, you must also tie the bell. The locking and unlocking must be done by the same client. The client itself cannot unlock the lock added by others.
Code implementation
Component dependencies
First we need to introduce Jedis open source components through Maven. Add the following code to the pom.xml file:
redis.clients jedis 2.9.0
Lock code
Correct posture
Talk is cheap, show me the code. First show the code, and then slowly explain why it is implemented this way:
public class RedisTool { private static final String LOCK_SUCCESS = "OK"; private static final String SET_IF_NOT_EXIST = "NX"; private static final String SET_WITH_EXPIRE_TIME = "PX"; /** * 尝试获取分布式锁 * @param jedis Redis客户端 * @param lockKey 锁 * @param requestId 请求标识 * @param expireTime 超期时间 * @return 是否获取成功 */ public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) { String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime); if (LOCK_SUCCESS.equals(result)) { return true; } return false; } }
As you can see, we only need one line of code to lock: jedis.set(String key, String value, String nxxx, String expx, int time ), this set() method has a total of five formal parameters:
The first one is key. We use key as the lock because key is unique.
The second one is value. What we pass is requestId. Many children may not understand. Isn’t it enough to have a key as a lock? Why do we need to use value? The reason is that when we talked about reliability above, the distributed lock must meet the fourth condition to unlock the bell and the person holding the bell must be the person who tied the bell. By assigning the value to requestId, we will know which request added the lock. When unlocking Then you can have a basis. requestId can be generated using the UUID.randomUUID().toString() method.
The third one is nxxx. We fill in this parameter with NX, which means SET IF NOT EXIST, that is, when the key does not exist, we perform the set operation; if the key already exists, no operation is performed;
The fourth one is expx. This parameter we pass is PX, which means we want to add an expiration setting to this key. The specific time is determined by the fifth parameter.
The fifth parameter is time, which corresponds to the fourth parameter and represents the expiration time of the key.
In general, executing the above set() method will only lead to two results: 1. There is currently no lock (key does not exist), then perform the lock operation and set a validity period for the lock , and value represents the locked client. 2. The lock already exists, no operation is performed.
Careful children will find that our locking code meets the three conditions described in our reliability:
1. First, set() adds NX parameters, which can ensure If the key already exists, the function will not be called successfully, that is, only one client can hold the lock, satisfying mutual exclusion.
2. Secondly, since we set an expiration time for the lock, even if the lock holder crashes later and does not unlock it, the lock will be automatically unlocked (that is, the key will be deleted) because the expiration time is reached. Deadlock will occur.
3. Finally, because we assign value to requestId, which represents the locked client request identification, then when the client is unlocking, it can be verified whether it is the same client. Since we only consider the scenario of Redis stand-alone deployment, we will not consider fault tolerance for the time being.
Error example 1
A more common error example is to use a combination of jedis.setnx() and jedis.expire() to implement locking. The code is as follows:
public static void wrongGetLock1(Jedis jedis, String lockKey, String requestId, int expireTime) { Long result = jedis.setnx(lockKey, requestId); if (result == 1) { // 若在这里程序突然崩溃，则无法设置过期时间，将发生死锁 jedis.expire(lockKey, expireTime); } }
The setnx() method functions as SET IF NOT EXIST, and the expire() method adds an expiration time to the lock. At first glance, the result seems to be the same as the previous set() method. However, since these are two Redis commands, they are not atomic. If the program suddenly crashes after executing setnx(), the lock will not have an expiration time set. Then a deadlock will occur. The reason why some people implement this on the Internet is because lower versions of jedis do not support the multi-parameter set() method.
Error example 2
public static boolean wrongGetLock2(Jedis jedis, String lockKey, int expireTime) { long expires = System.currentTimeMillis() + expireTime; String expiresStr = String.valueOf(expires); // 如果当前锁不存在，返回加锁成功 if (jedis.setnx(lockKey, expiresStr) == 1) { return true; } // 如果锁存在，获取锁的过期时间 String currentValueStr = jedis.get(lockKey); if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) { // 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间 String oldValueStr = jedis.getSet(lockKey, expiresStr); if (oldValueStr != null && oldValueStr.equals(currentValueStr)) { // 考虑多线程并发的情况，只有一个线程的设置值和当前值相同，它才有权利加锁 return true; } } // 其他情况，一律返回加锁失败 return false; }
This kind of error example is more difficult to find the problem, and the implementation is also more complicated. Implementation idea: Use the jedis.setnx() command to implement locking, where key is the lock and value is the expiration time of the lock.
Execution process:
1. Try to lock through the setnx() method. If the current lock does not exist, return the lock successfully.
2. If the lock already exists, get the expiration time of the lock and compare it with the current time. If the lock has expired, set a new expiration time and return the lock successfully. The code is as follows:
So what is the problem with this code?
1、由于是客户端自己生成过期时间，所以需要强制要求分布式下每个客户端的时间必须同步。
2、当锁过期的时候，如果多个客户端同时执行jedis.getSet()方法，那么虽然最终只有一个客户端可以加锁，但是这个客户端的锁的过期时间可能被其他客户端覆盖。
3、锁不具备拥有者标识，即任何客户端都可以解锁。
解锁代码
正确姿势
还是先展示代码，再带大家慢慢解释为什么这样实现：
public class RedisTool { private static final Long RELEASE_SUCCESS = 1L; /** * 释放分布式锁 * @param jedis Redis客户端 * @param lockKey 锁 * @param requestId 请求标识 * @return 是否释放成功 */ public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) { String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end"; Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId)); if (RELEASE_SUCCESS.equals(result)) { return true; } return false; } }
可以看到，我们解锁只需要两行代码就搞定了！第一行代码，我们写了一个简单的Lua脚本代码，上一次见到这个编程语言还是在《黑客与画家》里，没想到这次居然用上了。第二行代码，我们将Lua代码传到jedis.eval()方法里，并使参数KEYS[1]赋值为lockKey，ARGV[1]赋值为requestId。eval()方法是将Lua代码交给Redis服务端执行。
那么这段Lua代码的功能是什么呢？其实很简单，首先获取锁对应的value值，检查是否与requestId相等，如果相等则删除锁（解锁）。那么为什么要使用Lua语言来实现呢？因为要确保上述操作是原子性的。关于非原子性会带来什么问题，可以阅读【解锁代码-错误示例2】 。
那么为什么执行eval()方法可以确保原子性，源于Redis的特性，下面是官网对eval命令的部分解释：
简单来说，就是在eval命令执行Lua代码的时候，Lua代码将被当成一个命令去执行，并且直到eval命令执行完成，Redis才会执行其他命令。
错误示例1
最常见的解锁代码就是直接使用jedis.del()方法删除锁，这种不先判断锁的拥有者而直接解锁的方式，会导致任何客户端都可以随时进行解锁，即使这把锁不是它的。
public static void wrongReleaseLock1(Jedis jedis, String lockKey) { jedis.del(lockKey); }
错误示例2
这种解锁代码乍一看也是没问题，甚至我之前也差点这样实现，与正确姿势差不多，唯一区别的是分成两条命令去执行，代码如下：
public static void wrongReleaseLock2(Jedis jedis, String lockKey, String requestId) { // 判断加锁与解锁是不是同一个客户端 if (requestId.equals(jedis.get(lockKey))) { // 若在此时，这把锁突然不是这个客户端的，则会误解锁 jedis.del(lockKey); } }
如代码注释，问题在于如果调用jedis.del()方法的时候，这把锁已经不属于当前客户端的时候会解除他人加的锁。那么是否真的有这种场景？答案是肯定的，比如客户端A加锁，一段时间之后客户端A解锁，在执行jedis.del()之前，锁突然过期了，此时客户端B尝试加锁成功，然后客户端A再执行del()方法，则将客户端B的锁给解除了。
更多redis知识请关注redis数据库教程栏目。
The above is the detailed content of Introduction to the correct implementation of Redis distributed lock. For more information, please follow other related articles on the PHP Chinese website!