redis 通过setnx实现的分布式锁有问题

如图：

解决的新的工具为（闪亮登场）：redisson

redisson可重入锁的原理

实现语言lua：

加锁实现脚本语言：

释放锁的脚本语言：

加锁的lua

-- 首先判断这个锁是否存在，也就是判断key是否存在。不存在则直接加锁，存在则判断是否flied是否存在，
if(redis.call('EXISTS',KEYS[1]) == 0)then
    redis.call('HSET',KEYS[1],ARGV[1],'1')
    redis.call('EXPIRE',KEYS[1],ARGV[2])
    return 1
end
if(redis.call('HEXISTS',KEYS[1],ARGV[1]) == 1)then
    redis.call('HINCRBY',KEYS[1],ARGV[1],1)
    redis.call('EXPIRE',KEYS[1],ARGV[2])
    return 1;
end
return 0

释放锁的lua（比人觉得是在大于0的基础上减一，但是我觉得应该是在大于1的基础上减一。因为，在第一次加锁的时候，就设置为1，如果有其他重入则++，第二次则为2，删除顺序的话，应该是第一次大于1不删除，第二次释放锁等于1，也是最后一个锁，则直接删除了）

-- 删除逻辑，如果key存在，则查找flied，如果flied的值大于1，则释放锁，并减1

if(redis.call('HEXISTS',KEYS[1],ARGV[1]) == 1) then
    local num = redis.call('HGET',KEYS[1],ARGV[1]);
    local count = tonumber(num)
    if(count >1) then
        redis.call('HINCRBY',KEYS[1],ARGV[1],-1)
        redis.call('EXPIRE',KEYS[1],ARGV[2])
        return 1
    else
    redis.call('del',KEYS[1])
    return 1
    end
end
return 0

1、redisson的重入机制：通过redis hash实现

2、redisson的可重试机制：对于一个线程去获取锁，如果ttl（key的剩余过期时间），如果等于null，则为没有相对应的key，则可以加锁成功。如果不为null则说明已经key了，加锁失败。失败之后就是等待。等待也不是死等（一直while循环），因为redis在释放一个键的时候，会发布一个通知，其他线程一直等待这个通过，有了通知之后，再次判断是否已经过了等待时间（设置的一个线程最长的等待时间，如果超出则获取锁失败）。没有超过，则去获取锁，没有获取成功。判断是否超过设置的等待时间。如果没有超过则继续等待，这个等待就是在while循环当中（while循环里也不是一直循环，而是等待锁释放的通知）。

通知是发布订阅模式 ：订阅：SUBSCRIBE mychannel（mychannel是订阅的频道） 发布：PUBLISH mychannel "Key deleted: mykey"（mychannel 是发布的频道）。发布和订阅是同一个频道，当有key删除，则redis发布这个频道的通知，其他线程收到这个通知之后，则就会去获取相应的锁了。

3、redisson超时释放：对于一个线程获取锁之后，key就会超时释放，这样就造成了并发的问题。为了解决这样的问题，给每一个获取锁的线程增加一个定时的任务（TimeOut），如果key释放的时间剩余key设置的释放时间的三分之一的话，就重新给key重新设置超时释放的值（这个值一直是原本的时间）。（看门狗机制）

4、主从节点：主节点（写，然后同步给从节点），用户的查询都到从节点（主查）。当主节点宕机，就会出现主节点的数据还没有同步到从节点，导致的一系列的问题。

        解决方法：使用集群节点，全部都是node，每个node都可以读写。避免了因为一个主节点宕机，从节点没有数据的情况。当是分布式锁的时候，只有当所有的节点的都加锁成功的时候，才会返回加锁成功，使用的redisson的mulit的联锁。