Redisson分布式锁实战-2：解决wait_time之坑

我们一起来分析一下原因,我们获取锁之后,我们只打印了一个日志,然后从配置文件里面拿到一个hour,然后就结束了,

结束之后就来到finally里边,而这个时间并没有执行SQL语句,所以他的时间会非常非常短,是小于一秒的,而另外一个TOMCAT

在执行的时候呢,在等待一秒之后,发现我又能获取锁了,所以在同一次Schedule执行的时候,我们就会发生两个进程,都拿到

分布式锁,所以这一次我们把waittime改成0,

    /**
     * Redisson分布式锁实现
     * @throws InterruptedException
     */
//    @Scheduled(cron="0 */1 * * * ?")//每1分钟(每个1分钟的整数倍)
    public void closeOrderTaskV4() throws InterruptedException {
        RLock lock = redissonManager.getRedisson().getLock(Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
        boolean getLock = false;
        try {
            if(getLock = lock.tryLock(0,50, TimeUnit.SECONDS)){//trylock增加锁
                log.info("===获取{},ThreadName:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK,
				Thread.currentThread().getName());
                int hour = Integer.parseInt(PropertiesUtil
				.getProperty("close.order.task.time.hour","2"));
                iOrderService.closeOrder(hour);
            }else{
                log.info("===没有获得分布式锁:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
            }
        }finally {
            if(!getLock){
                return;
            }
            log.info("===释放分布式锁:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
            lock.unlock();
       
为1的时候两个TOMCAT都会获取到锁的一个问题,那我们就可以使waittime变成0,解决了这个问题,不再去等待,所以这也是我们实际工作

中发现的一个问题,一个小坑,如果大家对这里的预估时间不是太准确的话,建议把waittime这个时间设置为0,以及如何分析waittime的

一个原理,在使用Redisson的时候,我们最好使用waittime是0,否则会产生两边同时拿到分布式锁的一个问题,也就是我们分布式事务

执行的非常非常快,小于1秒的时候,就会有这么一个坑,我现在在实际工作中使用Redisson分布式锁的时候,也会把waittime统一设置成0,

finally里如果没有获取到所就直接return了,并不会执行unlock和打印日志,所以在TOMCAT2里只会看到没有获取到分布式锁,和我们

预期是一致的,waittime请大家务必设置成0,这样比较统一,也不会出现问题,我们也不需要来评估这个定时任务,所执行业务逻辑的

时候,他所耗费的一个时间,我们只需要让每一次的waittime,为0即可,让每一个TOMCAT竞争锁并不等待,对分布式锁原生实现,

和Redisson来实现分布式锁,都有一个比较深入的理解了