当前位置：网站首页>从源码角度剖析redis分布式锁

从源码角度剖析redis分布式锁

2022-04-21 07:07:00 【dengk2013】

解决思路：需要自己加的锁自己解锁，通过线程id来判断是否是自己加的锁

 这样做的话：重现刚刚说的问题：比如第一个线程执行了15s,此时第一个线程已经释放了锁，第二个线程拿到了锁，需要执行8s,当执行到第5s，第一个线程执行玩了，需要释放锁，判断当前的clientId和redis的不一样，所以不会释放锁，也就是不会删除第二个线程的锁，当第二个线程执行玩了，释放锁能成功，这就起到了锁的作用，自己加的锁，自己释放，第一个线程由于超时早就释放锁了,所以就不会影响下一个线程去争抢锁

但是有有新的问题：如何保证锁周期类业务代码执行完？

通过锁续命来增加锁的时间，比如可以通过定时任务来检查加锁时间快结束，我们增加加锁的时间，这样就可以保证在锁的周期来完成业务代码

3行代码解决分布式锁：redission组件的使用

 

 每个10s检测是否还有锁，如果锁还存在直接设置该锁的时间为30s

对于上述redis主从架构存在的问题：第一个线程进来后抢到锁，加锁也成功了，此时redis在做主从的时候主节点宕机了，导致从节点没有来得及复制，也就是从节点没有key,那么主从节点从新选举的时候，从节点变成了主节点，主节点没有key,此时第二个线程进来后仍然可以加锁成功，也就是一个产品可能被枷锁2次，导致超卖的问题，当然这种概率几乎为0，当然我们也可以通过zk分布式锁可以解决主从节点失效带来的问题

如何提高分布式锁的效率？对redis中的key进行分段存储，比如有A商品有100个，redis存放可以这样存放： A_001=1000可以这样设置key,A001_1=100,A001_2=100,A001_3=100,....这样通过分段锁可以大大提高效率

版权声明
本文为[dengk2013]所创，转载请带上原文链接，感谢
https://blog.csdn.net/u012222011/article/details/124293865

边栏推荐

猜你喜欢

随机推荐