【Redis】分布式锁

本文介绍了为什么需要使用分布式锁,特别是在多机器环境下的并发问题。基于Redis的分布式锁通过setnx命令实现加锁,并利用超时机制防止死锁。文章讨论了加锁和解锁过程中的原子性问题以及解决方案,如使用Lua脚本和守护线程。还介绍了Redission库提供的tryLock、unLock方法及watch dog自动延期功能,但同时也指出watch dog在主备切换时可能存在的问题,可能导致多个客户端同时获取锁。
摘要由CSDN通过智能技术生成

为什么要用分布式锁

如果原本我们的系统分布在一台机器上的时候,JVM提供的锁就能解决并发问题。但是如果我们是使用多台机器,要同时去Redis里面去拿同一个Key 这个时候,就会发生并发问题,因为这个时候JVM的锁事无
法解决这个问题。

基于Redis的分布式锁

  • 加锁:最简单的方法是使用setnx 命令,Key 是锁的唯一标识

    setnx key value :是去redis尝试set,如果里面已经有key,那么就设置失败返回0
    这里其实就是利用的redis的原子性,实现了CAS的效果。

  • 解锁:有加锁就得有解锁。当得到锁的线程执行完任务,需要释放锁,以便其他线程可以进入。释放锁的最简单方式是执行 del 指令

    del key:删去Key 达到解锁的效果

  • 锁超时
    因为如果宕机 不给锁设置超时,那么就会死锁 ,所以在 setnx的时候需要设置超时时间。expire key times

  • 问题!

    • 第一点: 在加锁和锁超时的时候 不是原子操作
      • 解决方案:可以利用lua ,set 可以添加可选参数
    • del 误删:如果某个业务逻辑的时间超过了超时时间,这个时候如果key 已经被删除了就会有第二个逻辑进来操作 从而没有达到锁的效果。
      • 解决方案:使用守护线程 一直去给我们的key 加上超时时间,这样会让锁不被释放。
        • 守护线程:开辟一个线程 如果主线程挂了或者结束 那么守护线程也会结束。

Redission

tryLock()

 if (redis.call('exists', KEYS[1]) == 0) then 
   redis.call('hset', KEYS[1], ARGV[2], 1); 
   redis.
  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值