为什么要用分布式锁
使用场景
xx游戏平台举办了一个回馈用户活动，只要等级达到x等级，即可领取xx装备。可能有些人，有过这样的想，是不是，只要我速度够快，就能领到多份奖品啊，想想都美滋滋。结果，系统显示，当前操作过于频繁，请稍后再试。what???
这个的话，就涉及到了锁。同个账号，当我们的第一次请求到服务器的时候，已经被加上了锁，当还没释放锁的时候，再次请求，则不能拿到锁，只能继续等待。(当然这种场景不一定要用分布式锁进行实现，比如数据库的索引唯一性也可实行，只是举个例子)
说到锁的话，则要从公司系统的架构说起了。一开始，很多公司的系统不是很庞大，为了节省资源，单机即可满足需求。对于这种单机模式的系统，我们可以用java原生的synchronized和lock这两种锁，只要锁住相应的类、对象或者方法等即可简单的时间锁机制。
但随着公司的不断发展，用户量的增加，需要对业务进行拆分。这个时候，微服务就出现了，服务拆分了，同时为了保证高可用，每个服务会根据负载等因素，选择部署不同数量的机器，进行集群管理。
在分布式系统的话，则出现了同个服务，部署在不同的机器上。因为我们上面采用的是基于JVM的锁机制，没法保证同个用户请求的锁都是同个JVM（其实可以通过设置负载均衡策略，根据用户id进行hash之类，让用户落到同一台机器上，但这种很少用，毕竟这个是属于业务的问题），则需要使用分布式锁进行控制。
常见的分布式锁的解决方案
- 基于数据库的分布式锁
- 基于缓存的分布式锁，比如redis
- 基于zookeeper的分布式锁
本文的话，则主要介绍 redis分布式锁的实现 、潜在的问题 以及 解决方法
基于redis分布式锁的实现
1.加锁
最简单的方法是使用setnx命令。key是锁的唯一标识，一般根据业务来命名。比如想给某个活动的某个用户加锁，则key可以命名为lock_xx(活动id)_XX(用户id)，而value的话，这里的话，我们暂且设置为1。
jc.setnx(key, 1);
当一个线程执行setnx返回1，说明key不存在，获取锁成功；当返回结果为0，说明key已经存在，获取锁失败。
2.解锁
有加锁，就得释放锁。当得到锁的线程执行完任务之后，需要释放锁，以便其他线程能够拿到锁，执行任务。
jc.del(key);
释放锁成功之后，其他线程则能执行setnx命令，拿到锁执行任务。
3.设置锁超时
如果一个拿到锁的线程，在执行任务的过程中挂掉了，来不及显示的释放锁，则会一直占用着资源，导致其他线程无法拿到锁，没法执行任务。
所以在执行setnx命令之后，需要给锁显示设置一个锁超时时间，以保证即使拿到锁的线程挂掉了，也能在超过一定时间自动释放锁，让出资源。而setnx不支持设置超时参数，所以需要其他命令来执行。如下：
jc.expire(key, seconds);
结合起来，分布式锁的代码如下：
if (jc.setnx(key, value) == 1){
jc.expire(key,30);
try {
//业务逻辑
}finally {
jc.del(key);
}
}
存在的问题分析
（1）setnx和expire的非原子性
设想一个极端场景，当线程成功执行了setnx，成功得到了锁：
结果，执行完setnx之后，节点1宕机了，还没来得及执行expire命令：
这样一来的话，这把锁还没设置超时时间，则会一直存在，一直占用着资源，导致其他线程拿不到锁，处于死锁状态。
解决方法
setnx指令本身是不支持设置超时参数，但在Redis 2.6.12以上版本，为set设置了可选参数，代码如下：
//设置参数
SetParams setParams = new SetParams();
//设置过期时间，防止加锁之后宕机，一直处于死锁状态
setParams.ex(expireTime);
//当key不存在时，才创建key
setParams.nx();
String result = jc.set(lockKey, requestId,setParams);
(2)del误删
又是一个极端场景，假设节点1的线程A通过set拿到了锁，并设置了过期时间30秒
由于某些原因，导致线程A执行的很慢，超时时间30秒过去了，但线程A还没执行完，这个时候锁自动释放，线程B得到了锁
随后，线程A任务执行完，进行del操作释放锁，这个时候线程B还没执行完，线程A实际上删除的是线程B加的锁
解决方法
每个线程在set操作的时候，可以给value设置一个唯一的值，然后在del释放锁之前加一个判断，验证当前的锁是不是自身加的锁。
加锁
String value = UUID.randomUUID().toString();
//设置参数
SetParams setParams = new SetParams();
//设置过期时间，防止加锁之后宕机，一直处于死锁状态
setParams.ex(expireTime);
//当key不存在时，才创建key
setParams.nx();
String result = jc.set(lockKey, value,setParams);
释放锁
//判断当前的锁是否是自己加的锁
if (value.equals(jc.get(lockKey))){
jc.del(lockKey);
}
但是，这里又存在一个问题，类似上面的原子性，判断和删除操作是两个独立的操作，不是原子性。会有一个场景，就是判断的时候，获取的值是自身设置的值，但刚好在执行完判断操作之后，超时时间到期，自动释放锁，而刚好有其他线程拿到锁，这个时候在执行删除操作，则释放的是其他线程加的锁。
针对这种情况，我们可以使用Lua脚本进行实现，代码如下：
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
jc.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));
