[分布式管理] 分布式锁 分布式锁是用来干嘛的

我们知道，在多线程情况下访问一些共享资源需要加锁，不然就会出现数据被写乱的问题。在分布式系统下，这样的问题也是一样的。只不过，我们需要一个分布式的锁服务。对于分布式的锁服务，一般可以用数据库 DB、Redis 和 ZooKeeper 等实现。不管怎么样，分布式的锁服务需要有以下几个特点

安全性（Safety）：在任意时刻，只有一个客户端可以获得锁（排他性）。

避免死锁：客户端最终一定可以获得锁，即使锁住某个资源的客户端在释放锁之前崩溃或者网络不可达。

容错性：只要锁服务集群中的大部分节点存活，Client 就可以进行加锁解锁操作。

Redis 的分布式锁服务

我们通过以下命令对资源加锁。

SET resource_name my_random_value NX PX 30000

解释一下：SET NX 命令只会在 key 不存在的时候给 key 赋值，PX 命令通知 Redis 保存这个 key 30000ms。my_random_value 必须是全局唯一的值。这个随机数在释放锁时保证释放锁操作的安全性。PX 操作后面的参数代表的是这个 key 的存活时间，称作锁过期时间。当资源被锁定超过这个时间时，锁将自动释放。获得锁的客户端如果没有在这个时间窗口内完成操作，就可能会有其他客户端获得锁，引起争用问题。

这里的原理是，只有在某个 key 不存在的情况下才能设置（set）成功该 key。于是，这就可以让多个进程并发去设置同一个 key，只有一个进程能设置成功。而其它的进程因为之前有人把 key 设置成功了，而导致失败（也就是获得锁失败）。

我们通过下面的脚本为申请成功的锁解锁：

if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end

如果 key 对应的 value 一致，则删除这个 key。通过这个方式释放锁是为了避免 Client 释放了其他 Client 申请的锁。例如，下面的例子演示了不区分 Client 会出现的一种问题。

注意，虽然 Redis 文档里说他们的分布式锁是没有问题的，但其实还是很有问题的。尤其是上面那个为了避免 Client 端把锁占住不释放，然后，Redis 在超时后把其释放掉。不知道你怎么想，但我觉得这事儿听起来就有点不靠谱。

一般情况下，我们可以使用数据库、Redis 或 ZooKeeper 来做分布式锁服务，这几种方式都可以用于实现分布式锁。

分布式锁的特点是，保证在一个集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。这就是所谓的分布式互斥。所以，大家在做某个事的时候，要去一个服务上请求一个标识。如果请求到了，我们就可以操作，操作完后，把这个标识还回去，这样别的进程就可以请求到了。

所以，需要分清楚：我是用来修改某个共享源的，还是用来不同进程间的同步或是互斥的。如果使用 CAS 这样的方式（无锁方式）来更新数据，那么我们是不需要使用分布式锁服务的，而后者可能是需要的。所以，这是我们在决定使用分布式锁服务前需要考虑的第一个问题——我们是否需要？

如果确定要分布式锁服务，你需要考虑下面几个设计。

需要给一个锁被释放的方式，以避免请求者不把锁还回来，导致死锁的问题。

Redis 使用超时时间，ZooKeeper 可以依靠自身的 sessionTimeout 来删除节点。

分布式锁服务应该是高可用的，而且是需要持久化的。对此，你可以看一下 Redis 的文档 RedLock 看看它是怎么做到高可用的。

要提供非阻塞方式的锁服务。还要考虑锁的可重入性。

我认为，Redis 也是不错的，ZooKeeper 在使用起来需要有一些变通的方式，好在 Apache 有 Curator 帮我们封装了各种分布式锁的玩法。