分布式锁

最新推荐文章于 2024-09-04 22:16:29 发布

逆凡~

最新推荐文章于 2024-09-04 22:16:29 发布

阅读量156

点赞数

分类专栏： redis

本文链接：https://blog.csdn.net/qq_38735055/article/details/105448232

版权

redis 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

直接基于setnx实现分布式锁

setnx高版本已经可以将设置setnx和设置超时时间合并成原子操作了
当然如果不想解除别人的锁，那么你可能需要threadLocal保存随机值
其实还有一个问题，就是你拿到分布式锁后你来执行，但是执行过程中锁超时了，就会造成一些冲突操作，怎么办？因为你得操作可能很耗费时间，比如是一个大事务操作，这个时候就需要一个后台线程每隔10s来看看是否还拥有锁，如果拥有那么就延长锁时间

Redission

RLock lock = redission.getLock(lockKey);
lock.lock();
lock.unlock();其实就是对我们上面的封装，设置的key的value就是线程ID，超时时间是30s

在这里插入图片描述
这个Lua脚本来实现原子性?Lua不太懂，看来得去学学了
为什么Lua脚本就有原子性呢？
redis会为lua脚本执行创建伪客户端模拟客户端调用redis执行命令，伪客户端执行lua脚本是排他的
这样redis在执行lua脚本得时候，原本执行得客户端就需要等待伪客户端执行完毕才能继续执行下去，相当于一个原子操作？

RedLock

像上面那种方式，如果是高并发环境下，存在巨大的隐患。比如，如果你在主从架构下，你的设置是在主节点上设置，然后并没有开始同步的时候主节点挂了，这时候另外一个节点来获取分布式锁还是成功的，因为从节点升级为主节点后并没有这个key，这时候就存在两把锁了

多个redis结点，抢过半的锁，并且多个抢锁失败，那么就释放锁重新抢夺，总会有一轮有一个人抢到过半的锁，但是有个很严重的问题，就是锁的时间，因为时间延迟等原因，每个锁的过期时间可能不同，比如一个是8点10分，一个是8点10分05秒，导致第一个先失效了以后另外一个来抢还是能抢到一般的锁，又会出现两把锁的情况，所以整体来看时间是缩小了的
那zookeeper是怎么做的？
假设还是三个客户端，还是三个结点，类似于redis
他其实是基于一个串行化的机制，直接让客户端排队来创建结点，如果第一个创建过一半的结点，那么第二个就不用继续抢了