redis分布式锁的实现方式

是什么?为什么要有分布式锁?

首先 现在的项目很少是单体的了 都是分布式的 也就是可能在不同的服务器上 而synchronized这些锁 是JVM层面或者API层面的锁 所以说 无法锁住 我们需要新的方式保证安全 也就是分布锁

有哪些实现方式?

1.zookeeper
2.mysql
3.redis

redis:

在这里插入图片描述
set的key是商品ID value可以是个随机值 大家抢购同一个商品 就给这个商品加一把锁
注意这个10s,现在有两个线程,可能到10s的时候 线程A还没执行完,就释放锁,然后B线程进来了,刚加完锁,A线程执行完了,又要释放锁。它现在能释放谁的锁 只有B的。也就是说,你线程A把B的锁给释放了.
解决方法:
解决方案就是给线程加一个唯一标识(UUID) UUID对上了 才释放
在这里插入图片描述

两个需要知道的知识点

首先要知道2个问题
1.锁超时
有两个服务A和B 如果A获取到锁之后 挂了 那么B将永远无法获取到锁
所以要额外设置一个超时时间 但是如果超时时间太短 就会导致还没执行完 锁就因为过期被释放了
所以redis分布式锁不要用于较长时间的任务

设置锁就用setnx + expire
删除锁就用LUA脚本删除来保证原子性 (逻辑是先获取key 如果存在并且是自己设置的就删除key)

==
2.单点问题
场景:
A服务在主机上获取了锁,然后主机挂了,又选了个主机(这个新主机里面没有A的锁,也就是这没标志位),这个时候B来获取锁,又获取到了刚才的这把锁。现在一把锁被两个线程持有了,就会出问题

这个失败的原因是因为从redis立刻升级为主redis,如果能够过TTL时间再升级为主redis(延迟升级)后,或者立刻升级为主redis但是过TTL的时间后再执行获取锁的任务,就能成功产生互斥效果;

red lock:一种算法 redisson封装了redLock算法
假设有5个redis节点,这些节点之间既没有主从,也没有集群关系。客户端用相同的key和随机值在5个节点上请求锁,请求锁的超时时间应小于锁自动释放时间。当在3个(超过半数)redis上请求到锁的时候,才算是真正获取到了锁。如果没有获取到锁,则把部分已锁的redis释放掉。

个人理解 用作对抗遗忘

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值