Redis分布式锁
为什么要用Redis
分布式环境考虑加锁,可以想到如下方法
- 数据库字段
- 基于Zookeeper管理机器
- 基于缓存,可以适用Redis
基于数据库的方式个人感觉意义不大，因为大多数锁说需要保存的值非常少，为此建库建表意义不大，而且查询速度还比较慢。性能不佳。
而基于Zookeeper，可以对于每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。 判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。 问题是较为麻烦，而且效率没有使用缓存高。
如果基于缓存呢?首先性能比较好读取很快，而且像Redis都是已有部署好的集群可以直接使用。
实现
主要是使用SETNX()方法 全称就是SET IF NOT EXIST
- 返回1 说明在Redis中set了key，获得锁
- 返回0 说明该key已经被set，不能获得锁
看似很美好 直接一句话就可以实现了 但是其实存在死锁的问题
死锁问题
无论这个锁是干什么用的 都要在使用后放开锁 否则会让其他竞争者永久等待
对于这个问题一般都是考虑使用设置超时来实现的
错误的处理
先来看几个我亲自犯过的错误 一定认真看一下 可能你第一次写也是这样考虑的 如果实在等不急可以先去偷看一下正确答案。
错误A
Long result = jedis.setnx(lockKey, requestId);
if (result == 1) {
// 若在这里程序突然崩溃，则无法设置过期时间，将发生死锁
jedis.expire(lockKey, expireTime);
}
这是是第一次写的时候出现的问题 先通过一条命令尝试加锁再设置过期时间，但是这里有个坑，就是如果在尝试加锁完成以后程序崩了。GG这个锁这辈子也释放不了了，标准的死锁。
错误B
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;
}
这里看似很完美，通过对Value设置时间戳的方式防止之前的线程挂掉的情况，但是我们再看一下释放锁的方法
public static void wrongReleaseLock2(Jedis jedis, String lockKey, String requestId) {
// 判断加锁与解锁是不是同一个客户端
if (requestId.equals(jedis.get(lockKey))) {
// 若在此时，这把锁突然不是这个客户端的，则会误解锁
jedis.del(lockKey);
}
}
设想一个情况，线程A加锁并设置过期时间。突然线程A挂了这是线程B苦苦等到了过期时间成功拿到了锁。正准备爽一下的时候，突然A满血复活了，可能会“正常”的释放锁。B就不能忍了，我等你这么长时间好不容易拿到了锁，你回来直接给我释放了。
A加锁 - A死亡 - 超时 - B加锁 - A复活 - A释放锁（这时B还在执行）
说了这么多，都感觉Redis是不是不适合做分布式锁啊！那我们来看一下正确答案。
正确答案
这里我也是学习了别人的代码，需要使用Lua脚本。
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代码传到jedis.eval()方法里，并使参数KEYS[1]赋值为lockKey，ARGV[1]赋值为requestId。eval()方法是将Lua代码交给Redis服务端执行。
那么这段Lua代码的功能是什么呢？其实很简单，首先获取锁对应的value值，检查是否与requestId相等，如果相等则删除锁（解锁）。那么为什么要使用Lua语言来实现呢？因为要确保上述操作是原子性的。
因为：eval命令执行Lua代码的时候，Lua代码将被当成一个命令去执行，并且直到eval命令执行完成，Redis才会执行其他命令。保证了其原子性。
最后
其实Redis本身实现的分布式锁的确存在各种问题。有人认为它并不安全
但是对于Redis是多机部署的，那么可以尝试使用Redisson实现分布式锁，这是Redis官方提供的Java组件,这里有一篇网易技术的博客可以看一下.
