经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置:技术经验 » 数据库/运维 » Redis » 查看文章
redis实现分布式锁(包含代码以及分析利弊)
来源:cnblogs  作者:煜航  时间:2023/2/13 8:45:47  对本文有异议

redis实现分布式锁(基础版)

使用redis实现分布式锁的方法有多种,基础版本是基于setnx命令,即如果不存在则设置。这个命令可以保证只有一个客户端能够成功设置一个key,从而获得锁。设置key的时候需要设置一个过期时间,以防止死锁。释放锁的时候需要删除key,或者使用lua脚本来保证原子性。

  1. //导入jedis依赖
  2. import redis.clients.jedis.Jedis;
  3. //定义一个分布式锁的类
  4. class RedisLock {
  5. //定义一个jedis对象,用于连接redis
  6. private Jedis jedis;
  7. //定义一个锁的key
  8. private String lockKey;
  9. //定义一个锁的过期时间,单位是毫秒
  10. private long expireTime;
  11. //构造方法,传入jedis对象,锁的key和过期时间
  12. public RedisLock(Jedis jedis, String lockKey, long expireTime) {
  13. this.jedis = jedis;
  14. this.lockKey = lockKey;
  15. this.expireTime = expireTime;
  16. }
  17. //尝试获取锁的方法,返回一个布尔值,表示是否成功获取锁
  18. public boolean tryLock() {
  19. //使用setnx命令,如果成功设置key,返回1,否则返回0
  20. long result = jedis.setnx(lockKey, "1");
  21. //如果返回1,表示获取锁成功
  22. if (result == 1) {
  23. //设置key的过期时间,防止死锁
  24. jedis.pexpire(lockKey, expireTime);
  25. //返回true
  26. return true;
  27. }
  28. //如果返回0,表示获取锁失败
  29. else {
  30. //返回false
  31. return false;
  32. }
  33. }
  34. //释放锁的方法
  35. public void unlock() {
  36. //删除key,释放锁
  37. jedis.del(lockKey);
  38. }
  39. }

基础代码优缺点:

分析一下这个代码的优缺点。这个代码的优点是简单易懂,使用setnx命令可以保证锁的互斥性,使用过期时间可以防止死锁。这个代码的缺点是不够健壮,有以下几个问题:

  • 如果在设置key的过期时间之前,客户端崩溃或者网络中断,那么key可能永远不会过期,导致其他客户端无法获取锁。
  • 如果在释放锁之前,客户端崩溃或者网络中断,那么key可能没有被删除,导致其他客户端无法获取锁。
  • 如果在释放锁的时候,key已经过期,那么可能会误删其他客户端设置的key,导致锁的安全性被破坏。
  • 如果锁的过期时间太短,那么可能会导致客户端在执行任务的过程中,锁被其他客户端抢占,导致任务的一致性被破坏。
  • 如果锁的过期时间太长,那么可能会导致客户端在获取锁失败的情况下,等待的时间过长,导致性能下降。

redis实现分布式锁(进阶版)

为了解决这些问题,可以使用一些更复杂的逻辑,如使用lua脚本来保证设置key和过期时间的原子性,使用唯一的随机值来标识锁的持有者,使用续租机制来延长锁的过期时间等。

  1. //导入jedis依赖
  2. import redis.clients.jedis.Jedis;
  3. //定义一个分布式锁的类
  4. class RedisLock {
  5. //定义一个jedis对象,用于连接redis
  6. private Jedis jedis;
  7. //定义一个锁的key
  8. private String lockKey;
  9. //定义一个锁的过期时间,单位是毫秒
  10. private long expireTime;
  11. //定义一个锁的唯一值,用于标识锁的持有者
  12. private String lockValue;
  13. //定义一个续租线程,用于延长锁的过期时间
  14. private Thread renewThread;
  15. //定义一个lua脚本,用于原子性地设置key和过期时间
  16. private String setScript = "if redis.call('setnx', KEYS[1], ARGV[1]) == 1 then return redis.call('pexpire', KEYS[1], ARGV[2]) else return 0 end";
  17. //定义一个lua脚本,用于原子性地删除key
  18. private String delScript = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
  19. //构造方法,传入jedis对象,锁的key和过期时间
  20. public RedisLock(Jedis jedis, String lockKey, long expireTime) {
  21. this.jedis = jedis;
  22. this.lockKey = lockKey;
  23. this.expireTime = expireTime;
  24. }
  25. //尝试获取锁的方法,返回一个布尔值,表示是否成功获取锁
  26. public boolean tryLock() {
  27. //生成一个唯一的随机值,作为锁的值
  28. lockValue = UUID.randomUUID().toString();
  29. //使用lua脚本,原子性地设置key和过期时间,如果成功返回1,否则返回0
  30. long result = (long) jedis.eval(setScript, 1, lockKey, lockValue, String.valueOf(expireTime));
  31. //如果返回1,表示获取锁成功
  32. if (result == 1) {
  33. //创建一个续租线程,每隔一半的过期时间,就延长锁的过期时间
  34. renewThread = new Thread(() -> {
  35. while (true) {
  36. try {
  37. //休眠一半的过期时间
  38. Thread.sleep(expireTime / 2);
  39. //延长锁的过期时间
  40. jedis.pexpire(lockKey, expireTime);
  41. } catch (InterruptedException e) {
  42. //如果线程被中断,退出循环
  43. break;
  44. }
  45. }
  46. });
  47. //启动续租线程
  48. renewThread.start();
  49. //返回true
  50. return true;
  51. }
  52. //如果返回0,表示获取锁失败
  53. else {
  54. //返回false
  55. return false;
  56. }
  57. }
  58. //释放锁的方法
  59. public void unlock() {
  60. //使用lua脚本,原子性地删除key,只有当key的值和锁的值相等时,才会删除
  61. jedis.eval(delScript, 1, lockKey, lockValue);
  62. //中断续租线程
  63. renewThread.interrupt();
  64. }
  65. }

进阶代码优缺点:

分析一下这个代码的优缺点。这个代码的优点是比之前的代码更健壮,解决了以下几个问题:

  • 使用lua脚本可以保证设置key和过期时间的原子性,避免了客户端崩溃或者网络中断导致的死锁。
  • 使用唯一的随机值可以标识锁的持有者,避免了误删其他客户端设置的key的情况。
  • 使用续租机制可以延长锁的过期时间,避免了锁被其他客户端抢占的情况。
  • 使用lua脚本可以保证删除key的原子性,避免了客户端崩溃或者网络中断导致的锁未释放的情况。

这个代码的缺点是还是有一些问题,如:

  • 如果续租线程出现异常或者延迟,那么锁可能会过期,导致锁的安全性被破坏。
  • 如果锁的过期时间太长,那么可能会导致客户端在获取锁失败的情况下,等待的时间过长,导致性能下降。
  • 如果锁的过期时间太短,那么可能会导致续租线程频繁地延长锁的过期时间,导致网络开销增加。
  • 如果redis服务器出现故障或者主从切换,那么锁的状态可能会丢失,导致锁的一致性被破坏。

为了解决这些问题,可以使用一些更复杂的逻辑,如使用watchdog机制来监控续租线程的状态,使用自旋锁或者阻塞锁来优化锁的等待策略,使用集群或者哨兵模式来提高redis的可用性等。或者可以使用redisson框架,它已经实现了这些逻辑,而且提供了更多的分布式锁的功能和选项。
但是进阶版代码已经能cover大部分的场景,没有技术能实现万无一失,只是在出现问题的时候进行有效的补救,代价在承受范围内就行。也没有什么技术是永恒最好的,抛开业务谈方案就像空中楼阁。
最后,再一次感谢大家的阅读!

原文链接:https://www.cnblogs.com/yuhang-wiki/p/17112225.html

 友情链接:直通硅谷  点职佳  北美留学生论坛

本站QQ群:前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

W3xue 的所有内容仅供测试,对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接(目前9元/月)请联系QQ:27243702 沸活量
皖ICP备17017327号-2 皖公网安备34020702000426号