前言
在这里粗略的说一下，zk锁性能比redis低的原因：zk中的角色分为leader，flower，每次写请求只能请求leader，leader会把写请求广播到所有flower，如果flower都成功才会提交给leader，其实这里相当于一个2PC的过程。在加锁的时候是一个写请求，当写请求很多时，zk会有很大的压力，最后导致服务器响应很慢。
正题：
什么情况下需要加锁?
当多个线程、用户同时竞争同一个资源时，需要加锁。比如，下订单减库存，抢票，选课，抢红包等。如果在此处没有锁的控制，会导致很严重的问题，下订单减库存的时候不加锁，会导致商品超卖;抢票的时候不加锁，会导致两个人抢到同一个位置;选课的时候没有锁的控制，导致选课成功的人数大于教室的座位数;抢红包时没有锁的控制，抢到红包的金额大于红包的实际金额。
什么是分布式锁?
学过JAVA多线程的朋友都知道，为了防止多个线程同时执行同一段代码，可以用synchronized关键字或JAVA API中ReentrantLock类来控制。
但是目前几乎任何一个系统都往往部署多台机器的，单机部署的应用很少，synchronized和ReentrantLock发挥不出任何作用，此时就需要一把全局的锁，来代替JAVA中的synchronized和ReentrantLock。
当Thread1线程获取到锁，执行锁中的代码，其他线程或其他机器再次请求该锁，发现锁被Thread1占用，加锁失败。当Thread1释放锁，其他线程则可以获取到锁并执行相应的操作。
我们可以用Jedis中是setnx命令来构建这把锁，首先，我列举一些错误的构建锁的方式：
错误例子1
Long lock= jedis.setnx(key,value);
if(lock>0){
//执行业务逻辑
}
通过setnx命令创建一个key、value，如果key不存在，则加锁成功。这样做有什么问题呢?如果执行加锁操作成功，在释放锁的时候，系统宕机，导致这个key永远不会被del掉，也就是说其他线程一直获取不到锁，
导致死锁发生。为了避免这种情况，请看下面的代码
错误例子2
Long lock= jedis.setnx(key,value);
if(lock>0){
jedis.expire(key,expireTime);
}
和上面的例子类似，唯一不同的是这里多了一步设置key过期时间的操作。如果在del的时候系统宕机，等过期时间一到，Redis会删除这个key。
其他线程可以再次获取锁。这样就可以万无一失了吗?这里有一个问题，如果在第一步setnx成功后，突然网络闪断，expire命令执行失败，同样也有死锁的风险。这两步并不具备原子性，不保证全部成功或全部失败。
正确的构建方式
public static boolean getDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {
String result = jedis.set(lockKey, requestId, "NX", "EX", expireTime);
if (LOCK_SUCCESS.equals(result)) {
return true;
}
return false;
}
参数解释：
key：键
value：值
nx：如果当前key存在，则set失败，否则成功
ex：设置key的过期时间
expireTime：key的过期时间，时间到了，Redis会自动删除key和value。
这个命令，将上面的错误例子2中的两个操作合为一个原子操作，保证了同时成功或同时失败。
解锁方式：
错误例子1：
jedis.del(key);
执行这个操作的线程，不去判断锁的拥有者就删除锁。
还记的set命令可以设置value吗?在获取锁的操作时，主要是判断key是否存在，那么value有什么用呢??如果在删除锁的时候，不去判断当前锁的拥有者，任何线程都可以释放锁。这个时候，value值就起到作用了。
错误例子2：
if(value==jedis.get(key)){
jedis.del(key);
}
我们在加锁的时候，可以将value设置成唯一标识当前线程的一个值，这个值可以是一个UUID，当释放锁的时间，判断value是否和set时的值相同，如果相同，则说明加锁和释放锁是同一个线程，允许释放。否则释放锁失败。
这样就可以绝对安全了吗??答案当然是否定的。这步操作，同样不具备原子性。如果ThreadA在执行value==jedis.get(key)返回true后的瞬间，del命令还没来的及执行，key过期了，而此时ThreadB获取到锁，之后ThreadA执行del命令，把ThreadB的锁释放掉了。
所以要保证两部操作的原子性，我们不得不利用简单的Lua脚本。
正确的解锁姿势：
public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {
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;
}
Redis在2.6后内部内嵌Lua脚本解释器，所以我们可以通过简单的Lua脚本来保证上述操作的原子性。代码中的Lua脚本的的意思是：我们把LockKey赋值给KEYS[1]，把RequestId赋值给ARGV[1]，如果key中的值等于RequestId，返回true否则返回false。这样就保证了释放锁操作时原子的，并且当前客户端只会释放当前客户端的锁。
