一、Redis分布式锁
1.连接
通过jedis来取得和Redis的连接。
2.语法
①setnx key value
当且仅当 key 不存在,将 key 的值设为 value ,并返回1;若给定的 key 已经存在,则 SETNX 不做任何动作,并返回0。
②getset key value
将给定 key 的值设为 value ,并返回 key 的旧值,当 key 存在但不是字符串类型时,返回一个错误,当key不存在时,返回nil。
③get key
返回 key 所关联的字符串值,如果 key 不存在那么返回特殊值 nil 。
④del key
删除给定的一个或多个 key ,不存在的 key 会被忽略。
3.用setnx加锁,死锁或超时直接用del解锁(存在问题)
用时间戳作为value存入
C1获取锁,并崩溃。C2和C3调用SETNX上锁返回0后,获得foo.lock的时间戳,通过比对时间戳,发现锁超时。
C2 向foo.lock发送DEL命令。
C2 向foo.lock发送SETNX获取锁。
C3 向foo.lock发送DEL命令,此时C3发送DEL时,其实DEL掉的是C2的锁。
C3 向foo.lock发送SETNX获取锁。
即C2、C3都获取了锁,产生竞争条件。
4.优化
用getset方法,更新value并返回旧值,通过返回的旧值和get获得的值比较判断是否能拿到锁。
C1获取锁,并崩溃。C2和C3调用setnx上锁返回0后,调用get命令获得当前锁的时间戳T1,通过比对时间戳,发现锁超时。
C4 发送getset命令,并得到老的时间戳T2。
如果T1=T2,说明C4获得时间戳。
如果T1!=T2,说明C4之前有另外一个客户端C5通过调用GETSET方式获取了时间戳,C4未获得锁。只能sleep下,进入下次循环中。
现在唯一的问题是,C4设置的新时间戳,是否会对锁产生影响。C4和C5执行的时间差值极小,并且写入的都是有效时间错,所以对锁并没有影响。