优化之UUID防误删 问题:删除操作缺乏原子性。 场景: index1执行删除时,查询到的lock值确实和uuid相等 uuid=v1 set(lock,uuid); index1执行删除前,lock刚好过期时间已到,被redis自动释放,在
优化之UUID防误删问题:删除操作缺乏原子性。 场景: index1执行删除时,查询到的lock值确实和uuid相等
index1执行删除前,lock刚好过期时间已到,被redis自动释放,在redis中没有了lock,没有了锁。 index2获取了lock index2线程获取到了cpu的资源,开始执行方法
index1执行删除,此时会把index2的lock删除 index1 因为已经在方法中了,所以不需要重新上锁。index1有执行的权限。index1已经比较完成了,这个时候,开始执行 删除的index2的锁! 优化之LUA脚本保证删除的原子性
Lua 脚本详解: 项目中正确使用定义key,key应该是为每个sku定义的,也就是每个sku有一把锁。
总结加锁 使用lua释放锁 重试 为了确保分布式锁可用,我们至少要确保锁的实现同时满足以下四个条件: - 互斥性。在任意时刻,只有一个客户端能持有锁。 - 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁,也能保证后续其他客户端能加锁。 - 解铃还须系铃人。加锁和解锁必须是同一个客户端,客户端自己不能把别人加的锁给解了。 - 加锁和解锁必须具有原子性 |
2021-06-05
2021-05-27
2021-05-26
2021-06-05
2021-05-16