分布式锁
之前看程序员小灰的公众号，通过漫画的形式讲解了分布式锁的内容。
后来想到公司的项目里，也利用到了分布式锁，但是分布式锁的具体代码实现和在项目中的应用并不是自己写的，具体情况还不是太懂。寻思，决定利用这个热度来看看公司的分布式锁实现，向大牛们学习学习。
说到锁，在生活中锁通常是用来锁门的，锁车的。在java中，锁是用来同步的，锁是用来保证数据的一致性的。两者虽不同，但最终都是以安全为结果来考虑的。
分布式锁和我们java基础中学习到的synchronized略有不同，在synchronized中我们的锁是个对象，如果一个线程拿到了该锁，别的线程就只能等待了。
分布式中的锁，通常不会是一个对象，而是一个唯一的数据，可以是商户的订单号，商户的编码，或者是一条数据的唯一主键等等。
synchronized主要对于单个应用中，多线程的同步；
而分布式锁对应的是多个应用，每个应用中都可能会处理相同的数据，所以需要对对个应用的数据进行同步，保证数据的一致性；
抛开具体代码实现，我认为两种锁的最大不同。
分布式锁的具体实现
1.redis
向redis中添加一个key，添加的操作是原子性操作，key不存在才能添加成功；
2.zookeeper
具体实现，还没了解过，等有了解在做详细解答；
下面我们就来看看redis怎么实现分布式锁；
redis实现分布式锁
说的简单些，redis来实现分布式锁的原理就是将程序中一个唯一的key写入redis中，当有其他分布式应用要访问时候此key时，就去redis中读取，读取到了则说明此数据正在被处理，读取不到则说明可以进行处理；
但是，想将分布式锁处理的妥当，还真不是一件轻松地事情，继续往后看。
在redis实现的分布式锁中，我们需要强调以下几点，只有保证了以下几点，才可说是确保了锁的实现：
互斥，在任何时刻，对于同一条数据，只有一台应用可以获取到分布式锁；
不能发生死锁，一台服务器挂了，程序没有执行完，但是redis中的锁却永久存在了，那么已加锁未执行完的数据，就永远得不到处理了，直到人工发现，或者监控发现；
高可用性，可以保证程序的正常加锁，正常解锁；
加锁解锁必须由同一台服务器进行，不能出现你加的锁，别人给你解锁了。
再开始具体代码之前，我们需要来创建测试环境；首先是，在你的电脑中安装redis，具体安装如下：
下载，解压，编译：
$ wget http://download.redis.io/releases/redis-4.0.10.tar.gz
$ tar xzf redis-4.0.10.tar.gz
$ cd redis-4.0.10
$ make
编译成功后，进入到redis-4.0.10目录中，再进入到src目录下：
执行./redis-server命令，redis程序启动；
新启动一个新的窗口，进入到redis-4.0.10/src目录下执行，./redis-cli命令进入redis客户端；
创建项目工程，添加java端redis依赖:
最新的2.9.0版本：
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>2.9.0</version>
</dependency>
基本的环境创建完了，接下来我们就来编写具体的代码。
前面说了，redis分布式锁实现就是像redis服务器中插入一个可做唯一条件的的key。那么，我们来看看redis中Java的api；
我们使用的是redis在Java中的jedis框架。
在Jedis老版本中，多数实现使用的是setnx()方法和expire()方法实现，而在jedis最新版本中使用的是set()方法；
例如：
public boolean setLock(Jedis jedis,String key,String val,int expireTime){
if (jedis.setnx(key, val) == 1) {
jedis.expire(key, expireTime / 1000);
return true;
}
return false;
}
上面的例子中，你觉得会发生什么样的问题？如果当程序执行完成jedis.setnx后，key和val被设置到了redis中，此时应用程序异常，过期时间还未设置，那么此key将永久保留在redis中，不会被删除。之所以这么实现，是因为当时jedis框架并不支持多参数的setnx()方法,setnx指令本身不支持传入超时时间。
public boolean setLock(Jedis jedis,String key,String val,int expireTime){
String response = jedis.set(key, val, "NX", "PX",
expireTime);
return "OK".equals(response);
}
此方法为现在通用的实现；当key不存在时，向redis中插入数据，设置过期时间，这就相当于上锁了；这里面需要注意的一点就是，val的值。我们将唯一的值当做key，那么val怎么搞？
在分布式系统环境下，val的值可以设置成该机器的唯一标识，例如时间+请求号。为什么这么说，当一个服务器向redis加锁时候，我们需要确定这个key是来自于哪台服务器，在解锁时需要校验是不是解锁的请求来自于同一个服务器；
set(final String key, final String value, final String nxxx,final String expx, final int time) 方法：
(1)key，我们使用key来当锁，key是唯一的。
(2)value，我们传的是“时间+请求号”，通过给value赋值我们在解锁的时候就会传递同样的数据进行解锁。不至于出现不同的服务器对key进行解锁。为什么说，不允许出现不同的服务器对一个key进行解锁？我们后面讲解。
(3)nxxx，NX意思为SET IF NOT EXIST，即当key不存在时，我们进行set操作；若key已经存在，则不做任何操作；
(4)expx，PX意思是给这个key加一个过期设置，具体时间由第五个参数决定。
(5)time，代表key的过期时间，单位毫秒。
说完了上锁，接下来说说解锁：
解锁，就是将key删除，你可能会觉得调用jedis删除方法就行了呗，事实并不是如此；
public void deleteLock(Jedis jedis, String key){
jedis.del(key);
}
我们前面说了，在分布式环境中，哪台服务器加的锁，在解锁时候，还让那台服务器来解锁。不能出现A服务器加锁，而B服务器解锁的情况；而上面的代码就会出现这种情况。
当A服务器将一个key设置超时时间为5秒钟，获取到锁执行业务逻辑，但是呢，5秒钟没有执行完，此时key由于到了过期时间而被删除了。正好B服务器进行了获取锁操作，发现key没有上锁，进而加锁开始执行业务逻辑。过了1秒后，A服务器执行完毕，执行释放所操作，del(key)，将B服务器上的锁给删除了。A、B服务器对同一个可以执行了一样的操作；
实现如下：
public void deleteLock(Jedis jedis, String key, String value){
if (value.equals(jedis.get(key))) {
jedis.del(lockKey);
}
}
上面实现，你觉得有问题吗？会不会出现A服务器加锁，而B服务器解锁的情况。
答案：是。
由于判断和del()操作不是原子性的，那么就会存在判断后，让其他服务器删除的情况；
例如：A服务器加锁，执行业务逻辑，很快执行完毕，进行解锁操作，解锁判断，OK，准备进行del()操作，此时CPU切换到执行别的操作了，或者JVM虚拟机进行垃圾回收操作。这时候，key到了过期时间，B服务器执行获取到锁，执行业务逻辑，还没执行完成，A服务器复活，执行del()操作，删除key；此时，A服务器上的锁，超时而被删除，B服务器加锁，A服务器将其删除；
终极大招，lua脚本实现：
String luaScript = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";
jedis.eval(luaScript,Arrays.asList(key),Arrays.asList(value));
总体代码结构为：
public void redisLock(Jedis jedis,String key,String val,int expireTime){
String luaScript = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";
try{
String response = jedis.set(key, val, "NX", "PX", expireTime);
if(!"OK".equals(response)){
return;
}
//.....执行业务逻辑
}catch (Exception e){
}finally {
jedis.eval(luaScript,Arrays.asList(key),Arrays.asList(val));
}
}
通过lua脚本，解决了 解铃还须系铃人 的问题，但是并没有解决由于A服务器执行时间过长，导致锁失效，从而使得B服务器获取到了锁，对同一个key执行了相同的逻辑。
笔者想到了两种方式。首先，需要确认的是，以上的情况发生概率很低，如果你的系统并发量不大，业务逻辑不复杂的话，基本上很难遇到这个误删除的问题，或者A、B服务器都对同一个key执行业务逻辑的问题。
第一个解决办法，我给他起名叫“懒政”，意思是重复执行就重复执行吧，不影响数据的一致性就行。但是，此解决办法有个前提条件，不影响数据的最终一致性。比如说，在加锁的业务逻辑中有一个远程调用的接口，此接口不是幂等性的，你调用几次，此接口就接受几次你的数据，那么这种情况下就不能使用该方法。还有就是说，在业务逻辑中有一个update数据库更新操作，sql为 update set amount = amount - 10 where id = 1 and amount >=0，很常见的金额更新操作，但是如果对id为1的数据连续执行2次，那金额就不对了，这个是个大问题，这种情况也不行。
第二个解决办法是，守护线程，当A服务器设置的锁要超时的时候，守护线程再对该锁进行续命，加血，延长存活时间。
守护线程例子：
public class ThreadTest implements Runnable{
@Override
public void run() {
for (;;){
System.out.println("111111111");
}
}
public static void main(String[] agrs){
ThreadTest threadTest = new ThreadTest();
Thread thread = new Thread(threadTest);
//thread.setDaemon(true);
thread.start();
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
当设置setDaemon为true时，当main方法执行结束后，新启动的线程也随之结束，这就是守护线程，守护这main方法主线程，随着main结束而结束；
具体实现如下：
public void redisLockAndDaemonThread(final Jedis jedis, String key, String val, int expireTime){
String luaScript = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";
try{
String response = jedis.set(key, val, "NX", "PX", expireTime);
if(!"OK".equals(response)){
return;
}
//开启守护线程：
final int tmpExpireTime = expireTime;
final String tmpKey = key;
Thread thread = new Thread(new Runnable(){
@Override
public void run() {
for(;;){
jedis.expire(tmpKey,tmpExpireTime);
try {
Thread.sleep(tmpExpireTime);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
});
thread.setDaemon(true);
thread.start();
//.....执行业务逻辑
}catch (Exception e){
}finally {
jedis.eval(luaScript,Arrays.asList(key),Arrays.asList(val));
}
}
与之前的一样，首先我们来对key进行加锁，设置超时间。获取到锁后，开启守护线程，再对key进行超时间设置，增加其寿命，接下来进行睡眠，如果在睡眠后还能继续执行，则说明此业务逻辑执行还未结束，再次对key进行寿命延长。
如果业务线程结束，那么守护线程也随之结束。
至此，如上便是redis实现分布式锁的逻辑。
