Redis构建分布式锁
Redis提供的
setnx命令虽然有基本加锁的功能，但是他的功能并不完整，并且也不具备分布式锁的一些高级特性，所以我们需要自己动手来实现分布式锁。
一般来说，我们在访问一个由许多线程共享的数据的时候需要先获取锁，然后执行一系列操作，最后释放锁，以方便其他线程访问。分布式锁也具有这种先获取锁然后执行操作，最后释放锁的特性，不过他是由运行在多个不同的机器上的客户端来获取和释放的，我们没有使用操作系统或者语言本身提供的锁,而是话费大把力气实现自己的锁，其中一个原因与范围有关,为了对共享的数据进行排他性访问，客户端必须要有一个锁,这个锁必须定义在所有客户端都可见的地方,这个地方就是redis本身了，另一方面Redis提供的setnx命令虽然有基本加锁的功能，但是他的功能并不完整，并且也不具备分布式锁的一些高级特性，所以我们需要自己动手来实现分布式锁。Redis也有另一个命令watch实现了乐观锁，不过并不是所有场景都适合使用watch来加锁。下文我们会一起讲解redis的各种加锁。
虽然很多使用redis实现的锁都对 锁 加锁 锁超时有所了解，但遗憾的是这可能只是基本正确，不一定完全正确，很多错误还是会在不可预料的情况下发生，下面列出锁出现不正确行为的原因,以及锁在不正确运行时的症状。
- 持有锁的线程因为操作时间过长而导致锁被自动释放，但线程本身可能并不知晓这一点，甚至还可能错误的释放了其他线程持有的锁。
- 一个持有锁，并打算执行长时间任务的线程已经崩溃,但其他想要获取锁的线程并不知道是哪个线程尺有锁，也无法检测出持有锁的线程已经崩溃,只能白白浪费时间等着锁被释放。
- 在一个线程持有的锁过期之后，其他所有等待的线程同时去争夺这把锁，并且都同时获得了锁。
- 第一种情况和第三种情况同时出现了，每个线程都认为自己是唯一获得锁的线程。
Redis的基准测试表明在最新的硬件上每秒能执行100000个操作，甚至在高端的硬件上能执行225000个操作，尽管上面提到的问题发生的几率很小，但是在互联网时代,高并发，分布式，高负载的情况下，再小的可能在数千万甚至上亿此访问面前都可能被无数倍的放大，错误会很快的发生，所以我们必须正确的实现一个锁,让锁能够正确的运行起来是一件相当重要的工作。
下面我们在一个分布式Redis主从集群上尝试建立一把可用的锁。<font color=red>特别说明，下面的代码都是为了学习原理写的，并不能在生产环境直接使用，后面我会推荐一个具有生产力级别的分布式锁的实现——Redisson</font>
第一种实现方式
public boolean tryLock(String lock) {
//默认的锁
String value = UUID.randomUUID().toString()
.replace("-", "");
return jedisCluster.setnx(lock, value) == 1;
}
public void release(String lock) {
jedisCluster.del(lock);
}
上面的tryLock方法使用setnx命令尝试加锁，传入锁的名称，值是一个uuid，返回是否加锁成功，
release方法根据所的名称释放锁，看着没什么问题，但实际上这样实现的锁存在一个问题，如果在任务执行期间
锁的值被修改的话，线程自己是不知道，或者在调用release的时候锁没被本自己持有，这就会释放其他线程持有
的锁，还有一旦线程获取到锁，但是在释放锁之前这个线程就崩溃了，那么这个锁将永远不会被释放，可怕！这是不可取的。
第二种实现方式
public boolean tryLock(String lock, long waitTime) {
//默认的锁
String value = UUID.randomUUID().toString().replace("-", "");
long endTime = System.currentTimeMillis() + (waitTime * 1000);
while (System.currentTimeMillis() < endTime) {
if (jedisCluster.setnx(lock, value) == 1) {
return true;
}
try {
Thread.sleep(1);//告诉CPU我不参加时间片分配，重新分配时间片给别人吧
//这样不会出现有哪个线程一直获得CPU时间片，一直在不断的尝试获取锁
} catch (InterruptedException e) {
e.printStackTrace();
}
}
return false;//指定时间段内没有获取到锁
}
public void release(String lock) {
jedisCluster.del(lock);
}
这种方式会在限定的时间内获取锁，如果没有获取到，则会返回一个false，除了在有限的时间内尝试获取锁并返回之外，其他没有解决任何问题，和第一种实现方式存在的问题一样。
第三种方式:带有超时特性的锁
public String tryLock(String lock, long waitTime, int lockTime) {
//默认的锁
String value = UUID.randomUUID().toString()
.replace("-", "");
long endTime = System.currentTimeMillis() + (waitTime * 1000);
while (System.currentTimeMillis() < endTime) {
if (jedisCluster.setnx(lock, value) == 1) {
//获取成功之后加一个超时时间，这样就算持有锁的客户端挂掉也无所谓
//时间到了自动会释放这个锁,但是要考虑的是设置合适的超时时间
//避免锁被释放了，可任务还在执行
jedisCluster.expire(lock, lockTime);
return value;
} else if (jedisCluster.ttl(lock) == -1) {
LOGGER.info("这个锁{}没有设置超时时间", lock);
//没有获取锁成功的线程需要检测锁有没有被设置超时时间，避免死锁
jedisCluster.expire(lock, lockTime);
}
try {
Thread.sleep(1);//告诉CPU我不参加时间片分配，重新分配时间片给别人吧
//这样不会出现有哪个线程一致获得CPU时间片，一直在不断的尝试获取锁
} catch (InterruptedException e) {
e.printStackTrace();
}
}
return null;//指定时间段内没有获取到锁
}
public void releaseWithCheck(String lock, String identifier) {
if (identifier.equals(jedisCluster.get(lock))) {
jedisCluster.del(lock);
} else {
throw new RuntimeException("释放不属于自己持有的锁" + lock + ":" + identifier);
}
}
tryLock方法会指定一个lockTime表示获取锁之后可以使用的时间，一个waitTime表示在这个时间段内尝试获取锁，获取成功之后返回锁的值，否则返回null，我用会用一个while循环在waitTime时间内不断尝试获取锁，在获取成功之后给锁设置一个过期时间，如果获取锁失败，他会检查(ttl)这个锁有没有设置超时时间,如果没有他会设置上超时时间，这样可以保证锁一定会被设置超时时间，即使客户端挂掉，也不会影响锁的释放，服务还是继续可用，,通常线程间切换的时间都非常短，所以lockTime的设置不会出现太大的不准确。Thread.sleep(1)是一个小小的技巧，告诉CPU我不参加时间片分配，重新分配时间片给别人吧，这样不会出现有哪个优先级高的线程经常获得CPU时间片，一直在不断的尝试获取锁，也就能比较公平的竞争锁。
而release方法则传入锁的名称和值，检查锁是否是线程获取锁成功时候的锁，中途是否被修改过，并且还能防止线程释放其他线程的锁。
总结
上面我们使用的是一个分布式的redis集群，客户端是jedis,但是jedis是不支持集群的redis的事务的，这点我们可以考虑使用lua脚本来实现，在释放锁的时候使用功能，这里不多说，强调一句话，第三种方式虽然实现了基本可用，但还不是最优的实现，<font color=red>如果想要一个更好的实现参考Redisson</font>。
