分布式锁前言在分布式应用开发中，如秒杀、商品抢购等业务，为防止库存超卖，都需要使用分布式锁。其本质就是不同进程共同访问

前言

在分布式应用开发中，如秒杀、商品抢购等业务，为防止库存超卖，都需要使用分布式锁。其本质就是不同进程共同访问共享资源的一种实现。
其实现有三种方式：

对于这种其本质是在数据库中新建一个表，用于存储分布式锁，而加锁则是根据特定标记判断表中有没有记录，如果没有或者记录中锁标记（锁状态、是否超时）为未锁状态那么获取锁，如果状态为已锁状态，那么获取锁失败。

这种方式基于版本号以及一个原值比对，每次修改操作版本号加一然后去更新值，将版本号查出，带上相关条件去更新，如果版本号未变那么更新，否则继续重试

在单节点中的redis实现分布式使用的是set ex px nx+校验唯一随机值

//伪代码如下
if(redis.set(key,uniqueId,"NX","EX",100s)==1){
  //业务代码
}
finally{
  if(uniqueId.equals(redis.get(key))){
    redis.del(key);
  }
}

此处的校验唯一随机值是为了防止由于锁过期释放但是业务还没有执行完，而其他业务获取锁执行期间，上一业务误将锁释放

对于在使用redis设置锁时存在的锁过期释放、业务还没有执行完问题，我们除了可以设置更长的过期时间以外，我们还可以在获取锁的线程中开启一个守护线程，每隔一段时间检测线程是否持有锁

RedLock算法实现步骤

客户端A请求加锁，ZK会创建一个持久节点/locks，如果A想获取锁，需要在locks创建一个顺序节点lock1
A查找locks先所有临时顺序子节点，判断自己的节点lock1是不是排序最小的，如果是，获取锁
客户端B此时尝试获取锁，在locks下创建临时节点lock2,B查找临时顺序子节点，看自己是不是最小的，此时发现lock1才是最小的，获取锁失败，接着在lock1上注册watcher事件，用来监听lock1是否存在
客户端C尝试获取锁，创建临时节点lock3，查找locks下所有临时顺序子节点，判断自己是不是最小的，发现前面有临时子节点lock2，在lock2上注册watcher事件