redis 通过setnx实现的分布式锁有问题
如图:
解决的新的工具为(闪亮登场):redisson
redisson可重入锁的原理
实现语言lua:
加锁实现脚本语言:
释放锁的脚本语言:
加锁的lua
-- 首先判断这个锁是否存在,也就是判断key是否存在。不存在则直接加锁,存在则判断是否flied是否存在,
if(redis.call('EXISTS',KEYS[1]) == 0)thenredis.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)thenredis.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,则释放锁,并减1if(redis.call('HEXISTS',KEYS[1],ARGV[1]) == 1) thenlocal num = redis.call('HGET',KEYS[1],ARGV[1]);local count = tonumber(num)if(count >1) thenredis.call('HINCRBY',KEYS[1],ARGV[1],-1)redis.call('EXPIRE',KEYS[1],ARGV[2])return 1elseredis.call('del',KEYS[1])return 1end
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的联锁。