免费1级做爰片免费网站,做软件需要网站吗,互联网公司排名去哪里看,专业网站建设价格redis 通过setnx实现的分布式锁有问题
如图#xff1a; 解决的新的工具为#xff08;闪亮登场#xff09;#xff1a;redisson redisson可重入锁的原理 实现语言lua#xff1a;
加锁实现脚本语言#xff1a; 释放锁的脚本语言#xff1a; 加锁的lua -- 首先判断这个锁…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 01、redisson的重入机制通过redis hash实现
2、redisson的可重试机制对于一个线程去获取锁如果ttlkey的剩余过期时间如果等于null则为没有相对应的key则可以加锁成功。如果不为null则说明已经key了加锁失败。失败之后就是等待。等待也不是死等一直while循环因为redis在释放一个键的时候会发布一个通知其他线程一直等待这个通过有了通知之后再次判断是否已经过了等待时间设置的一个线程最长的等待时间如果超出则获取锁失败。没有超过则去获取锁没有获取成功。判断是否超过设置的等待时间。如果没有超过则继续等待这个等待就是在while循环当中while循环里也不是一直循环而是等待锁释放的通知。
通知是发布订阅模式 订阅SUBSCRIBE mychannelmychannel是订阅的频道 发布PUBLISH mychannel Key deleted: mykeymychannel 是发布的频道。发布和订阅是同一个频道当有key删除则redis发布这个频道的通知其他线程收到这个通知之后则就会去获取相应的锁了。
3、redisson超时释放对于一个线程获取锁之后key就会超时释放这样就造成了并发的问题。为了解决这样的问题给每一个获取锁的线程增加一个定时的任务TimeOut如果key释放的时间剩余key设置的释放时间的三分之一的话就重新给key重新设置超时释放的值这个值一直是原本的时间。看门狗机制
4、主从节点主节点写然后同步给从节点用户的查询都到从节点主查。当主节点宕机就会出现主节点的数据还没有同步到从节点导致的一系列的问题。 解决方法使用集群节点全部都是node每个node都可以读写。避免了因为一个主节点宕机从节点没有数据的情况。当是分布式锁的时候只有当所有的节点的都加锁成功的时候才会返回加锁成功使用的redisson的mulit的联锁。
