分布式锁之Redis实现(acquire)

分布式锁一般有三种实现方式:

    1. 基于数据库的锁;
    1. 基于Redis的分布式锁;
    1. 基于ZooKeeper的分布式锁。

本篇将介绍第二种方式,基于Redis实现分布式锁。

使用分布式锁要满足的几个条件

1.系统是一个分布式系统(关键是分布式,单机的可以使用ReentrantLock或者synchronized代码块来实现)
2.共享资源(各个系统访问同一个资源,资源的载体可能是传统关系型数据库或者NoSQL)
3.同步访问(即有很多个进程同事访问同一个共享资源。没有同步访问,谁管你资源竞争不竞争)

使用命令介绍

SETNX

SETNX key val
当且仅当key不存在时,set一个key为val的字符串,返回1;若key存在,则什么都不做,返回0。

expire

expire key timeout
为key设置一个超时时间,单位为second,超过这个时间锁会自动释放,避免死锁。

delete

delete key
删除key

实现过程

简单版本

实现思路:SETNX命令只有当key不存在时才能设值成功,返回值为1;key存在设值失败,返回0。

public class testLock {

    public static void acquire(String lock){
        while(jedis.setnx(lock, "") == 0){}
    }

    public static void release(String lock){
        jedis.del(lock);
        jedis.close();
    }

}

在acquire方法内部,循环设置某个key的值,直到设置成功。release方法中删除这个key,代表释放锁。

存在的问题

如果有多个客户端竞争同一个分布式锁,如果三个客户端中,有任意一个线程在调用acquire成功之后异常退出,没有释放锁,另外两个客户端会死循环等待在SETNX命令上。

按照Redis文档给出的一种解决方法,重新修改acquire方法:

public static void acquire(String lock){
   //1.先尝试用setnx命令获取锁,key=lock,value=当前时间+要持有锁的时间hold_time
   while(jedis.setnx(lock, String.valueOf(System.currentTimeMillis() + hold_time)) == 0){
       //2.如果获取失败,检查lock对应的值是否已超时
       String expireTime = jedis.get(lock);
       if(expireTime != null && Long.parseLong(expireTime) < System.currentTimeMillis()){
           //3.如果已经超时了,删除lock,获取锁
               jedis.del(lock);
               jedis.setnx(lock, String.valueOf(System.currentTimeMillis() + hold_time))
               break;
       }
   }
}

这样就解决了死锁的问题,但是还有一个严重的问题

C0操作超时了,但它还持有着锁,C1和C2读取lock.foo检查时间戳,先后发现超时了。
C1 发送DEL lock.foo
C1 发送SETNX lock.foo 并且成功了。
C2 发送DEL lock.foo
C2 发送SETNX lock.foo 并且成功了。

这样一来,C1,C2都拿到了锁!问题大了!
针对这个问题,
继续修改acquire方法:

public static void acquire(String lock){
   //1.先尝试用setnx命令获取锁,key=lock,value=当前时间+要持有锁的时间hold_time
   while(jedis.setnx(lock, String.valueOf(System.currentTimeMillis() + hold_time)) == 0){
       //2.如果获取失败,检查lock对应的值是否已超时
       String expireTime = jedis.get(lock);
       if(expireTime != null && Long.parseLong(expireTime) < System.currentTimeMillis()){
           //3.如果已经超时了,使用getset命令,设置新的超时时间
           String oldExpire = jedis.getSet(lock, String.valueOf(System.currentTimeMillis() + hold_time));
           if(oldExpire != null && Long.parseLong(expireTime) < System.currentTimeMillis()){
               //4.如果setget命令返回的值,依然是过期时间,认为获取锁成功
               break;
           }
       }
   }
}

这样就解决了上述的c1,c2的问题,但这个版本依旧有两个问题没有解决:

1.有效期时间戳覆盖问题:持有锁的客户端1异常退出,其余多个客户端同时执行setnx失败,获取expireTime,发现已经小于currentTime,开始执行getset命令。假设客户端2先执行了getset,获取锁成功。客户端3在执行getset时,返回的是客户端2设置的未超时的时间戳,是一个未超时的时间,获取锁失败。看起来没有问题,但客户端2持有的锁的有效期时间戳已经被客户端3修改了。

2.超时问题:如果客户端2在持有锁的期间,由于操作还没有完成,但锁已经超时了。这时其它客户端会拿到锁,和超时的客户端一起访问redis,不满足互斥条件。

解决问题
public class SimpleRedisLock {

    public static long hold_time = 3000;

    public static ThreadLocal<String> expireHolder = new ThreadLocal<>();

    public static void acquire(String lock){
        //1.先尝试用setnx命令获取锁,key为参数lock,值为当前时间+要持有锁的时间hold_time
        while(jedis.setnx(lock, String.valueOf(System.currentTimeMillis() + hold_time)) == 0){
            //2.如果获取失败,先watch lock key
            jedis.watch(lock);
            //3.获取当前超时时间
            String expireTime = jedis.get(lock);
            if(expireTime != null && Long.parseLong(expireTime) < System.currentTimeMillis()){
                //4.如果超时时间小于当前时间,开事务准备更新lock值
                Transaction transaction = jedis.multi();
                Response<String> response = transaction.getSet(lock, String.valueOf(System.currentTimeMillis() + hold_time));
                //5.步骤2设置了watch,如果lock的值被其他线程修改,不是执行事务中的命令
                if(transaction.exec() != null){
                    String oldExpire = response.get();
                    if(oldExpire != null && Long.parseLong(expireTime) < System.currentTimeMillis()){
                        //6.如果setget命令返回的值依然是过期时间,认为获取锁成功(加了watch之后,这里返回的应该一直是超时时间)
                        break;
                    }
                }
            }else{
                //如果key未超时,解除watch
                jedis.unwatch();
            }
        }
        //设置客户端超时时间
        expireHolder.set(jedis.get(lock));
    }

    public static void release(String lock){
        //比较客户端超时时间与lock值,判断是否还由自己持有锁
        if(jedis.get(lock).equals(expireHolder.get())){
            jedis.del(lock);
        }
        jedis.close();
    }

}

新的acquire方法,通过watch、redis事务,保证只有一个客户端能执行getset,并记录了锁超时时间,解决了问题一的麻烦。
对于锁超时导致的两个客户端同时访问资源,要么靠业务代码保证锁超时时间内可以完成处理;要么在release时检查是否超时,如果超时回滚所有操作,但对不能回滚的,例如++操作就比较麻烦,或者放弃死锁容错功能。
Redis分布式锁的获取锁的问题就到这里了,具体怎么使用还要看实际业务场景。

推荐阅读更多精彩内容

  • 关于分布式锁 很久之前有讲过并发编程中的锁并发编程的锁机制:synchronized和lock。在单进程的系统中,...
    aoho阅读 1,125评论 0 7
  • 目前实现分布式锁的方式主要有数据库、Redis和Zookeeper三种,本文主要阐述利用Redis的相关命令来实现...
    Aldeo阅读 768评论 0 5
  • 起因前段时间,看到redis作者发布的一篇文章《Is Redlock safe?》,Redlock是redis作者...
    青川刺客阅读 1,520评论 0 40
  • Java多线程开发中锁提供了原子性、可见性。但是在分布式系统中,一个进程下的多个线程分布到一个集群中的多台机器上,...
    yingzong阅读 1,123评论 1 5
  • pdf下载地址:Java面试宝典 第一章内容介绍 20 第二章JavaSE基础 21 一、Java面向对象 21 ...
    王震阳阅读 78,443评论 25 510