缘起

有一个公共厕所只有一个坑位，为了控制正在使用的人不被使用，旁边设置了个门房，并给厕所上了密码锁，只有拿到单次使用密码的人才可以使用。

1. 只有一个坑位，所以同一时刻只能有一个人使用
2. 使用前需要跟门房要一个临时单次密码
3. 使用完后需要给门房说一声才可以生成新密码
4. 但有些人用完就走了，所以门房就规定5min使用过期时间，如果超过时间就可以生成新密码，其他人也就可使用了
5. 这就可能有问题，如果一个人确实使用时间超过5min，那么新进去的人会干扰他的使用。但如果5min内，一个人出去了又拉肚子需要重复使用，那么这是否算第二次使用
6. 如果是这个人没有带卫生纸，是否按照二次使用获取新密码呢？
7. 如果厕所正在使用，后面来的人是等待还是直接找其他厕所呢需要根据实际情况设定
8. 如果等待，是否需要设置一个最长等待时间呢
9. 如果等待，等待的人是否需要排队，下一个的时候是抢占呢，还是按照来的迟早获取
10. 获取新密码的时间要尽可能短，尽可能减少非使用厕所的损耗
11. 尽可能一直有人值守门房，否则拿不到密码也没法使用厕所

如果多人(多台机器，多个线程等)操作一个单元，那么结果就可能不是谁都愿意看到的。这是同步问题，放在分布式中也一样，解决方案就是：有一个尽可能小的单线程中间变量作为是否可以该变量的标记。

谁拿到这把钥匙，谁就可以开启箱子。

分布式锁要求

1. 互斥：进程外同一刻时间，只能有一个客户端访问 （必选）
2. 死锁：访问可能中断，锁需要有一定过期时间（必选）
3. 在过期时间和使用时间做好平衡,时间太长*并发=常数
4. 锁尽可能高可用，高性能
5. 阻塞和非阻塞特性：对后续来的客户是直接打发回去呢，还是等待一定时间，还没有获取到就打发回去
6. 等待的客户是否需要排队，还是看运气抢占
7. 如果同一个多次要密码，是否给生成，还是等待(可重入问题)
8. 解铃还须系铃人：防止别人等不住说我用不了，自己去使用；当然门房设置的超时机制除外

实现方案1：数据库

原理或步骤：

1. 开启事务
2. 使用数据库select lock from table1 where id = 0 for update; 给改行添加排它锁，事务没有提交之前，其他事务不能更新
3. 判断lock==0，0没有锁，1已锁
4. 更新数据lock=1
5. 提交事务

1. 业务操作

1. 开启事务
2. 使用数据库select lock from table1 where id = 0 for update; 给改行添加排它锁，事务没有提交之前，其他事务不能更新
3. 判断lock==1，0没有锁，1已锁
4. 更新数据lock=0
5. 提交事务

问题：

1. 锁的使用者没法得到
2. 没有超时清理机制，可能导致死锁

延迟消息+添加使用者字段：

1. 更新lock=0的时候，先添加延迟清理消息，并添加使用者
2. 延迟消息，如果user没有匹配，就丢弃
3. 如果业务操作超时，延迟消息执行解锁，新客户锁后，超时的业务操作客户解锁时需要判断user：update table1 set lock=0 where id = 0 and user = 当前线程ID；

特点：

仅限于有事务数据库引擎，如果Mysql的Innodb。

方案2：缓存Memcached

利用 Memcached 的 add 命令。此命令是原子性操作，只有在 key 不存在的情况下，才能 add成功，也就意味着线程得到了锁。

类似Mysql，超时机制需要自己设置

方案3：Redis

setnx命令：如果有key有数据，就不设置，返回0；没有数据就赋值，返回1。单线程

超时机制：expire命令，设置超时命令

问题：

1. 没法先设置超时expire，然后在setnx。（先发送延迟消息，然后更新数据库）
2. 先设置setnx，如果没有设置expire就会死锁

解决：

合并命令 jedis版本：2.9.0

jedis.set(lockKey, value（requestId）, “NX”, “PX”, expireTime)

value:设置当前请求的requestID，用作解锁的依据

expireTime 过期时间

缺点：可重入 实现困难

1. set并设置时间返回0
2. 过期，清理
3. get并判断value是否为当前requestID
4. 获取到数据为空，返回false
5. 获取到数据为其他客户端加锁，返回false
6. 如果是返回true，已获取锁；否则返回false
7. 场景：可重复场景类似两层AOP都加锁，根据此次线程IP所谓requestId判断，第二次获取锁就可以直接拿到，否则获取同一个锁可能死锁。

解锁：也需要合并命令

解决：使用lua脚本，合并命令

完整代码&逻辑：

逻辑：
下面我们假设锁的key为“ lock ”，hashKey是当前线程的id：“ threadId ”，锁自动释放时间假设为20
获取锁的步骤：
    1、判断lock是否存在 EXISTS lock 
        2、不存在，则自己获取锁，记录重入层数为1.
        2、存在，说明有人获取锁了，下面判断是不是自己的锁,即判断当前线程id作为hashKey是否存在：HEXISTS lock threadId 
            3、不存在，说明锁已经有了，且不是自己获取的，锁获取失败.
            3、存在，说明是自己获取的锁，重入次数+1： HINCRBY lock threadId 1 ，最后更新锁自动释放时间， EXPIRE lock 20
        
释放锁的步骤：
    1、判断当前线程id作为hashKey是否存在： HEXISTS lock threadId 
        2、不存在，说明锁已经失效，不用管了 
        2、存在，说明锁还在，重入次数减1： HINCRBY lock threadId -1 ，
        　　3、获取新的重入次数，判断重入次数是否为0，为0说明锁全部释放，删除key： DEL lock
获取锁的脚本(注释删掉,不然运行报错)
local key = KEYS[1]; -- 第1个参数,锁的key
local threadId = ARGV[1]; -- 第2个参数,线程唯一标识
local releaseTime = ARGV[2]; -- 第3个参数,锁的自动释放时间
 
if(redis.call('exists', key) == 0) then -- 判断锁是否已存在
    redis.call('hset', key, threadId, '1'); -- 不存在, 则获取锁
    redis.call('expire', key, releaseTime); -- 设置有效期
    return 1; -- 返回结果
end;
 
if(redis.call('hexists', key, threadId) == 1) then -- 锁已经存在，判断threadId是否是自己    
    redis.call('hincrby', key, threadId, '1'); -- 如果是自己，则重入次数+1
    redis.call('expire', key, releaseTime); -- 设置有效期
    return 1; -- 返回结果
end;
return 0; -- 代码走到这里,说明获取锁的不是自己，获取锁失败
释放锁的脚本(注释删掉,不然运行报错)
local key = KEYS[1]; -- 第1个参数,锁的key
local threadId = ARGV[1]; -- 第2个参数,线程唯一标识
 
if (redis.call('HEXISTS', key, threadId) == 0) then -- 判断当前锁是否还是被自己持有
    return nil; -- 如果已经不是自己，则直接返回
end;
local count = redis.call('HINCRBY', key, threadId, -1); -- 是自己的锁，则重入次数-1
 
if (count == 0) then -- 判断是否重入次数是否已经为0
    redis.call('DEL', key); -- 等于0说明可以释放锁，直接删除
    return nil;    
end;
 
完整代码
import java.util.Collections;
import java.util.UUID;
import org.springframework.core.io.ClassPathResource;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.data.redis.core.script.DefaultRedisScript;
import org.springframework.scripting.support.ResourceScriptSource;
 
/**
 * Redis可重入锁
 */
public class RedisLock {
 
    private static final StringRedisTemplate redisTemplate = SpringUtil.getBean(StringRedisTemplate.class);
    private static final DefaultRedisScript LOCK_SCRIPT;
    private static final DefaultRedisScript