使用redis实现分布式锁

可靠性

1.互斥性：在任意时刻，只有一个客户端能持有锁

2.不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁

3.具有容错性：只要大部分的redis节点正常运行，客户端就可以加锁和解锁

4.解铃还须系铃人：加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了

加锁代码

使用SET key value [EX seconds] [PX milliseconds] [NX|XX]命令，而不是setnx

参数说明：

1.key： 键名

2.value：值，这里我们使用uuid而不是固定的一个值，可能会觉得key不同不就可以了吗，为什么还要value不同，这里我们需要满足可靠性中的第四条，即谁加的锁需要谁去解。

3.EX，PX： 过期时间，单位不同，这个参数可以满足可靠性中的第二条不会发生死锁和具有容错性

4：NX： 如果 存在则不设置

总的来说，执行上面的set方法会产生两种情况：

1.当前没有锁，那么进行加锁操作，并设置过期时间，同时value表示加锁的客户端

2.当前有锁（设置了key），不做任何操作

错误示例1：好多人用低版本的redis时，没有set这个命令，所以使用的setnx+expire，但这里有个问题，这两个命令不是原子操作，如果在两条命令中间崩溃，那么就会发生死锁。

错误示例2: 还是使用setnx，但是值设置为过期时间。执行过程如下：1.通过setnx方法尝试加锁，如果当前锁不存在，则设置value为当前时间+想过多久过期的时间，返回加锁成功。2.如果锁已经存在则获取锁设置的时间（value），和当前时间对比，如果已经过期，则设置新的过期时间，返回加锁成功。如果没有时间则返回已经有锁了。

问题出在哪？ 1.是客户端自己生成的时间，所以需要要求分布式环境下每个客户端的 时间必须同步。2.当锁过期的时候，如果多个客户端执行get获取过期时间，虽然只有一个客户端可以加锁成功，但最终设置的过期时间，可能被其它客户端覆盖掉。3.锁不具备标识性，即任何客户端都可以解锁。

解锁代码

1.正确解锁姿势：使用lua脚本

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

参数KEYS[1] = key ,ARGV[1] = value.

这句话的意思就是将Lua代码发送给redis服务执行，首先获取锁对应的value值，检查是否与requestId（UUID）相等，如果相等则删除锁（解锁）。为什么要使用Lua，因为他是原子操作

使用非原子操作会带来什么问题？看下面的错误示例

1. 最常见的解锁代码是使用del直接删掉key，但是这种会导致任意客户端可以解锁，即使这把锁不是它加的

2.先判断key的value与本客户端的uuid比较，如果相等的话则del掉，因为不是原子操作，所以有可能出现，比如客户端A加锁，一段时间之后客户端A解锁，在执行del()之前，锁突然过期了，此时客户端B尝试加锁成功，然后客户端A再执行del()方法，则将客户端B的锁给解除了。