方式一
tryLock() { SETNX Key 1 Seconds } release() { DELETE Key }
缺陷：C1 执行时间过长未主动释放锁，C2 在 C1 的锁超时后获取到锁，C1 和 C2 都同时在执行，可能造成数据不一致等未知情况。如果 C1 先执行完毕，则会释放 C2 的锁，此时可能导致另外一个 C3 获取到锁
方式二
tryLock() { SETNX Key UnixTimestamp Seconds } release() { EVAL ( //LuaScript if redis.call("get", KEYS[1] == ARGV[1]) then return redis.call("del", KEYS[1]) else return 0 end ) }
缺陷：极高并发场景下(如抢红包场景)，可能存在 UnixTimestamp 重复问题。分布式环境下物理时钟一致性，也无法保证，也可能存在 UnixTimestamp 重复问题
方式三
tryLock() { SET Key UniqId Seconds } release() { EVAL ( //LuaScript if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end ) }
执行SET key value NX的效果等同于执行SETNX key value
目前最优的分布式锁方案，但是如果在集群下依然存在问题。由于 Redis 集群数据同步为异步，假设在 Master 节点获取到锁后未完成数据同步情况下 Master 节点 crash，在新的 Master 节点依然可以获取锁，所以多个 Client 同时获取到了锁
|
|
|
|
|
|
|
|
|
版权说明：论坛帖子主题均由合作第三方提供并上传，若内容存在侵权，请进行举报
私信
