简介： 阿里云存储提供了残缺的分布式锁解决方案，通过了阿里云泛滥云产品贵重的业务场景中长期锻炼，稳固高牢靠，且提供了多种语言的 SDK 抉择，甚至是 RESTful 集成计划。

1 背景

针对共享资源的互斥拜访从来是很多业务零碎须要解决的问题。在分布式系统中，通常会采纳分布式锁这一通用型解决方案。本文将就分布式锁的实现原理、技术选型以及阿里云存储的具体实际进行阐述。

图 1 锁

2 从单机锁到分布式锁

在单机环境中，当共享资源本身无奈提供互斥能力的时候，为了避免多线程 / 多过程对共享资源的同时读写访问造成的数据毁坏，就须要一个第三方提供的互斥的能力，这里往往是内核或者提供互斥能力的类库，如下图所示，过程首先从内核 / 类库获取一把互斥锁，拿到锁的过程就能够排他性的访问共享资源。演变到分布式环境，咱们就须要一个提供同样性能的分布式服务，不同的机器通过该服务获取一把锁，获取到锁的机器就能够排他性的访问共享资源，这样的服务咱们统称为分布式锁服务，锁也就叫分布式锁。

图 2 单机锁到分布式锁

由此形象一下分布式锁的概念，首先分布式锁须要是一个资源，这个资源可能提供并发管制，并输入一个排他性的状态，也就是：
锁 = 资源 + 并发管制 + 所有权展现
以常见的单机锁为例：
Spinlock = BOOL + CAS（乐观锁）
Mutex = BOOL + CAS + 告诉（乐观锁）
Spinlock 和 Mutex 都是一个 Bool 资源，通过原子的 CAS 指令：当当初为 0 设置为 1，胜利的话持有锁，失败的话不持有锁，如果不提供所有权的展现，例如 AtomicInteger，也是通过资源（Interger）+CAS，然而不会明确的提醒所有权，因而不会被视为一种锁，当然，能够将“所有权展现”这个更多地视为某种服务提供模式的包装。
单机环境下，内核具备“上帝视角”，可能晓得过程的存活，当过程挂掉的时候能够将该过程持有的锁资源开释，但倒退到分布式环境，这就变成了一个挑战，为了应答各种机器故障、宕机等，就须要给锁提供了一个新的个性：可用性。
如下图所示，任何提供三个个性的服务都能够提供分布式锁的能力，资源能够是文件、KV 等，通过创立文件、KV 等原子操作，通过创立胜利的后果来表明所有权的归属，同时通过 TTL 或者会话来保障锁的可用性。

图 3 分布式锁的个性和实现

3 分布式锁的系统分类

依据锁资源自身的安全性，咱们将分布式锁分为两个营垒：
A：基于异步复制的分布式系统，例如 mysql，tair，redis 等；
B：基于 paxos 协定的分布式一致性零碎，例如 zookeeper，etcd，consul 等；
基于异步复制的分布式系统，存在数据失落（丢锁）的危险，不够平安，往往通过 TTL 的机制承当细粒度的锁服务，该零碎接入简略，实用于对工夫很敏感，冀望设置一个较短的有效期，执行短期工作，丢锁对业务影响绝对可控的服务。
基于 paxos 协定的分布式系统，通过一致性协定保证数据的多正本，数据安全性高，往往通过租约（会话）的机制承当粗粒度的锁服务，该零碎须要肯定的门槛，实用于对安全性很敏感，心愿长期持有锁，不冀望产生丢锁景象的服务。

4 阿里云存储分布式锁

阿里云存储在长期的实际过程中，在如何晋升分布式锁应用时的正确性、保障锁的可用性以及晋升锁的切换效率方面积攒比拟多的教训。

4.1 严格互斥性
互斥性作为分布式锁最根本的要求，对用户而言就是不能呈现“一锁多占”，那么存储分布式锁是如何防止该状况的呢？
答案是，服务端每把锁都和惟一的会话绑定，客户端通过定期发送心跳来保障会话的有效性，也就保障了锁的拥有权。当心跳不能维持时，会话连同关联的锁节点都会被开释，锁节点就能够被从新抢占。这里有一个要害的中央，就是如何保障客户端和服务端的同步，在服务端会话过期的时候，客户端也能感知，如下图所示，在客户端和服务端都保护了会话的有效期的工夫，客户端从心跳发送时刻（S0）开始计时，服务端从收到申请（S1）开始计时，这样就能保障客户端会先于服务端过期。用户在创立锁之后，外围工作线程在进行外围操作之前能够判断是否有足够的有效期，同时咱们不再依赖墙上工夫，而是基于零碎时钟来对工夫进行判断，零碎时钟更加准确，且不会向前或者向后挪动（秒级别误差毫秒级，同时在 NTP 跳变的场景，最多会批改时钟的速率）。

图 4 存储场景的应用形式

在分布式锁互斥性上，咱们是不是做到完满了？并非如此，还是存在一种状况下业务基于分布式锁服务的拜访互斥会被毁坏。咱们来看上面的例子：如下图 9 所示，客户端在工夫点 S0 尝试去抢锁，在工夫点 S1 在后端抢锁胜利，因而也产生了一个分布式锁的有效期窗口。在有效期内，工夫点 S2 做了一个拜访存储的操作，很快实现，而后在工夫点 S3 判断锁的有效期仍旧成立，继续执行拜访存储操作，后果这个操作耗时好久，超过了分布式锁的过期工夫，那么可能这个时候，分布式锁曾经被其余客户端抢占胜利，进而呈现两个客户端同时操作同一批数据的可能性，这种可能性是存在的，尽管概率很小。

图 6 越界场景

针对这个场景，具体的应答计划是在操作数据的时候确保有足够的锁有效期窗口，当然如果业务自身提供回滚机制的话，那么计划就更加齐备，该计划也在存储产品应用分布式锁的过程中被采纳。
还有一个更佳的计划，即，存储系统自身引入 IO Fence 能力。这里就不得不提 Martin Kleppmann 和 redis 的作者 antirez 之间的探讨了，redis 为了避免异步复制导致的锁失落的问题，引入 redlock，该计划引入了多数派的机制，须要取得多数派的锁，最大水平的保障了可用性和正确性，但依然有两个问题：
• 墙上工夫的不牢靠（NTP 工夫）
• 异构零碎的无奈做到严格正确性
墙上工夫能够通过非墙上工夫 MonoticTime 来解决（redis 目前依然依赖墙上工夫），然而异构零碎的只有一个零碎并没有方法保障完全正确，如下图 10 所示，Client1 获取了锁，在操作数据的时候产生了 GC，在 GC 实现时候失落了锁的所有权，造成了数据不统一。

图 7 异构零碎无奈做到齐全正确性

因而须要两个零碎同时合作来实现一个完全正确的互斥拜访，在存储系统引入 IO Fence 能力，如下图 11 所示，全局锁服务提供全局自增的 token，Client1 拿到锁返回的 token 是 33，并带入存储系统，产生 GC，当 Client2 抢锁胜利返回 34，带入存储系统，存储系统会回绝 token 较小的申请，那么通过了长时间 full gc 从新复原后的 Client 1 再次写入数据的时候，因为存储层记录的 Token 曾经更新，携带 token 值为 33 的申请将被间接回绝，从而达到了数据保护的成果（chubby 的论文中有讲述，也是 Martin Kleppmann 提出的解决方案）。

图 8 引入 IO Fence 能力

这与阿里云分布式存储平台盘古的设计思路不约而同，盘古反对了相似 IO Fence 的写爱护能力，引入 Inline File 的文件类型，配合 Seal File 操作，这就有着相似 IO Fence 的写爱护能力，首先，SealFile 操作用来敞开曾经关上的 cs 下面的文件，避免旧的 Owner 持续写数据；其次，InlineFile 能够避免旧的 Owner 关上新的文件。这两个性能事实上也是提供了存储系统中的 Token 反对。

4.2 可用性
存储分布式锁通过继续心跳来保障锁的健壮性，让用户不必投入很多精力关注可用性，但也有可能异样的用户过程继续占据锁。针对该场景，为了保障锁最终能够被调度，提供了能够平安开释锁的会话加黑机制。
当用户须要将产生假死的过程持有的锁开释时，能够通过查问会话信息，并将会话加黑，尔后，心跳将不能失常保护，最终导致会话过期，锁节点被平安开释。这里咱们不是强制删除锁，而是选用禁用心跳的起因如下:

1. 删除锁操作自身不平安，如果锁曾经被其他人失常抢占，此时删锁申请会产生误删除。
   b. 删除锁后，持有锁的人会话仍然失常，它依然认为本人持有锁，会突破锁的互斥性准则。

4.3 切换效率
当过程持有的锁须要被从新调度时，持有者能够被动删除锁节点，但当持有者产生异样(如过程重启，机器宕机等)，新的过程要从新抢占，就须要期待原先的会话过期后，才有机会抢占胜利。默认状况下，分布式锁应用的会话生命期为数十秒，当持有锁的过程意外退出后(未被动开释锁)，最长须要通过很长时间锁节点才能够被再次抢占。

图 5 客户端和服务各自保护过期工夫

要晋升切换精度，实质上要压缩会话生命周期，同时也意味着更快的心跳频率，对后端更大的拜访压力。咱们通过对进行优化，使得会话周期能够进一步压缩。
同时联合具体的业务场景，例如守护过程发现锁持有过程挂掉的场景，提供锁的 CAS 开释操作，使得过程能够零期待进行抢锁。比方利用在锁节点中寄存过程的惟一标识，强制开释曾经不再应用的锁，并从新争抢，该形式能够彻底防止过程降级或意外重启后抢锁须要的等待时间。

5 结语

阿里云存储提供了残缺的分布式锁解决方案，通过了阿里云泛滥云产品贵重的业务场景中长期锻炼，稳固高牢靠，且提供了多种语言的 SDK 抉择，甚至是 RESTful 集成计划。
分布式锁提供了分布式环境下共享资源的互斥拜访，业务或者依赖分布式锁谋求效率晋升，或者依赖分布式锁谋求拜访的相对互斥。同时，在接入分布式锁服务过程中，要思考接入老本、服务可靠性、分布式锁切换精度以及正确性等问题，正确和正当的应用分布式锁，是须要继续思考并予以优化的。

原文链接
本文为阿里云原创内容，未经容许不得转载。