Redis实现分布式锁

一、Redis单节点实现

(一) 获取锁

使用 Redis 客户端获取锁，向Redis发出下面的命令：

set key random_value NX PX 1000

上面的 SET 命令中：

• random_value 是客户端随机产生的字符串，需要保证唯一性，用于防止误删锁的情况

• NX 表示 key 不存在的时候，SET 操作才成功，这样保证了只有一个客户端活动锁

• PX 1000 表示这个锁在 1000毫秒以后过期

(二) 锁释放

当获取锁的客户端完成了操作，需要执行下面的命令释放锁：

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

释放锁时，要先比较 key 的 value 与 客户端的 random_value 是否相等，如果相等，就是释放锁，否则失败，这里的比较操作和删除操作需要保证原子性，所以使用 lua 脚本实现

这里记录一下在执行 lua 脚本时遇到的坑

#错误
eval "if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end" 1 name heyong

#正确
eval 'if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end' 1 name heyong

上面两行脚本唯一的不同点在于 ‘ 和 “, 在 redis-cli 执行脚本的时候一定要注意

将执行的 lua 脚本写到文件中

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

执行 lua 脚本文件

#错误,逗号两边少了空格
redis-cli --eval del.lua name,heyong

#正确
redis-cli --eval del.lua name , heyong

调用lua 脚本的语法如下：

调用Lua脚本的语法：
$ redis-cli --eval path/to/redis.lua KEYS[1] KEYS[2] , ARGV[1] ARGV[2] 

KEYS[1],KEYS[2] : 代表要操作的键
ARGV[1] ARGV[2] : 参数，在lua脚本中通过 ARGV[1] ARGV[2] 获得

注意 : KEYS和ARGV中间的 ',' 两边的空格，不能省略

二、单机Redis分布式锁相关问题

(一) 为什么需要设置过期时间

Redis实现分布式锁必须要设置过期时间，否则某个客户端获取锁以后，客户端宕机获取由于网络问题无法与Redis节点通信，那么该客户端就一直持有锁，其他客户端就无法获得锁。锁的过期时间要根据自己的业务场景来，但是也不要设置的过长或者过短。

(二) 为什么锁的获取需要保证原子性

如果获取锁的操作是使用下面的命令会有说明问题

SETNX key random_value
EXPIRE key 10

在理想情况下，通过上面的命令也能够获得锁，但是由于缺少原子操作，在执行完第一条命令以后，客户端重启或者崩溃，那么锁就一直没有办法释放

(三) random_value的必要性

设置 random_value 保证了一个客户端释放的锁必须是自己持有的锁，如果不能保证random_value值的唯一性，就可能出现下面的情况：

1. 客户端A获得锁
2. 客户端在某个操作上阻塞
3. key 过期，锁自动释放
4. 客户端B获得锁
5. 客户端A完成业务操作，释放掉客户端B持有的锁

由于客户端B的锁被释放，那么就会有其他客户端来获取锁，多个客户端同时操作共享资源，导致脏数据

(四) 为什么锁释放需要保证原子性

在释放锁的时候， random_value是否等于key的value 和 key的删除操作需要保证原子性，如果没有保证原子性，就可能出现下面的情况：

1. 客户端A获得锁
2. 客户端A执行业务操作
3. 客户端执行GET命令获取key的value，并与random_value相等
4. 客户端A发出del命令，但是由于网络问题，导致请求时间过长
5. key过期，锁自动释放
6. 客户端B获得锁
7. 客户端A的请求到达Redis服务器，执行del操作，客户端B的锁被释放

客户端B的锁被释放，就不能保护共享资源

(五) Redis主从对锁的影响

在生产环境中，Redis部署至少会实现主从架构，并通过各种容灾机制，在主节点宕机的时候将从节点升级为主节点，在这种架构下，分布式锁也可能出现问题

1. 客户端A从Master节点获取到锁
2. Master节点宕机，并且key没有及时同步到slave节点
3. Slave节点升级为主节点
4. 客户端B获得锁

这样也出现了共享资源被多个客户端操作的情况

三、分布式锁Redlock

上面提出提出了单机Redis分布式存在锁安全的问题，于是Redis的作者Antirez提出的Redlock方案。
有关Redlock可以参考：
1、https://github.com/antirez/redis-doc/blob/master/topics/distlock.md
2、http://ifeve.com/redis-lock/

四、使用单机Redis分布式锁还是Redlock

通过上面的分析，如果Redis主节点宕机，可能会丧失锁的安全性，但是是否项目使用单机Redis分布式锁需要结合自己的业务场景考虑，下面举一些场景作为参考

1. 在网上商城中，商品的信息很少发生变化，所以会将商品数据缓存到Redis中，可能会出现并发请求一个热点商品数据的情况，如果当前热点商品缓存过期，那么大量的请求就会打到 DB上，为了解决这种情况通常使用分布式锁，让获取到锁的线程去数据库获取商品数据，在这里使用单机Redis实现分布式锁，如果主节点宕机也不会影响数据的正确性，只是在短时间类可能出现多个请求打到DB，获取相同的商品数据。

2. 如果涉及到对某个共享资源的修改操作，需要保证数据的安全性，建议使用Redlock

五、扩展

(一) SET 命令参数

在redis2.6以后，提供了相关的参数来设置 SET 命令的行为

• EX second : 设置键的过期时间，过期时间以秒为单位
• PX millisecond : 设置键的过期时间，过期时间以毫秒为单位
• NX : 键不存在时才操作成功
• XX : 键存在时才操作成功

(二) 其他分布式实现方案

1. 基于数据库实现：在数据库创建一张表，加锁的机制就是在数据库里面通过插入和删除记录实现，当需要加锁的时候，创建一条数据库记录，释放锁的时候删除记录

2. 基于Zookeeper实现：ZK提供了临时节点，如果客户端与ZK断开连接，那么客户端就会自动删除改临时节点。同时ZK提供了 watcher 机制，如果节点发生了变更，会通知监听改节点的客户端。

根据zookeeper的这些特性，我们来看看如何利用这些特性来实现分布式锁：

• 创建一个锁目录lock

• 线程A获取锁会在lock目录下，创建临时顺序节点

• 获取锁目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁

• 线程B创建临时节点并获取所有兄弟节点，判断自己不是最小节点，设置监听(watcher)比自己次小的节点（只关注比自己次小的节点是为了防止发生“羊群效应”）

• 线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是最小的节点，获得锁

上面的分布式锁是基于ZK的临时节点和watch机制实现的，该方案也存在问题，如果出现网络抖动问题，导致client和ZK集群断开连接，那么临时节点就会被自动删除，那么其他客户端也可以获取锁。

可以使用 Apache 开源的curator 开实现 Zookeeper 分布式锁。