分布式锁-redis实现

redis实现分布式锁

锁是针对某个资源，保证其访问的互斥性，在实际使用当中，这个资源一般是一个字符串。使用 Redis 实现锁，主要是将资源放到 Redis 当中，利用其原子性，当其他线程访问时，如果 Redis 中已经存在这个资源，就不允许之后的一些操作。spring boot使用 Redis 的操作主要是通过 RedisTemplate 来实现，一般步骤如下：
1.将锁资源放入 Redis （注意是当key不存在时才能放成功，所以使用 setIfAbsent方法）：

redisTemplate.opsForValue().setIfAbsent("key", "value");

2.设置过期时间

redisTemplate.expire("key", 30000, TimeUnit.MILLISECONDS);

3.释放锁
redisTemplate.delete(“key”);

一般情况下，这样的实现就能够满足锁的需求了，但是如果在调用 setIfAbsent 方法之后线程挂掉了，即没有给锁定的资源设置过期时间，默认是永不过期，那么这个锁就会一直存在。所以需要保证设置锁及其过期时间两个操作的原子性，spring data的 RedisTemplate 当中并没有这样的方法。但是在jedis当中是有这种原子操作的方法的，需要通过 RedisTemplate 的 execute 方法获取到jedis里操作命令的对象，代码如下：

String result = redisTemplate.execute(new RedisCallback<String>() {
	@Override
	public String doInRedis(RedisConnection connection) throws DataAccessException {
		JedisCommands commands = (JedisCommands) connection.getNativeConnection();
		return commands.set(key, value, nx, px, time);
	}
});

key 缓存键
value 缓存值
nx 该的值只能取 NX 或者 XX，
– 如果取 NX，则只有当 key 不存在时才进行 set
– 如果取 XX，则只有当 key 已经存在时才进行 set
px 该的值只能取 EX 或者 PX，代表数据过期时间的单位，EX 代表秒，PX 代表毫秒
time 过期时间，单位是 expx 所代表的单位

这样在获取锁的时候就能够保证设置 Redis 值和过期时间的原子性，避免前面提到的两次 Redis 操作期间出现意外而导致的锁不能释放的问题。但是这样还是可能会存在一个问题，考虑如下的场景顺序：

• 线程T1获取锁
• 线程T1执行业务操作，由于某些原因阻塞了较长时间
• 锁自动过期，即锁自动释放了
• 线程T2获取锁
• 线程T1业务操作完毕，释放锁（其实是释放的线程T2的锁）

按照这样的场景顺序，线程T2的业务操作实际上就没有锁提供保护机制了。所以，每个线程释放锁的时候只能释放自己的锁，即锁必须要有一个拥有者的标记，并且也需要保证释放锁的原子性操作。

因此在获取锁的时候，可以生成一个随机不唯一的串放入当前线程中，然后再放入 Redis 。释放锁的时候先判断锁对应的值是否与线程中的值相同，相同时才做删除操作。

Redis 从2.6.0开始通过内置的 Lua 解释器，可以使用 EVAL 命令对 Lua 脚本进行求值。

因此我们可以通过 Lua 脚本来达到释放锁的原子操作，定义 Lua 脚本如下：

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

使用 RedisTemplate 执行的代码如下：

// 使用Lua脚本删除Redis中匹配value的key，可以避免由于方法执行时间过长而redis锁自动过期失效的时候误删其他线程的锁
// spring自带的执行脚本方法中，集群模式直接抛出不支持执行脚本的异常，所以只能拿到原redis的connection来执行脚本
Long result = redisTemplate.execute(new RedisCallback<Long>() {
	public Long doInRedis(RedisConnection connection) throws DataAccessException {
		Object nativeConnection = connection.getNativeConnection();
		// 集群模式和单机模式虽然执行脚本的方法一样，但是没有共同的接口，所以只能分开执行
		// 集群模式
		if (nativeConnection instanceof JedisCluster) {
			return (Long) ((JedisCluster) nativeConnection).eval(UNLOCK_LUA, keys, args);
		}

		// 单机模式
		else if (nativeConnection instanceof Jedis) {
			return (Long) ((Jedis) nativeConnection).eval(UNLOCK_LUA, keys, args);
		}
		return 0L;
	}
});

但是，在集群模式的极端情况下，还是可能会存在一些问题，比如如下的场景顺序：

• 线程T1获取锁成功
• Redis 的master节点挂掉，slave自动顶上
• 线程T2获取锁，会从slave节点上去判断锁是否存在，由于Redis的master slave复制是异步的，所以此时线程T2可能成功获取到锁

完整分布式锁类：

public class RedisDistributedLock {
	
	private final Logger logger = LoggerFactory.getLogger(RedisDistributedLock.class);
	
	private RedisTemplate<Object, Object> redisTemplate;
	
	private ThreadLocal<String> lockFlag = new ThreadLocal<String>();
	
	public static final String UNLOCK_LUA;

    static {
        StringBuilder sb = new StringBuilder();
        sb.append("if redis.call(\"get\",KEYS[1]) == ARGV[1] ");
        sb.append("then ");
        sb.append("    return redis.call(\"del\",KEYS[1]) ");
        sb.append("else ");
        sb.append("    return 0 ");
        sb.append("end ");
        UNLOCK_LUA = sb.toString();
    }

	public RedisDistributedLock(RedisTemplate<Object, Object> redisTemplate) {
		super();
		this.redisTemplate = redisTemplate;
	}

	public boolean lock(String key, long expire, int retryTimes, long sleepMillis) {
		boolean result = setRedis(key, expire);
		// 如果获取锁失败，按照传入的重试次数进行重试
		while((!result) && retryTimes-- > 0){
			try {
				logger.debug("lock failed, retrying..." + retryTimes);
				Thread.sleep(sleepMillis);
			} catch (InterruptedException e) {
				return false;
			}
			result = setRedis(key, expire);
		}
		return result;
	}
	
	private boolean setRedis(String key, long expire) {
		try {
			String result = redisTemplate.execute(new RedisCallback<String>() {
				@Override
				public String doInRedis(RedisConnection connection) throws DataAccessException {
					JedisCommands commands = (JedisCommands) connection.getNativeConnection();
					String uuid = UUID.randomUUID().toString();
					lockFlag.set(uuid);
					return commands.set(key, uuid, "NX", "PX", expire);
				}
			});
			return !StringUtils.isEmpty(result);
		} catch (Exception e) {
			logger.error("set redis occured an exception", e);
		}
		return false;
	}
	
	public boolean releaseLock(String key) {
		// 释放锁的时候，有可能因为持锁之后方法执行时间大于锁的有效期，此时有可能已经被另外一个线程持有锁，所以不能直接删除
		try {
			List<String> keys = new ArrayList<String>();
			keys.add(key);
			List<String> args = new ArrayList<String>();
			args.add(lockFlag.get());

			// 使用lua脚本删除redis中匹配value的key，可以避免由于方法执行时间过长而redis锁自动过期失效的时候误删其他线程的锁
			// spring自带的执行脚本方法中，集群模式直接抛出不支持执行脚本的异常，所以只能拿到原redis的connection来执行脚本
			
			Long result = redisTemplate.execute(new RedisCallback<Long>() {
				public Long doInRedis(RedisConnection connection) throws DataAccessException {
					Object nativeConnection = connection.getNativeConnection();
					// 集群模式和单机模式虽然执行脚本的方法一样，但是没有共同的接口，所以只能分开执行
					// 集群模式
					if (nativeConnection instanceof JedisCluster) {
						return (Long) ((JedisCluster) nativeConnection).eval(UNLOCK_LUA, keys, args);
					}

					// 单机模式
					else if (nativeConnection instanceof Jedis) {
						return (Long) ((Jedis) nativeConnection).eval(UNLOCK_LUA, keys, args);
					}
					return 0L;
				}
			});
			
			return result != null && result > 0;
		} catch (Exception e) {
			logger.error("release lock occured an exception", e);
		}
		return false;
	}
	
}

单机模式分布式锁实现了，在集群模式的极端情况下，还是可能会存在一些问题，比如如下的场景顺序：

• 线程T1获取锁成功
• Redis 的master节点挂掉，slave自动顶上
• 线程T2获取锁，会从slave节点上去判断锁是否存在，由于Redis的master slave复制是异步的，所以此时线程T2可能成功获取到锁