分布式锁之Redis实现（acquire）
分布式锁一般有三种实现方式：
- 基于数据库的锁；
- 基于Redis的分布式锁；
- 基于ZooKeeper的分布式锁。
本篇将介绍第二种方式，基于Redis实现分布式锁。
使用分布式锁要满足的几个条件
1.系统是一个分布式系统（关键是分布式，单机的可以使用ReentrantLock或者synchronized代码块来实现）
2.共享资源（各个系统访问同一个资源，资源的载体可能是传统关系型数据库或者NoSQL）
3.同步访问（即有很多个进程同事访问同一个共享资源。没有同步访问，谁管你资源竞争不竞争）
使用命令介绍
SETNX
SETNX key val
当且仅当key不存在时，set一个key为val的字符串，返回1；若key存在，则什么都不做，返回0。
expire
expire key timeout
为key设置一个超时时间，单位为second，超过这个时间锁会自动释放，避免死锁。
delete
delete key
删除key
实现过程
简单版本
实现思路：SETNX命令只有当key不存在时才能设值成功，返回值为1；key存在设值失败，返回0。
public class testLock {
public static void acquire(String lock){
while(jedis.setnx(lock, "") == 0){}
}
public static void release(String lock){
jedis.del(lock);
jedis.close();
}
}
在acquire方法内部，循环设置某个key的值，直到设置成功。release方法中删除这个key，代表释放锁。
存在的问题
如果有多个客户端竞争同一个分布式锁，如果三个客户端中，有任意一个线程在调用acquire成功之后异常退出，没有释放锁，另外两个客户端会死循环等待在SETNX命令上。
按照Redis文档给出的一种解决方法，重新修改acquire方法：
public static void acquire(String lock){
//1.先尝试用setnx命令获取锁,key=lock,value=当前时间+要持有锁的时间hold_time
while(jedis.setnx(lock, String.valueOf(System.currentTimeMillis() + hold_time)) == 0){
//2.如果获取失败,检查lock对应的值是否已超时
String expireTime = jedis.get(lock);
if(expireTime != null && Long.parseLong(expireTime) < System.currentTimeMillis()){
//3.如果已经超时了,删除lock，获取锁
jedis.del(lock);
jedis.setnx(lock, String.valueOf(System.currentTimeMillis() + hold_time))
break;
}
}
}
这样就解决了死锁的问题，但是还有一个严重的问题
C0操作超时了，但它还持有着锁，C1和C2读取lock.foo检查时间戳，先后发现超时了。
C1 发送DEL lock.foo
C1 发送SETNX lock.foo 并且成功了。
C2 发送DEL lock.foo
C2 发送SETNX lock.foo 并且成功了。
这样一来，C1，C2都拿到了锁！问题大了！
针对这个问题，
继续修改acquire方法:
public static void acquire(String lock){
//1.先尝试用setnx命令获取锁,key=lock,value=当前时间+要持有锁的时间hold_time
while(jedis.setnx(lock, String.valueOf(System.currentTimeMillis() + hold_time)) == 0){
//2.如果获取失败,检查lock对应的值是否已超时
String expireTime = jedis.get(lock);
if(expireTime != null && Long.parseLong(expireTime) < System.currentTimeMillis()){
//3.如果已经超时了,使用getset命令,设置新的超时时间
String oldExpire = jedis.getSet(lock, String.valueOf(System.currentTimeMillis() + hold_time));
if(oldExpire != null && Long.parseLong(expireTime) < System.currentTimeMillis()){
//4.如果setget命令返回的值,依然是过期时间,认为获取锁成功
break;
}
}
}
}
这样就解决了上述的c1,c2的问题，但这个版本依旧有两个问题没有解决:
1.有效期时间戳覆盖问题：持有锁的客户端1异常退出，其余多个客户端同时执行setnx失败，获取expireTime，发现已经小于currentTime，开始执行getset命令。假设客户端2先执行了getset，获取锁成功。客户端3在执行getset时，返回的是客户端2设置的未超时的时间戳，是一个未超时的时间，获取锁失败。看起来没有问题，但客户端2持有的锁的有效期时间戳已经被客户端3修改了。
2.超时问题：如果客户端2在持有锁的期间，由于操作还没有完成，但锁已经超时了。这时其它客户端会拿到锁，和超时的客户端一起访问redis，不满足互斥条件。
解决问题
public class SimpleRedisLock {
public static long hold_time = 3000;
public static ThreadLocal<String> expireHolder = new ThreadLocal<>();
public static void acquire(String lock){
//1.先尝试用setnx命令获取锁,key为参数lock,值为当前时间+要持有锁的时间hold_time
while(jedis.setnx(lock, String.valueOf(System.currentTimeMillis() + hold_time)) == 0){
//2.如果获取失败,先watch lock key
jedis.watch(lock);
//3.获取当前超时时间
String expireTime = jedis.get(lock);
if(expireTime != null && Long.parseLong(expireTime) < System.currentTimeMillis()){
//4.如果超时时间小于当前时间,开事务准备更新lock值
Transaction transaction = jedis.multi();
Response<String> response = transaction.getSet(lock, String.valueOf(System.currentTimeMillis() + hold_time));
//5.步骤2设置了watch,如果lock的值被其他线程修改,不是执行事务中的命令
if(transaction.exec() != null){
String oldExpire = response.get();
if(oldExpire != null && Long.parseLong(expireTime) < System.currentTimeMillis()){
//6.如果setget命令返回的值依然是过期时间,认为获取锁成功(加了watch之后,这里返回的应该一直是超时时间)
break;
}
}
}else{
//如果key未超时,解除watch
jedis.unwatch();
}
}
//设置客户端超时时间
expireHolder.set(jedis.get(lock));
}
public static void release(String lock){
//比较客户端超时时间与lock值,判断是否还由自己持有锁
if(jedis.get(lock).equals(expireHolder.get())){
jedis.del(lock);
}
jedis.close();
}
}
新的acquire方法，通过watch、redis事务，保证只有一个客户端能执行getset，并记录了锁超时时间，解决了问题一的麻烦。
对于锁超时导致的两个客户端同时访问资源，要么靠业务代码保证锁超时时间内可以完成处理；要么在release时检查是否超时，如果超时回滚所有操作，但对不能回滚的，例如++操作就比较麻烦，或者放弃死锁容错功能。
Redis分布式锁的获取锁的问题就到这里了，具体怎么使用还要看实际业务场景。
