redis散布式锁优化的实现

对单机的利用来讲，可以直接使用synchronized关键字或着Lock工具类来加锁；但是对散布式利用我们需要凭仗一些工具来实现加锁；

加锁流程通俗来解释就是：
1. 占坑
2. 履行逻辑
3. 填坑

我们可使用redis来完成占坑这个操作；

基础版加锁

//通过占坑的方式获得锁
boolean lock = redis.setIfAbsent(key, value);
if (lock) {
//业务逻辑

//填坑
redis.delete(lock)
}

如果获得锁以后，利用宕机致使未释放锁，会造成死锁

获得锁的时候需要给锁添加过期时间

redis.setIfAbsent(key, value);
redis.expire(key, value);

如果在获得锁的时候，意外致使过期时间没设置成功，也会致使死锁

通过lua脚本将set、expire两个操作合并成原子操作，确保过期时间能设置成功

如果锁过期了，但是当前任务未履行结束，此时锁便可能被其他利用获得到，并更新锁的key。如果此时当前任务履行结束去释放锁，会将他人的锁给释放掉

释放锁：

• 判断当前锁的值和自己上锁的值是不是是吻合的；
• 如果不吻合则不释放；
• 如果值吻合，就删除key释放锁；

在释放锁的时候，如果判断key值吻合，但此时key过期了，锁被他人获得到，此时再删除key，就是释放了他人的锁了
要保证查询、判断、删除逻辑为原子操作，使用lua脚本

如何保障锁的可重入

如果在递归方法有加锁逻辑或其他调用有

lock.lock();
//逻辑
lock.lock();
//逻辑
lock.unLock();
lock.unLock();

要实现可重入锁，可以在锁的value值上做文章,在value值上记录重入次数，每次重入次数加一，每次unlock次数减一，直至为零，则删除key 释放锁；

key:
{
    "value":1
}

如果业务逻辑时间太长，锁提早过期释放了怎样办

• 将过期时间设置的长一点
• 需要给锁添加续期功能。

设置长过期时间的弊端就是，如果利用宕机以后锁需要经历较长的时间才能被他人获得，影响业务；

如果是有续期功能的话，如果宕机，锁也会被较短的过期时间给刷掉，是种更优美的解决方式；

如redission中获得锁后，会启动一个watchDog线程来监控当前线程会不会还持有锁，如果还持有锁，就给他续期

具体操作为： 每十秒检查一下会不会持有锁，如果锁未释放就重置一下锁的过期时间，实现续期；

如果利用在redis的master节点上获得锁成功，此时该master节点宕机，且锁数据还未同步到slave节点上，主从切换以后，其他利用趁机也获得了散布式锁

redLock

主从结构不是会有问题吗，redlock就换成使用多个不相关的、没有主从关系的redisMaster节点，来保证他们不会同时宕机，总数最好为奇数个。
redLock通过在多个节点上同时获得锁，如果超过半数的节点都获得锁成功，才算成功；否则失败，回滚删除所有节点的锁。

参考

原来大厂Redis散布式锁都这么设计的

Redis散布式锁的原理和如何续期

到此这篇关于redis散布式锁优化的实现的文章就介绍到这了,更多相关redis散布式锁优化内容请搜索之前的文章或继续浏览下面的相关文章希望大家以后多多支持！

本文来源：https://www.yuntue.com/post/149622.html | 云服务器网，转载请注明出处！