随着分布式系统的流行，分布式锁的需求也越来越强。网上很多基于Redis实现的分布式锁，但是大大小小都有些问题。本文基于Redis给出实现及一些问题的分析。
基于Redis单节点（主从架构）的实现
获取锁
SET key_name random_value NX PX expire_time
public boolean lock(String key, long expireTime, TimeUnit timeUnit) {
String lockKey = LOCK_PREFIX + key;
return redisTemplate.execute(
(RedisCallback<Boolean>) connection ->
connection.set(lockKey.getBytes(), UUID.randomUUID().toString().replaceAll("-", "").getBytes(), Expiration.from(expireTime, timeUnit), RedisStringCommands.SetOption.SET_IF_ABSENT)
);
}
- key_name：锁的名称
- random_value：客户端生成的随机字符串
- NX：只有当不存在此key_name时才能操作成功
- PX：设置过期时间
- expire_time：过期时间值，单位：毫秒
执行业务代码
执行业务的具体处理操作。
释放锁
释放锁采用lua脚本去执行。
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
- KEYS[1]：就是前面获取锁时的key_name
- ARGV[1：前面获取锁时的random_value
Redis单节点实现分布式锁注意事项
- 锁要加上过期时间，防止成功获取锁的客户端由于各种原因导致无法与Redis进行通信，无法释放锁，导致其他客户端也无法获取到锁，产生了死锁。
- set NX 操作与 PX 操作要在同一条命令里执行，避免set NX后由于其他原因，导致无法执行PX操作，无法给锁设置过期时间。
- 必须给锁设置一个随机字符串，它保证了客户端在释放锁时，释放的一定是自己获得的那把锁。
- 释放锁的操作必须使用lua脚本实现。释放锁其实包含三步，'GET'、判断和'DEL'。使用lua脚本可以保证这三个操作的原子性，客户端自己操作这三个步骤不具有原子性。
这里解释下第三点为什么要这么做，考虑的是可能会出现以下情况：
- 客户端1获取锁成功
- 客户端1在成功获取锁后，执行业务逻辑时，在某个地方阻塞了（比如说IO操作）很长一段时间
- 锁的过期时间到了，锁自动释放了
- 客户端2获取到了同一个锁的资源
- 客户端1从阻塞中恢复过来，并且释放掉了客户端2持有的锁。
使用random_value，客户端会判断redis保存的那把锁还是不是自己持有的那把锁，如果是则释放锁，不是，则释放失败。
以上几个问题在使用时只要稍加注意，还是可以避免掉的。但是有一个问题，由于Redis单节点无法解决的。
failover（故障转移）引起的问题，以下简述一下发生的过程。
- 客户端1从master节点获取了锁
- master宕机了，并且存储的key尚未复制到slaver节点
- slaver升级为master
- 客户端2从新的master节点获得了同一个锁
由于Redis单节点存在一些问题，而且实际生产过程中，一般采用Redis集群保证高可用。Redis作者提出了Redlock的算法来实现Redis多节点下的分布式锁。
Redis集群下的分布式锁
获取锁
- 获取当前系统时间（毫秒数）
- 按顺序向Redis所有节点执行获取锁的操作，这个获取锁的操作和单节点时一致，包含随机字符串、过期时间等。为了保证不受某个不可用节点的影响，Redis还增加了一个超时时间，它远小于锁的有效时间（几十毫秒级）。客户端向某个节点获取锁失败，应立即向其他节点获取锁
- 计算整个获取锁的过程总共消耗了多少时间，计算方法是用当前时间减去第一步获取的时间，如果客户端从大多数节点（>N/2+1）都获取到了锁，并且获取锁的总消耗时间小于锁的有效时间，这时才认为获取锁成功，否则认为失败
- 如果获取锁成功了，那么这个锁的有效时间需要重新计算，它等于最初的锁的有效时间减去获取锁的过程消耗时间
- 如果锁最终获取失败了，那么客户端应该向所有节点发送释放锁的操作
执行客户端代码
释放锁
客户端向所有节点发送释放锁的操作，包括获取锁失败的节点。
