浅谈分布式锁

曹思远 360云计算

1 分布式锁概述

从进程锁到分布式锁

在单进程环境中，为了防止多线程同时对共享资源进行读写操作，我们通常使用内核或者类库实现线程间的互斥。当扩展到分布式系统下，我们需要提供相同功能的分布式锁服务，不同的主机通过该服务获取一把锁，而获取该锁的机器就可以排他性的访问共享资源。

在单机环境下，操作系统知道自己进程的状态，当进程挂掉的时候该进程会释放自己持有的锁资源，但在分布式环境下，存在宕机、网络分区、时延等各种异常状态，因此需要给分布式锁提供新的特性：可用性。

分布式锁的系统分类

基于锁资源的安全性，可以将分布式锁分为以下两部分：
基于异步复制的分布式系统，例如：redis、mysql

基于paxos协议的分布式一致性系统，例如：etcd、zookeeper

基于异步复制的分布式系统，存在丢锁的风险，不够安全，通常使用TTL机制承担细粒度的锁服务，该系统接入简单，适用于对事件很敏感，期望设置一个较短的有效时间，执行短期任务，丢锁对业务影响相对可控的服务。

基于paxos协议的分布式系统，通过一致性协议保证数据的多副本，数据的安全性高，通常使用lease机制承担粗粒度的锁服务，适用于对安全性很敏感，希望长期持有锁，不希望发生丢锁现象的服务。

2 基于 redis 的分布式锁

通常可以使用setnx（set if not exists）实现排他的获取锁操作，但是由于分布式系统中进程可能随时宕机，因此获取锁时，需要添加TTL保证锁不会因为进程挂掉之后变成死锁状态，但是此时又出现了第二个问题，那就是setnx和expire操作必须是原子操作，因为setnx之后，如果进程挂掉，expire有可能没有机会执行，这同样会导致死锁。正确的操作如下：

SET lock_name value NX EX lock_time

EX second：设置 key 的过期时间，单位是秒
NX：当 key 不存在的时候进行设置，等同于 SETNX 操作

释放锁时，只需要调用DEL命令删除锁即可：

DEL lock_name

需要注意的是，这里有可能出现错误删除锁的问题。场景如下：

进程A加锁成功，锁超时时间20秒。由于进程A业务逻辑执行过长，20秒之后，锁过期自动释放。
此时进程B接着加锁，加锁成功后，执行业务逻辑。这期间，进程A结束执行，使用DEL释放锁。

这样就导致进程A错误的释放进程B的锁。因此，为了不被错误的释放锁，我们在加锁的时候需要设置UUID。例如：

SET lock_name uuid NX EX lock_time

释放锁时，需要先获取锁的UUID，如果是自己分配的，则释放锁。但是这里的比较和释放操作必须是原子操作，否则会出现获获取锁比对的时候正确，此时正好TTL过期，另一个进程加锁成功，这样的话还是会出现错误释放锁的操作。可以使用Lua脚本实现判断与删除的原子操作。

3 基于 etcd/zookeeper 的分布式锁

排他锁（exclusive locks）

排他锁（写锁、独占锁）表现如下：

进程p1对数据d1加上排他锁，那么在整个加锁期间，只允许进程p1对数据d1进行读取和更新操作，其他任何进程都不能再对整个数据进行任何类型的操作。直到p1释放排他锁。

通过在zk/etcd上的数据节点来表示一个锁

上面/exclusive_lock/lock1节点，就可以被定义为一个锁。

获取锁：

创建排他锁：需要获取排他锁的时候，所有的客户端都会试图调用create()接口，在/exclusive_lock节点下创建临时子节点/exclusive_lock/lock1。zk/etcd会保证在所有的客户端中，最终只有一个客户端能够创建成功，那么就可以为该客户端获取锁。
watch排他锁：所有没有成功获取锁的客户端就要到/exclusive_lock节点上注册一个子节点变更的watcher监听，用于实时监听lock1节点的变更情况。

释放锁即移除该临时节点。由于/exclusive_lock/lock1是一个临时节点（etcd通过租约，通过发送心跳来续租），因此需要考虑以下情况：

已经获取锁的client发生了宕机，那么zk/etcd上整个临时节点就会被移除

2.正常完成业务之后，client会主动删除临时节点

无论在什么情况下移除lock节点，zk/etcd都会通知所有watcher /exclusive_lock的客户端。这些客户端在接受到通知之后，再次重新发起分布式锁获取，即重复获取锁过程。

共享锁（shared locks）

共享锁（读锁）表现如下：

进程p1对数据d1加上共享锁，那么当前事务只能对d1进行读取操作，其他事务也只能对整个数据加共享锁，直到该数据对象上的所有共享锁都被释放。

与排他锁的区别是，加上排他锁之后，数据只对一个事务可见，而加上共享锁之后，数据对所有事务可见。

定义锁：

同样是通过zk/etcd上的数据节点表示一个锁，格式可以参考/shared_lock/[hostname]-请求类型-序号的临时节点。

例如：下图中/shared_lock/host1-R-001就代表了一个共享锁

需要获取共享锁时，所有客户端都会到/shared_lock整个节点下创建一个临时顺序节点。

如果当前是读请求，创建/shared_lock/192.168.0.1-R-01节点
如果是写请求，创建/shared_lock/192.168.0.1-W-02节点

根据共享锁的定义，

不同的事务可以对同一数据对象进行读取操作
更新操作必须在当前没有任何事务进行读写操作的情况下进行

zk/etcd的读写顺序：

创建完节点，获取/shared_lock节点下的所有子节点，并对该节点注册子节点变更的watcher监听
确定自己的节点序号，在所有子节点中的顺序
对于读请求：

a.如果没有比自己小的子节点，或者所有比自己小的子节点都是读请求，那么自己已经成功获取到共享锁，可以开始业务逻辑

b.如果比自己小的节点中有写请求，那么需要进入等待

4.对于写请求：

a.如果自己不是序号最小的子节点，那么就需要进入等待

5.接收到watcher通知后，重复步骤1

释放锁与排他锁是一致的：

例子：

1. 主机10.16.0.1先进行读操作，完成后，将节点/shared_lock/10.16.0.1-R-000001删除
剩余4台机器均收到节点移除通知，然后重新从/shared_lock节点上获取一份新的子节点列表
每个主机判读自己的读写顺序。接着，主机10.16.0.2检测到自己已经是需要最小的了，于是开始执行写操作，而其他主机发现没有轮到自己进行读取或者更新操作，于是继续等待
继续上面循环

浅谈分布式锁