Redis分布式锁原理和实现

Redis分布式锁原理和实现

一、为什么需要分布式锁
说到锁，大家也不陌生，不管什么代码 加了锁也就意味着 同步 意味着性能会下降，但是有的业务场景不加还不行 当多个线程一个公共资源的时候比如我们熟悉的库存加减等，那么我们怎么解决呢？

在传统单体应用单机部署的情况下，解决的办法很多比如用ReentrantLock或Synchronized关键字等，但是，随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

二、redis分布式锁
分布式锁的实现大致有三种方式，数据库、redis、zookeeper，本文只来分析下redis的实现方式。
一般用redis的话会用Redisson框架，非常的简便易用，下面先来看下demo

  //这段代码放在启动类用于初始化Redisson
    @Bean
    public Redisson redission() {
        Config config = new Config();
        //本文只是演示真实环境初始化RedissonClient 需要从配置文件获取需要的参数
        config.useSingleServer().setAddress("redis://127.0.0.1:6379");
        config.useSingleServer().setPassword("123456");
        return (Redisson) Redisson.create(config);
    }

 @Service
 public class testService {
        @Autowired
        private Redisson redission;

        //操作库存业务
        public String stock() {
            //获取锁的实例
            RLock lock = redission.getLock("lock1");

            try {
                //如果加锁成功返回true 反之返回flase
                boolean flag = lock.tryLock();
                if (flag) {
                    //操作库存业务
                } else {
                    return "业务繁忙请稍后重试"
                }
            catch(Exception e){
                    //这里打印错误日志

                } finally{
                    //解锁
                    lock.unlock();
                }


            }
        }

总结下上面的代码，其实就三步操作首先获取锁的实例，也就是
RLock lock = client.getLock(“lock1”);
加锁就一行代码
lock.tryLock() 如果返回true说明获取到锁返回flase没有获取到锁
释放锁在finally 执行
lock.unlock();
三、手写一个redis锁
查看Redisson源码，跟踪lock.trylock()你会发现底层是一段lua脚本

   "if (redis.call('exists', KEYS[1]) == 0) 
 then redis.

 call('hset',KEYS[1], ARGV[2], 1); 
     redis.call('pexpire',KEYS[1],ARGV[1]);
      return nil;end;
     if(redis.call('hexists',KEYS[1],ARGV[2])==1)
 then redis.

 call('hincrby',KEYS[1], ARGV[2], 1);
        redis.call('pexpire',KEYS[1],ARGV[1]); 
       return nil;end; return redis.call('pttl',KEYS[1]);",

为啥要用lua脚本呢,因为他可以保证原子性
KEYS[1]代表的是你加锁的那个key
就是上面例子中 RLock lock = client.getLock(“lock1”); 的lock1
ARGV[1]代表的就是锁key的默认生存时间，默认30秒
这个参数我们可以修改，例如这样
try.lock(Long long,TimeUnit timeUnit)
ARGV[2]代表的是加锁的客户端的ID，具有唯一性
第一段if判断语句"if (redis.call(‘exists’, KEYS[1]) == 0)
就是判断锁是否存在 如果不存在就加锁那么是怎么加锁的呢
hset
通过这个命令设置一个hash数据结构 这个时候你的redis会有这样一条hash数据

lock1:{
"客户端id"：1
} 

接着会执行“pexpire myLock 30000”命令设置k的过期时间
这就是加锁的整体步骤说白了就是往redis设置一条带有有效时间的数据，如果k存在就返回失败，如果不存在则插入，返回成功，
如果我们不用框架的话想实现redis分布式锁
可以用命令
SET key value [EX seconds] [PX milliseconds] [NX|XX]
当我们执行完业务逻辑就把这个k删除就可以了 。
只不过不用框架的话需要考虑很多，比如怎么防止删掉别人的k，又或者在有效期时间内业务代码没有执行完或者服务器宕机了等。
下边开始造轮子手写个redis分布式锁

@Service
public class testService {
   @Autowired
   private StringRedisTemplate redisTemplate;

   //操作库存业务
   public String stock() {


       try {
           //生成唯一id作为value
           String vlueId = UUID.randomUUID().toString();

           boolean flag = redisTemplate.opsForValue().setIfAbsent("lock1", vlueId, 30, TimeUnit.SECONDS)
           if (flag) {
               //操作库存业务
           } else {
               return "业务繁忙请稍后重试"
           }
           catch(Exception e){
               //这里打印错误日志   

           } finally{
               //解锁  
               //先判断锁是否是自己的,这里是为了防止在过期时间内代码没有走完锁，误删别的线程的锁的。
               String value = redisTemplate.opsForValue().get("lock1");
               if（vlueId.equals(valueId)){
                   redisTemplate.delete("lock1")
               }

           }


       }
   }

可以看到上面那个过期时间 如果不设置的话服务器发生宕机就会造成死锁的问题，设置的短了导致在有效时间内业务代码没有执
行完引发当前线程锁失效,如果设置太长用户体验不够好那么我们如何解决呢？
很简单给锁续命，这里就不写代码了 就是开个定时器每隔一段时间判断下这个k值是否存在如果存在就重新设置下过期时间，这里说下间隔时间要小于过期时间，这样万一服务器宕机了最多锁的时间为设置的过期时间，也不用担心有效时间内业务代码执行不完 因为会锁的过期时间会定时续命。
到此一个手写的redis分布式锁就完成了
欢迎大家一起讨论，如有理解不到位的地方，请多多指教