应用场景

分布式系统中，面对高并发场景，又对数据一致性有一定要求的情况下，使用分布式锁。例如商城中下单扣库存这种情况。

解决方案

基于数据库

例如：

select * from mall_spu where id=111 for update

例如：专门建一张表用来实现。例如以类名、方法名、数据ID作为唯一主键，org.leo.mall.order.OrderServer.addOrder.skuId.111，方法执行的时候，如果能插入成功，代表拿到锁，如果报主键冲突，则拿锁失败。

基于Zookeeper

以类、方法、数据ID作为目录，请求取顺序节点&节点列表，如果自己的节点最小，说明拿锁成功。而且还可以通过watch，在锁释放的时候重新拿锁。因为是临时锁，所以主动释放，或者session失效都可以释放锁，避免死锁产生。

性能差点，因为Zookeeper的操作都在主节点上。

基于redis

本文主要讲讲应用的一些变革。

1、加锁。

原来的做法是：

public static boolean getLock(String key,int expireTime){
 Long result=RedisClient.setnx(key,"");
 if(result!=1){return false}
 RedisClient.expire(key,expireTime);
 return true;
}

setnx加锁，成功后用expire加上超时时间。

问题在于：sennx和expire不是原子操作，万一expire的时候崩了，这条命令永远不过期了。

所以后来基于Redis的升级，有了下面正确的加锁方法：

public static boolean getLock(String key,String requestId,int expireTime){
 String result=RedisClient.set(key,requestId,"NX","PK",expireTime);
 if(result.equals("OK")){return true;}
 return false;
}

其实就是用Redis提供的一条set命令，替代了前面的setnx、expire两条命令，保证了原子性。

NX是指Key不存在就新增。PX是指设置超时时间。

requestId是为了后面解锁用。

2、解锁

解锁看着最简单，其实蛮复杂。

脑子里第一想法就是：

public static void releaseLock(String key){
 RedisClient.del(key);
}

这个危险性在于任何人都可以解锁！比如A请求加了锁：spu_id_111。B请求也要对111进行操作，一看锁被占了，直接del，然后自己拿锁——虽然在程序开发上讲，没有哪个傻子会这么干！！

所以这才有了第二种做法：

A请求加锁的时候，通过UUID、Random等方法生成随机数requestId。

public static void releaseLock(String key,String requestId){
  String result=RedisClient.get(key);//步骤1
  if(result.equals(requestId)){//步骤2
   //二者相等，说明加解锁的请求是同一个
   RedisClient.del(key);//步骤3
 }
}

看似很严谨，但是问题出在哪呢？还是出在操作不是原子性上。

A请求执行步骤1、2完毕，还未执行步骤2时，锁过期了，自动解锁！这时B请求加锁必然成功，而A请求继续执行步骤3，把B请求的锁给删了。

正确的做法如下：

public static boolean releaseLock(String key,String requestId){
 String luaCommand="if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
 List<String> keyList=Lists.newArrayList(key);//这里我用的是Guava
List<String> valList=Lists.newArrayList(requestId);
 Object result=RedisClient.eval(luaCommand,keyList,valList);
 if(result.equals(1L)){return true;}
 return false;
}

利用的就是Redis通过eval命令执行LUA脚本是原子性的特性。

再然后就是使用Redisson实现了，这个适用于集群部署的Redis。

我在实际使用Redis分布式锁的时候遇到过一种情况。使用分布式锁后，要调用第三方接口，从而导致整个流程时间偏长，锁过期的情况下还没有执行完，当时的处理方式是加大了过期时间。

如果使用Redisson，因为有看门狗机制，就很好地解决了这个问题。看门狗会定时去检查，如果请求实例还在则自动去延长超时时间。不过这带来的问题一定是性能的下降，所以当时我们还是采用了粗暴的延长设置过期时间来解决此类问题。

Redisson也是个可重入锁，因为锁的内容除了key、实例ID之外还有数字Value，这样一来同样的实例多次拿锁，Value+1，释放锁，Value-1即可。