Redis（八）-- Redis分布式锁实现

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

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

二、应用的场景例子

　　管理后台的部署架构（多台tomcat服务器+redis【多台tomcat服务器访问一台redis】+mysql【多台tomcat服务器访问一台服务器上的mysql】）就满足使用分布式锁的条件。多台服务器要访问redis全局缓存的资源，如果不使用分布式锁就会出现问题。 看如下伪代码：

　　long N=0L;
　　//N从redis获取值
　　if(N<5){
　　　　N++；
　　//N写回redis
　　}

上面的代码主要实现的功能：

　　从redis获取值N，对数值N进行边界检查，自加1，然后N写回redis中。 这种应用场景很常见，像秒杀，全局递增ID、IP访问限制等。以IP访问限制来说，恶意攻击者可能发起无限次访问，并发量比较大，分布式环境下对N的边界检查就不可靠，因为从redis读的N可能已经是脏数据。传统的加锁的做法（如java的synchronized和Lock）也没用，因为这是分布式环境，这个同步问题的救火队员也束手无策。在这危急存亡之秋，分布式锁终于有用武之地了。

　　分布式锁可以基于很多种方式实现，比如zookeeper、redis...。不管哪种方式，他的基本原理是不变的：用一个状态值表示锁，对锁的占用和释放通过状态值来标识。

三、使用redis的setNX命令实现分布式锁　　

1、实现的原理

　　Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系。redis的SETNX命令可以方便的实现分布式锁。

2、基本命令解析

1）setNX（SET if Not eXists）

语法：

   SETNX key value

　　将 key 的值设为 value ，当且仅当 key 不存在。

　　若给定的 key 已经存在，则 SETNX 不做任何动作。

　　SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写

　　返回值：

　　设置成功，返回 1 。

　　设置失败，返回 0 。

 例子：

　　redis> EXISTS job                # job 不存在
　　(integer) 0

　　redis> SETNX job "programmer"    # job 设置成功
　　(integer) 1

　　redis> SETNX job "code-farmer"   # 尝试覆盖 job ，失败
　　(integer) 0

　　redis> GET job                   # 没有被覆盖
　　"programmer"

 所以我们使用执行下面的命令

　　SETNX lock.foo <current Unix time + lock timeout + 1> 

• 如返回1，则该客户端获得锁，把lock.foo的键值设置为时间值表示该键已被锁定，该客户端最后可以通过DEL lock.foo来释放该锁。

• 如返回0，表明该锁已被其他客户端取得，这时我们可以先返回或进行重试等对方完成或等待锁超时。

2）getSET

语法：

　　GETSET key value

　　将给定 key 的值设为 value ，并返回 key 的旧值(old value)。

　　当 key 存在但不是字符串类型时，返回一个错误。

返回值：

　　返回给定 key 的旧值。

　　当 key 没有旧值时，也即是， key 不存在时，返回 nil 。

3）get

语法：

GET key

 返回值：

　　当 key 不存在时，返回 nil ，否则，返回 key 的值。

　　如果 key 不是字符串类型，那么返回一个错误

四、解决死锁

　　上面的锁定逻辑有一个问题：如果一个持有锁的客户端失败或崩溃了不能释放锁，该怎么解决？

　　我们可以通过锁的键对应的时间戳来判断这种情况是否发生了，如果当前的时间已经大于lock.foo的值，说明该锁已失效，可以被重新使用。 

　　发生这种情况时，可不能简单的通过DEL来删除锁，然后再SETNX一次（讲道理，删除锁的操作应该是锁拥有这执行的，这里只需要等它超时即可），当多个客户端检测到锁超时后都会尝试去释放它，这里就可能出现一个竞态条件,让我们模拟一下这个场景： 

　　C0操作超时了，但它还持有着锁，C1和C2读取lock.foo检查时间戳，先后发现超时了。 
　　C1 发送DEL lock.foo 
　　C1 发送SETNX lock.foo 并且成功了。 
　　C2 发送DEL lock.foo 
　　C2 发送SETNX lock.foo 并且成功了。 
　　这样一来，C1，C2都拿到了锁！问题大了！ 

　　幸好这种问题是可以避免的，让我们来看看C3这个客户端是怎样做的： 

　　C3发送SETNX lock.foo 想要获得锁，由于C0还持有锁，所以Redis返回给C3一个0 
　　C3发送GET lock.foo 以检查锁是否超时了，如果没超时，则等待或重试。 
　　反之，如果已超时，C3通过下面的操作来尝试获得锁： 
　　GETSET lock.foo <current Unix time + lock timeout + 1> 
　　通过GETSET，C3拿到的时间戳如果仍然是超时的，那就说明，C3如愿以偿拿到锁了。 
　　如果在C3之前，有个叫C4的客户端比C3快一步执行了上面的操作，那么C3拿到的时间戳是个未超时的值，这时，C3没有如期获得锁，需要再次等待或重试。留意一下，尽管C3没拿到锁，但它改写了C4设置的锁的超时值，不过这一点非常微小的误差带来的影响可以忽略不计。 

　　注意：为了让分布式锁的算法更稳键些，持有锁的客户端在解锁之前应该再检查一次自己的锁是否已经超时，再去做DEL操作，因为可能客户端因为某个耗时的操作而挂起，操作完的时候锁因为超时已经被别人获得，这时就不必解锁了。  

五、代码实现

　　expireTimeMsg 锁过期时间，防止线程在入锁之后 无限等待 
　　waitTimeMsg    锁等待时间（或者 叫 尝试获得锁的时间），防止线程饥饿

1.Jedis工具类

package com.xbq.redis;

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;
/**
 * Jedis工具类
 * @author xbq
 * @created：2017-4-19
 */
public class JedisUtil {

    private JedisPool pool;
    private static String URL = "192.168.242.130";
    private static int PORT = 6379;
    private static String PASSWORD = "xbq123";
    
    // ThreadLocal，给每个线程 都弄一份 自己的资源
    private final static ThreadLocal<JedisPool> threadPool = new ThreadLocal<JedisPool>();
    private final static ThreadLocal<Jedis> threadJedis = new ThreadLocal<Jedis>();
    
    private final static int MAX_TOTAL = 100;   // 最大分配实例
    private final static int MAX_IDLE = 50;     // 最大空闲数
    private final static int MAX_WAIT_MILLIS = -1; // 最大等待数
    
    /**
     * 获取 jedis池
     * @return
     */
    public JedisPool getPool(){
        JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
        // 控制一个pool可分配多少个jedis实例，通过pool.getResource()来获取，如果赋值为-1，则表示不限制；
        // 如果pool已经分配了maxActive个jedis实例，则此时pool的状态为exhausted(耗尽)
        jedisPoolConfig.setMaxTotal(MAX_TOTAL);
        // 控制一个pool最多有多少个状态为idle(空闲的)的jedis实例
        jedisPoolConfig.setMaxIdle(MAX_IDLE);
        // 表示当borrow(引入)一个jedis实例时，最大的等待时间，如果超过等待时间，则直接抛出JedisConnectionException
        jedisPoolConfig.setMaxWaitMillis(MAX_WAIT_MILLIS);
        
        final int timeout = 60 * 1000;
        pool = new JedisPool(jedisPoolConfig, URL, PORT, timeout);
        
        return pool;
    }
    
    /**
     * 在jedis池中 获取 jedis
     * @return
     */
    public Jedis common(){
        // 从 threadPool中取出 jedis连接池
        pool = threadPool.get();
        // 为空，则重新产生 jedis连接池
        if(pool == null){
            pool = this.getPool();
            // 将jedis连接池维护到threadPool中
            threadPool.set(pool);
        }
        // 在threadJedis中获取jedis实例
        Jedis jedis = threadJedis.get();
        // 为空，则在jedis连接池中取出一个
        if(jedis == null){
            jedis = pool.getResource();
            // 验证密码
            jedis.auth(PASSWORD);
            // 将jedis实例维护到threadJedis中
            threadJedis.set(jedis);
        }
        return jedis;
    }
    
    /**
     * 释放资源
     */
    public void closeAll(){
        Jedis jedis = threadJedis.get();
        if(jedis != null){
            threadJedis.set(null);
            JedisPool pool = threadPool.get();
            if(pool != null){
                // 释放连接，归还给连接池
                pool.returnResource(jedis);
            }
        }
    }
}

2.分布式锁实现

package com.xbq.redis;

import org.apache.log4j.Logger;

import redis.clients.jedis.Jedis;

/**
 * Redis实现分布式锁
 * @author xbq
 */
public class RedisLock {
    
    private static final Logger logger = Logger.getLogger(RedisLock.class);

    // 获取jedis实例
    private Jedis jedis;
    
    // 锁 的key
    private String lockKey;
    
    // 锁过期时间，防止线程在入锁之后 无限等待
    private int expireTimeMsg = 60 * 1000;
    
    // 锁等待时间（或者 叫 尝试获得锁的时间），防止线程饥饿
    private int waitTimeMsg = 10 * 1000;
    
    // 系统时间偏移量5秒，服务器间的系统时间差不可以超过5秒，避免由于时间差造成错误的解锁
    private final static int offsetTime = 5 * 1000;  // 用毫秒表示
    
    // 默认减去的时间
    private static final int DEFAULT_ACQUIRY_RESOLUTION_MILLIS = 100;
    
    // 锁状态
    private volatile boolean lock = false;
    
    public RedisLock(Jedis jedis, String lockKey){
        this.jedis = jedis;
        this.lockKey = lockKey + "_lock";
    }
    
    public RedisLock(Jedis jedis, String lockKey, int waitTimeMsg){
        this(jedis, lockKey);
        this.waitTimeMsg = waitTimeMsg;
    }
    
    public RedisLock(Jedis jedis, String lockKey, int waitTimeMsg, int expireTimeMsg){
        this(jedis, lockKey, waitTimeMsg);
        this.expireTimeMsg = expireTimeMsg;
    }
    
    /**
     * 获取 锁 的key
     * @return
     */
    public String getLockKey(){
        return lockKey;
    }
    
    /**
     * 获取 key 对应的value
     * @param key
     * @return
     */
    private String get(String key){
        return jedis.get(key);
    }
    
    /**
     * 设置 key value，不存在 key，设置值 成功，返回1；存在key，设置值 失败，返回0
     * @param key
     * @param value
     * @return
     */
    private long setNx(String key, String value){
        return jedis.setnx(key, value);
    }
    
    /**
     * 获取旧值，设置 新的 值
     * @param key
     * @param value
     * @return
     */
    private String getSet(String key, String value){
        return jedis.getSet(key, value);
    }
    
    /**
     * 获取锁
     * 实现思路: 主要是使用了redis 的setnx命令,缓存了锁
     *     reids缓存的key是锁的key,所有的共享, value是锁的到期时间(注意:这里把过期时间放在value了,没有时间上设置其超时时间)
     * 执行过程:
     *     1.通过setnx尝试设置某个key的值,成功(当前没有这个锁)则返回,成功获得锁
     *     2.锁已经存在则获取锁的到期时间,和当前时间比较,超时的话,则设置新的值
     * @return
     * @throws InterruptedException
     */
    public boolean lock() throws InterruptedException{
        int waitTime = waitTimeMsg;
        // 循环为了多次争夺锁
        while (waitTime >= 0) {
            // 过期时间
            long exquires = System.currentTimeMillis() + expireTimeMsg + 1;
            logger.info(Thread.currentThread().getName() + "尝试获取锁！");
            // 得到了 锁
            if(this.setNx(lockKey, String.valueOf(exquires)) == 1){
                logger.info(Thread.currentThread().getName() + "获得了锁，锁 过期时间为：" + exquires);
                lock = true;
                return true;
            }
            // 存在原来的锁，就获取原来锁的过期时间
            String lastLockTime = this.get(lockKey);
            // 判断redis中的时间是否为空，获取出的 时间 过期了，则进行下面操作
            if(lastLockTime != null 
                    && System.currentTimeMillis() - Long.valueOf(lastLockTime) > (expireTimeMsg + offsetTime)){
                // 获取上一个锁的过期时间，并设置现在的锁的过期时间（只有一个线程才能获取上一个线程的设置时间，因为jedis.getSet是同步的）
                String oldValue = this.getSet(lockKey, String.valueOf(exquires));
                // 防止误删（覆盖，因为key是相同的）了他人的锁——这里达不到效果，这里值会被覆盖，但是因为相差了很少的时间，所以可以接受
                if(oldValue != null && oldValue.equals(lastLockTime)){
                    // [分布式的情况下]:如果这个时候，多个线程恰好都到了这里，但是只有一个线程的设置值和当前值相同，他才有权利获取锁
                    logger.info("------" + Thread.currentThread().getName() + "获得了锁！------");
                    lock = true;
                    return true;
                }
            }
            // 循环一次减去一次
            waitTime = waitTime - DEFAULT_ACQUIRY_RESOLUTION_MILLIS;
            // 使用随机的等待时间可以一定程度上保证公平性
            Thread.sleep((long)(Math.random() * 100));
        }
        logger.error("--------" + Thread.currentThread().getName() + "获取锁失败！！");
        return false;
    }
    
    /**
     * 释放锁
     */
    public void unLock(){
        // 判断加锁了，才进行删除操作
        if(lock){
            jedis.del(lockKey);
            System.out.println(Thread.currentThread().getName() + "解锁成功！--------------");
            // 恢复默认值
            lock = false;
        }
    }
    
}

3.模拟并发测试

package com.xbq.redis;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Semaphore;

import redis.clients.jedis.Jedis;

/**
 * 模拟并发环境下 获取锁
 * @author xbq
 */
public class Main {

    public static void main(String[] args) {

        // 定义线程池
        ExecutorService service = Executors.newCachedThreadPool();
        
        // 只能有10个线程同时访问，用来模拟并发
        final Semaphore semaphore = new Semaphore(10);
        
        // 模拟20个客户端访问 
        for (int i = 0; i < 20; i++) {
            Runnable runnable = new Runnable() {
                String lockKey = "TestLock33";
                @Override
                public void run() {
                    try {
                        // 获取许可 
                        semaphore.acquire();
                        // 获取jedis实例
                        Jedis jedis = new JedisUtil().common();

                        RedisLock redisLock = new RedisLock(jedis, lockKey, 10000);
                        if(redisLock.lock()){    // 获取到了锁，然后进行 业务处理
                            // 业务代码
                            Thread.sleep(3000);
                        }
                        // 释放锁
                        redisLock.unLock();
                        // 访问完后，释放 ，如果屏蔽下面的语句，则在控制台只能打印5条记录，之后线程一直阻塞
                        semaphore.release();
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            };
            // 执行线程
            service.execute(runnable);
        }
        // 退出线程池 
        service.shutdown();
    }
}

六、一些问题

1、为什么不直接使用expire设置超时时间，而将时间的毫秒数其作为value放在redis中？

　　如下面的方式，把超时的交给redis处理：

lock(key, expireSec){
　　isSuccess = setnx key
if (isSuccess)
　　expire key expireSec
}

　　这种方式貌似没什么问题，但是假如在setnx后，redis崩溃了，expire就没有执行，结果就是死锁了。锁永远不会超时。

 2、为什么前面的锁已经超时了，还要用getSet去设置新的时间戳的时间获取旧的值，然后和外面的判断超时时间的时间戳比较呢？

　　

　　因为是分布式的环境下，可以在前一个锁失效的时候，有两个进程进入到锁超时的判断。如：

　　　　C0超时了，还持有锁,C1/C2同时请求进入了方法里面

　　　　C1/C2获取到了C0的超时时间

　　　　C1使用getSet方法

　　　　C2也执行了getSet方法

　　假如我们不加 oldValueStr.equals(currentValueStr) 的判断，将会C1/C2都将获得锁，加了之后，能保证C1和C2只能一个能获得锁，一个只能继续等待。

　　注意：这里可能导致超时时间不是其原本的超时时间，C1的超时时间可能被C2覆盖了，但是他们相差的毫秒及其小，这里忽略了。

 七、源码下载

　　https://gitee.com/xbq168/DistributedLockByRedis

致谢：感谢您的阅读！转载请加原文链接，谢谢。转载请加上原文链接，谢谢！http://www.cnblogs.com/0201zcr/p/5942748.html