本篇内容主要讲解“redis分布式锁优化的具体实现”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“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就换成使用多个不相关的、没有主从关系的redisMaster节点，来保证他们不会同时宕机，总数最好为奇数个。
redLock通过在多个节点上同时获取锁，如果超过半数的节点都获取锁成功，才算成功；否则失败，回滚删除所有节点的锁。
到此，相信大家对“redis分布式锁优化的具体实现”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
