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分布式锁的获取锁的问题就到这里了，具体怎么使用还要看实际业务场景。