redis setnx 实现分布式锁和单机锁

对应给定的keys到他们相应的values上。只要有一个key已经存在，MSETNX一个操作都不会执行。由于这种特性，MSETNX可以实现要么所有的操作都成功，要么一个都不执行，这样可以用来设置不同的key，来表示一个唯一的对象的不同字段。

在 Redis 里，所谓 SETNX，是「SET if Not eXists」的缩写，也就是只有不存在的时候才设置，可以利用它来实现锁的效果，不过很多人没有意识到 SETNX 有陷阱！

比如说：某个查询数据库的接口，因为调用量比较大，所以加了缓存，并设定缓存过期后刷新，问题是当并发量比较大的时候，如果没有锁机制，那么缓存过期的瞬间，大量并发请求会穿透缓存直接查询数据库，造成雪崩效应，如果有锁机制，那么就可以控制只有一个请求去更新缓存，其它的请求视情况要么等待，要么使用过期的缓存。

下面以目前 PHP 社区里最流行的 PHPRedis 扩展为例，实现一段演示代码：

<?php

$ok = $redis->setNX($key, $value);

if ($ok) {

$cache->update();

$redis->del($key);

}

?>

缓存过期时，通过 SetNX 获取锁，如果成功了，那么更新缓存，然后删除锁。看上去逻辑非常简单，可惜有问题：如果请求执行因为某些原因意外退出了，导致创建了锁但是没有删除锁，那么这个锁将一直存在，以至于以后缓存再也得不到更新。于是乎我们需要给锁加一个过期时间以防不测：

<?php

$redis->multi();

$redis->setNX($key, $value);

$redis->expire($key, $ttl);

$redis->exec();

?>

因为 SetNX 不具备设置过期时间的功能，所以我们需要借助 Expire 来设置，同时我们需要把两者用 Multi/Exec 包裹起来以确保请求的原子性，以免 SetNX 成功了 Expire 却失败了。 可惜还有问题：当多个请求到达时，虽然只有一个请求的 SetNX 可以成功，但是任何一个请求的 Expire 却都可以成功，如此就意味着即便获取不到锁，也可以刷新过期时间，如果请求比较密集的话，那么过期时间会一直被刷新，导致锁一直有效。于是乎我们需要在保证原子性的同时，有条件的执行 Expire，接着便有了如下
Lua 代码：

local key = KEYS[1]

local value = KEYS[2]

local ttl = KEYS[3]

local ok = redis.call('setnx', key, value)

if ok == 1 then

redis.call('expire', key, ttl)

end

return ok

没想到实现一个看起来很简单的功能还要用到 Lua 脚本，着实有些麻烦。其实 Redis 已经考虑到了大家的疾苦，从 2.6.12 起，SET 涵盖了 SETEX 的功能，并且 SET 本身已经包含了设置过期时间的功能，也就是说，我们前面需要的功能只用 SET 就可以实现。

<?php

$ok = $redis->set($key, $value, array('nx', 'ex' => $ttl));//注意这里控制了不存在才设置 以及超时时间

if ($ok) {

$cache->update();

$redis->del($key);

}

?>

如上代码是完美的吗？答案是还差一点！设想一下，如果一个请求更新缓存的时间比较长，甚至比锁的有效期还要长，导致在缓存更新过程中，锁就失效了，此时另一个请求会获取锁，但前一个请求在缓存更新完毕的时候，如果不加以判断直接删除锁，就会出现误删除其它请求创建的锁的情况，所以我们在创建锁的时候需要引入一个随机值：

<?php

$ok = $redis->set($key, $random, array('nx', 'ex' => $ttl));

if ($ok) {

$cache->update();

if ($redis->get($key) == $random) {

$redis->del($key);

}

}

?>

如此基本实现了单机锁，假如要实现分布锁，请参考：Distributed locks with Redis，这里就不深入讨论了，总结：避免掉入 SETNX 陷阱的最好方法就是永远不要使用它

所谓并发控制，就是指系统必须能够对并发操作之间的相互作用加以控制，正确协调并发操作的执行以获得正确的结果。若操所是串行执行的，那么肯定不会发生并发执行的冲突，因此，并发控制机制的本质就是让冲突的并发操作在某个地方得到串行化。

退款系统采用无管理节点的对等集群结构，统一对外提供退款业务，所有节点的作用是一样的，均可独立完成单次退款请求，因此，无法通过管理节点来执行统一调度，实现并发控制，只能通过使用协议或规则来保证串行化，即所谓的并发控制规则，如果这个规则被每个并发操作所遵守，那么就将确保所有参与的并发操作是串行化的。

2.1 分布式锁服务

谈到并发控制，首先想到的当然是锁服务。退款系统是一个集群系统，面临多个节点间的锁问题，因此，需要的是一种可供集群不同节点使用的锁服务，即分布式锁服务。

另外，目前退款系统中对于单次退款请求是同步处理，若无法获取锁需立即返回，即只能使用非阻塞模式锁(non blocking lock)，以免较长时间等待导致退款调用超时，通过退款补流程脚本来异步完成后续工作。

2.1.1 用Redis实现分布式锁服务

Redis是一个开源的使用C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库。它本身没有锁的概念，利用其单进程单线程结构，采用队列模式将并发访问变为串行访问，从而实现分布式锁服务。

2.1.1.1 实现原理

Redis的SETNX命令（SET if Not eXists）可以用作加锁原语(locking primitive)。SETNX key value命令，将key的值设为value ，当且仅当key不存在；若给定的key已经存在，则SETNX不做任何动作，成功返回1，失败返回0。

比如说，要对某资源（key）Bank_Id_4001加锁，退款节点可以尝试以下方式：

SETNX Bank_Id_4001 <current Unix time + lock timeout + 1>

如果SETNX返回1，说明该退款节点获得锁，key设置的时间戳则指定了锁失效的时间，即超时时间，之后可以通过DEL Bank_Id_4001来释放锁。

如果SETNX返回0，说明key已经被其他节点上锁了。

2.1.1.2 处理死锁(deadlock)

上面的锁定逻辑面临一个问题：如果一个持有锁的退款节点失败、崩溃或者执行超时了不能释放锁，该怎么解决？

可以通过key对应的超时时间戳来判断这种情况是否发生了，如果当前时间戳已经大于key值的超时时间戳，说明该锁已失效，可以被重新使用。

但是，发生这种情况时，不能简单粗暴地DEL死锁的key，再用SETNX上锁，因为当有多个节点同时检测一个锁是否过期并尝试释放它的时候，竞争条件(race condition)已经形成了：

1. 请求0持有锁，但崩溃了。

2. 请求1和请求2发送GET key获得时间戳，检查发现已超时。

3. 请求1发送DEL key。

4. 请求1发送SETNX key并成功，请求1获得锁。

5. 请求2发送DEL key。

6. 请求2发送SETNX key并成功，请求2获得锁。

因为竞争条件的关系，请求1 和 请求2 两个节点都获得了锁。对于该问题，可通过以下操作避免：

1. 请求1发送SETNX key想要获得锁，由于请求0还持有锁，所以Redis返回0

2. 请求1发送GET key以检查锁是否超时了，如果没超时，则返回调用。

3. 反之，如果已超时，请求1继续通过下面的操作来尝试获得锁：

GETSET key <current Unix time + lock timeout + 1>，该命令将给定key的值设为value ，并返回key的旧值(old value)；当 key没有旧值时，也即是，key不存在时，返回nil

4. 通过GETSET，请求1拿到的时间戳如果仍然是超时的，那就说明，请求1如愿以偿拿到锁了。

5. 如果在请求1之前，有其他请求比请求1快一步执行了上面的操作，那么请求1拿到的时间戳是未过期的，这时，请求1没有如期获得锁。注意，尽管请求1没拿到锁，但它改写了其他请求设置的key的超时时间戳，不过这一点非常微小的误差带来的影响可以忽略不计。

注意：为了让分布式锁的算法更稳键些，持有锁的节点在解锁之前应该再检查一次自己的锁是否已经超时，再去做DEL操作，因为可能节点因为某个耗时的操作而挂起，操作完的时候锁因为超时已经被别人获得，这时就不必解锁了。

2.1.1.3 优劣势

优势：实现简单，直接部署Redis即可使用；横向扩展容易，可任意增加资源key，只需在缓存中存储该Key-Value对。

劣势：Redis只能单机部署，出现故障将导致整个锁服务不可用。如果部署成对等集群结构，还需要另外的机制来保证Redis集群的数据一致性，增大了实现难度。

2.1.1 用zookeeper节点名称的唯一性实现分布式共享锁

zookeeper是一个基于google chubby原理开发的，针对大型分布式系统的可靠协调系统，提供的功能包括：配置维护、名字服务、分布式同步、组服务等

2.1.1.1 实现原理

ZooKeeper抽象出来的节点结构是一个和unix文件系统类似的小型的树状的目录结构，并规定：同一个目录下只能有一个唯一的文件节点名。例如：两个客户端想要在Zookeeper的/lock目录下创建一个key为Bank_Id_4001的节点，只有一个能够成功。

Zookeeper中还有一种特殊节点：临时节点，由某个客户端创建，当客户端与ZooKeeper集群断开连接，则该临时节点自动被删除。

利用Zookeeper的名称唯一性和临时节点这两个特性，即可实现分布式锁服务：

1. 客户端在某个lock目录下创建key子节点，类型为EPHEMERAL（临时节点）。

2. 若创建成功，则表示获得锁，处理完成之后删除该节点即可解锁。

3. 若创建失败，表示已被其他请求获取，则返回调用。

2.1.1.2 优劣势

优势：实现简单，部署即可使用，其正确性和可靠性由ZooKeeper机制保证；无Redis的单点问题；当获得锁的退款节点崩溃或宕机时，不会产生死锁问题，临时节点会被自动删除。横向扩展容易，根据不同key创建不同子节点即可。

劣势：需要增加额外的服务集群，增加了实现成本；无超时机制，获取锁的退款节点不能长时间持有锁，否则会导致其他需要使用该资源的请求被延迟。

2.1.2 利用数据库实现共享锁

2.1.2.1 实现原理

Mysql数据库的InnoDB引擎带有行锁功能，可利用该功能实现分布式锁服务：

首先，在数据库中建立一张拥有锁标识的表，建立表的SQL语句如下：

CREATE TABLE MBS_LOCKS

(

LOCK_KEY VARCHAR2(40) NOT NULL,

IMARY KEY (LOCK_KEY）

)

表创建好之后，对于比较固定的通道ID和商户ID key，可以在使用之前插入一些记录；对于交易单key，无法在退款之前准确获知，只能在退款请求执行中插入记录。注意，钱包系统保证同类型的key不会出现重复问题，但为了防止不同类型的key重复，可以在key前加上一些特殊类型字符串，比如trans_id，band_id等等
当节点需要获取锁时，先去该表中查询操作相关key对应的锁，执行查询的SQL形如

select * from MBS_LOCKS where t.lock_key='TRANS_ID_XXX' for update;

若执行成功，则获得锁；若执行失败，则表示锁已被获取，返回调用。

2.1.2.2 优劣势

优势：简单方便，可建立在已有系统之上，无需添加额外的系统实现，对于退款系统的改动少，实现成本低；横向扩展容易，当增加key时，只需要在数据库中增加一条记录即可。

劣势：对于数据库的访问较大，特别是根据交易单来进行并发控制时，几乎每一笔交易的部分退款都需要去访问数据库。由于线上数据库不支持删除操作，因此，需要定期对已经退款的交易单key进行删除，因为退款完成之后，对应的交易单key就不会被再次使用。

2.2 分布式队列

既然并发控制的本质是串行化并发冲突操作，那么先进先出队列当然也是一个不错的选择，与锁服务类似，退款系统依然需要的是可在集群之间使用的分布式队列

2.2.1 用zookeeper顺序节点实现分布式队列

2.2.2 实现原理

Zookeeper中有一种节点叫做顺序节点，故名思议，假如在/queue_fifo/key目录下创建3个子节点，ZooKeeper集群会按照提起创建的顺序来创建节点，节点分别为/queue_fifo/key/0000000001、/queue_fifo/key/0000000002、/queue_fifo/key/0000000003。

利用该顺序节点的特性，即可实现分布式队列：

退款节点接收进程获取到退款请求之后，在对应队列目录下创建子节点，类型SEQUENTIAL（顺序节点），以保证所有成员加入队列时都是有编号的。
退款节点消费进程获取各队列目录下的所有子节点元素。若存在子节点，则消费节点序号最小的请求并删除该子节点，以保证FIFO；若不存在，则等待。

注意：退款集群节点共同消费分布式队列，要做到全局的间隔发送，需要为每个请求子节点增加一个时间字段，用于标示前一个请求的执行时间，每当从队列中取出一条请求，就将当前时间记录到后一个请求的时间字段中，即可实现并发冲突操作的串行化。

2.2.2.1 优劣势

优点：退款系统除了并发控制之外，还需要实现异步化的处理。单次同步退款请求执行过程中涉及的RPC调用太多，导致耗时较长，需要在执行到某个阶段之后，该同步请求就立刻返回，由退款系统内部来保证异步完成后续的工作。因此，使用分布式队列的方式，即可实现异步化处理，也可实现并发控制。对于无需并发控制的退款请求，添加到普通队列中；需要并发控制的请求，则添加到间隔发送队列中。

缺点：需要添加额外的服务集群，增加了实现成本；不易横向扩展，增加资源key时，需要创建一个新的队列目录。

三 后记

目前退款业务中的并发控制仍然处于调研阶段，暂无定论。上面提到的四种并发控制机制各有优劣，需综合考虑各种因素才能制定具体的实现方案。下表仅从部署难易程度、成本、可靠性等占比较重因素对四种方案进行了比较：

并发控制实现机制	部署难易程度	部署成本	是否易于横向扩展	可靠性	对现有系统影响程度
Redis分布式锁服务	较小	较小	易	较可靠	小
Zookeeper分布式锁服务	较大	较大	较易	可靠	小
数据库分布式锁服务	小	小	易	可靠	较小
Zookeeper分布式队列服务	较大	较大	较难	可靠	大(同时满足了异步化需求)