redis getset()方法_Redis实现分布式锁的正确方式

原理分析

最近看到好多博主都在推分布式锁，实现方式很多，基于db、redis、zookeeper。zookeeper方式实现起来比较繁琐，这里我们就谈谈基于redis实现分布式锁的正确实现方式。

背景

在很多互联网产品应用中，有些场景需要加锁处理，比如：秒杀，全局递增ID，楼层生成等等。大部分的解决方案是基于DB实现的，Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系。 其次Redis提供一些命令SETNX，GETSET，可以方便实现分布式锁机制。

Redis命令介绍

使用Redis实现分布式锁，有两个重要函数需要介绍。

SETNX命令(SET if Not Exists)

• 语法：

SETNX key value

• 功能：
• 当且仅当 key 不存在，将 key 的值设为 value ，并返回1； 若给定的 key 已经存在，则 SETNX 不做任何动作，并返回0。

GETSET命令

• 语法：

GETSET key value

• 功能：
• 将给定 key 的值设为 value ，并返回 key 的旧值 (old value)， 当 key 存在但不是字符串类型时，返回一个错误，当key不存在时，返回nil。

GET命令

• 语法：

GET key

• 功能：
• 返回 key 所关联的字符串值，如果 key 不存在那么返回特殊值 nil 。

DEL命令

• 语法：

DEL key [KEY …]

• 功能：
• 删除给定的一个或多个 key ,不存在的 key 会被忽略。

兵贵精，不在多。分布式锁，我们就依靠这四个命令。但在具体实现，还有很多细节，需要仔细斟酌，因为在分布式并发多进程中，任何一点出现差错，都会导致死锁，hold住所有进程。

加锁实现

SETNX 可以直接加锁操作，比如说对某个关键词foo加锁，客户端可以尝试 SETNX foo.lock 。

• 如果返回1，表示客户端已经获取锁，可以往下操作，操作完成后，通过 DEL foo.lock 命令来释放锁。
• 如果返回0，说明foo已经被其他客户端上锁，如果锁是非堵塞的，可以选择返回调用。如果是堵塞调用，就需要进入下一个重试循环，直至成功获得锁或者重试超时。

理想是美好的，现实是残酷的。仅仅使用SETNX加锁带有竞争条件的，在某些特定的情况会造成死锁错误。

处理死锁

在上面的处理方式中，如果获取锁的客户端执行时间过长，进程被kill掉，或者因为其他异常崩溃，导致无法释放锁，就会造成死锁。所以，需要对加锁要做时效性检测。

因此，我们在加锁时，把当前时间戳作为value存入此锁中，通过当前时间戳和redis中的时间戳进行对比，如果超过一定差值，认为锁已经时效，防止锁无限期的锁下去。

但是，在大并发情况，如果同时检测锁失效，并简单粗暴的删除死锁，再通过SETNX上锁，可能会导致竞争条件的产生，即多个客户端同时获取锁。

情景描述如下：

1. C1获取锁，并崩溃。C2和C3调用SETNX上锁返回0后，获得foo.lock的时间戳，通过比对时间戳，发现锁超时。
2. C2 向f