redis分布式锁(2)
【摘要】 优化之UUID防误删编辑编辑问题:删除操作缺乏原子性。场景:index1执行删除时,查询到的lock值确实和uuid相等uuid=v1set(lock,uuid); 编辑index1执行删除前,lock刚好过期时间已到,被redis自动释放,在redis中没有了lock,没有了锁。 编辑index2获取了lockindex2线程获取到了cpu的资源,开始执行方法uuid=v2se...
优化之UUID防误删
问题:删除操作缺乏原子性。
场景:
index1执行删除时,查询到的lock值确实和uuid相等
uuid=v1
set(lock,uuid);
index1执行删除前,lock刚好过期时间已到,被redis自动释放,在redis中没有了lock,没有了锁。
index2获取了lock
index2线程获取到了cpu的资源,开始执行方法
uuid=v2
set(lock,uuid);
index1执行删除,此时会把index2的lock删除
index1 因为已经在方法中了,所以不需要重新上锁。index1有执行的权限。index1已经比较完成了,这个时候,开始执行
删除的index2的锁!
优化之LUA脚本保证删除的原子性
Lua 脚本详解:
项目中正确使用:
定义key,key应该是为每个sku定义的,也就是每个sku有一把锁。
总结
加锁
使用lua释放锁
重试
为了确保分布式锁可用,我们至少要确保锁的实现同时满足以下四个条件:
- 互斥性。在任意时刻,只有一个客户端能持有锁。
- 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁,也能保证后续其他客户端能加锁。
- 解铃还须系铃人。加锁和解锁必须是同一个客户端,客户端自己不能把别人加的锁给解了。
- 加锁和解锁必须具有原子性
【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱:
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论(0)