一篇文章彻底说透分布式锁

【应用场景】 秒杀场景，多个用户同时点击秒杀，相当于多个线程争夺库存 

【实现】 

1.使用setNX命令,KEY设置成功返回1；设置失败返回0；只有返回1的那个线程才能获取锁； 程序执行完，释放锁

2.若服务进程被kill或服务器宕机，那么try catch块也解决不了问题 

   【解决】：为KEY设置生效时间；防止程序异常导致KEY没有释放锁， 其他线程一直获取不到锁，这里要用Jedis新提供的SetNX设置生效日期的原子操作，不要分开 

3.若分成两段代码写（伪代码）

Boolean result =redisTemplate.setIfAbsent(lockKey,"liwei");
redisTemplate.expire(lockKey,10,TimeUnit.SECONDS);

问题又来啦，若程序执行完第一段代码正好就挂掉了(就这么巧)，设置生效时间失败

【解决】：jedis提供了一套原子方法 redisTemplate.setIfAbsent(lockKey,"liwei",10,TimeUnit.SECONDS);

4.现在就没问题了么？ NO,高并发场景下，需要考虑的细节特别多，时时刻刻都是陷阱，要多思考 言归正传，有这么一种场景，线程A执 行了10s还没有执行完，就在此时，KEY失效了 线程B顺利争夺到了这把锁(好开森！)，但是线程A还要继续执行，执行到释放锁 的逻辑，咔嚓，把锁给删掉了，但是他删掉的不是自己那把锁，而是线程B加的锁； 这一删掉，妥了，线程C又拿到锁开心的进来了..汗.一看屋里还有这么多人.不是说好 今晚只有我么,周而复始,所有的线程都进来了,由于线程执行的不可预知性,有可能造成 库存的重复扣减,即"超卖"

【解决】:放心,能解决,方法总比困难多,我们为每个线程都做一个标记,只有当前线程 上的锁,才能被当前线程释放;这样不就解决啦,上代码

public void test(){ 
    String lockKey = "liwei"; 
    String clientId = UUID.randomUUID().toString(); 
    try{ redisTemplate.setIfAbsent(lockKey,clientId,10,TimeUnit.SECONDS); 
    /******START业务逻辑*******/ 
    /******END业务逻辑********/ 
    }finally { 
        if(clientId.equals(redisTemplate.get(lockKey))){     
            redisTemplate.delete(lockKey); } 
        } 
}

5.解决了上面这些问题,还是没解决由于网络原因或者程序本身原因执行时间 超出生效时间的问题(因为业务本身执行时间无法预估,只能大概估一个时间设置为超时时间)

【解决】为分布式的KEY进行续期; 目前Redisson针对于分布式微服务架构，提供了一套API来解决这个问题

【原理】：Redisson不但解决了上述分布式锁使用时出现的4点问题,还提供一个时长为30s的续期功能， Redisson会新创建一个线程,做一个定时任务,内容是每10s(这个时间一般为设置的失效时间的1/3)检查一次当前这个 持有锁的线程有没有释放分布式锁,如果没有释放,重新设置锁的失效时间为30s

public void test(){ 
    String lockKey = "liwei"; 
    RLock lock = redisson.getLock(lockKey); 
    try{ 
        //默认失效时间30s lock.tryLock(); 
        /******START业务逻辑*******/ 
        /******END业务逻辑********/ 
    }finally { 
        lock.unlock(); 
    } 
}

Redisson框架原理脑图

总结：在高并发场景下，要使你写的代码做到高可用，需要在写代码时，要学会思考，多总结，否则"坑"会非常多

"学而不思则罔，思而不学则殆"；学会举一反三，不要盲从，跟着官方文档或者视频实操一遍，得出的结果才是真理，

印象也会更加深刻；Java技术都是相通的，专注的掌握学习一个框架的原理，一通百通. 第一篇文章...还是很兴奋的，不足之处请多指教