单体系统中，在高并发场景下想要访问共享资源的时候，我们需要通过加锁的方式来保证共享资源并发的安全性，确保在同一时刻只有一个线程对共享资源进行 *** 作。相信大家对于Java提供的synchronized关键字以及Lock锁都不陌生，在实际的项目中大家都使用过。如下图所示，在同一个JVM进程中，Thread1获得锁之后，对共享资源进行 *** 作，其他线程未获得锁的线程只能等待Thread1释放后才能进行对应的 *** 作。
但是随着业务的不断发展，原先的单体应用被拆分为多个微服务，每个微服务又会部署多个实例，于是就形成了当下的微服务架构。处理共享资源的请求来自不同的服务实例，也就是在不同的JVM进程中。原先的单体服务中的加锁方式在分布式场景下不能满足共享资源的并发访问要求。因此我们需要一种适用于分布式场景下的共享资源安全的处理机制，此时应对这种问题的分布式锁就应运而生了。
既然JVM进程管不到其他服务实例的线程，那么可以借助于外部组件能力来实现不同服务实例对于共享资源的统一管控，这种能力我们可以称之为分布式锁。因此分布式锁的本质就是在不同服务实例之外建立一种获取锁的机制，形成一种并发互斥能力来确保不同线程对于共享资源的并发安全，从而实现在微服务架构中同一时刻只有一个线程可以对共享资源进行 *** 作。对于分布式锁来说，实际就是需要一个外部的状态存储系统来实现原子化的排他性 *** 作。
通过对于分布式锁的需求分析，总结了如下的分布式锁四大特性，分别是多节点、加锁速度快、排他性以及锁过期实现机制。
分布式锁实现方案 基于数据库的分布式锁实现方案 实现原理通过数据库的方式实现分布式锁的效果，实际就是借助于数据库的唯一性约束特性或者for update来实现。这里以唯一性约束来举个栗子，在电商领域的库存服务负责对商品的库存进行扣减，首先创建一张专门存放锁信息的锁表，那么库存服务在进行库存 *** 作之前，先向数据库中的锁表插入一条锁资源数据。
create table ‘distributed_lock’ ( ‘id’ BIGINT NOT NULL AUTO_INCREMENT, ‘resource_lock_key‘ varchar(64) NOT NULL PRIMARY KEY(‘id’), UNIQUE KEY ‘uk_resource_lock_key‘ (‘resource_lock_key‘) USING BTREE )
大致的交互流程如下：
1、当库存服务进行手机库存扣减的时候，首先先向数据库中的锁表当中插入一条资源锁信息；
2、如果插入成功，则表示库存服务1可以对手机库存进行库存扣减 *** 作；
3、此时库存服务2也要对库存进行 *** 作，于是同样插入数据到锁表中；
4、但是由于锁表设置了唯一性约束，锁信息插入失败，库存服务进行等待；
5、库存服务1执行完库存扣减之后，删除锁表的信息；
6、库存服务2尝试插入资源锁信息，发现可以插入成功，继续执行后续 *** 作。
基于数据库的实现方式，看起来还是比较容易理解的。但是实际上还是有一些问题存在的，我们一起来分析下。
1、性能问题：由于是插入数据数据需要落盘存储，如果平凡进行读写的话会影响数据库性能，另外由于使用唯一键进行判断也会一定程度上影响数据库性能，因此数据库方案适用于并发量不到的简单场景；
2、数据库如果单点部署的话会存在单点故障问题，如果数据库出现故障，可能会导致平台中的业务异常；
3、死锁问题：在上文介绍中，包含了插入数据库的获取锁的步骤，还包含了删除锁信息的释放锁的过程，但是如果库存服务1在加锁之后挂掉了，无法进行锁的释放，而其他服务又无法获取到锁就会造成死锁的问题。当然了我们可以通过一个定时任务去检查锁表中是不是有过时的锁资源。但是这样无疑增加了分布式锁实现的复杂性。
4、不支持可重入：如果想要实现可重入锁，还需要增加主机、线程名等字段来进行标注，通过这几个字段来判断和当前信息是否一致，如果一致则认为已经获取到了锁。
鉴于以上的这些问题，有没有其他的分布式实现方案可以避免上述存在的问题呢？我们再往下来看。
Redis作为一块高性能的数据库中间件，经常被当做缓存在项目中使用。因此通过Redis实现分布式锁，也是比较常见的实现方案。 一样的道理，通过Redis实现分布式锁也需要通过它实现锁的互斥的能力。实际上就是利用了sentnx（set if not exists）命令。同时该命令是否能够设置成功，决定服务是否可以拿到对应的分布式锁。
127.0.0.1:6379> setnx stockLock 10.12.35.12_stockService (integer) 1
如上图所示，大致的加锁以及释放锁的过程其实和数据库的分布式锁方案还是比较类似的。只不过将其中向数据库插入数据的步骤替换成了向Redis获取锁的步骤，由于Redis是基于内存进行 *** 作的，因此性能上比基于数据库的分布式锁方案更好一点。
上述基于Redis的方案的方案在性能上具有优势，我们再来分析下，这个使用命令的方式有没有什么问题。实际上和前面的数据库方案类似，Redis也会有死锁问题，当获取锁之后如果库存服务1挂掉了，库存服务2就获取不到锁了。因此我们要对其进行优化。那么问题的本质是如何让锁可以释放，因此我们需要在设置锁的时候加上过期时间，这样即使库存服务1挂了，无法主动释放锁，那么到了过期时间后锁失效，库存服务2依然可以获取锁，不会再造成死锁问题。
另外还应该注意的是，在我们设置锁的时候，还需要带有自身服务的业务属性，否则容易造成错乱。为什么这么说呢？举个栗子，库存服务在加完锁之后开始执行扣减库存的任务，当扣减库存完成之后，服务挂了，原先需要删除的锁资源，等到过期之后被Redis删除，此时库存服务2可以继续申请锁，如果此时库存服务1恢复了，它并不知道锁资源已经释放，起来后立马删除了库存服务2加的锁，那么此时就会出现两个问题：
1、库存服务执行完库存扣减之后，回头来进行锁资源释放的时候，发现锁实际已经不在了；
2、当库存服务1恢复后发现锁还在，立马删除了该锁，完成了它挂掉之前未完成的工作。但是实际上这个锁是库存服务2加的锁，如果此时库存服务3也要尝试加锁，发现可以加锁成功，和库存服务2一样同样对库存进行 *** 作，那么此时就会出现线程安全问题。
经过上文的分析，这个问题的根源就是在加锁的时候没有具体区分到底是哪个服务加的锁。因此在执行命令的时候，我们需要将带有服务实例关联属性的设置为value，这样在进行锁获取的时候检查下当前锁的持有者是谁，如果不是服务实例自己则不能执行删除 *** 作。
那这样是不是就完美解决问题了呢？实际上还是有问题存在的，有同学会说，怎么这么多问题？实际上这种方案的实现就是在各种不完美的方案中逐渐找到相对完美的方案。
上文提到的获取锁判断是不是自己方服务实例加的锁，再执行删除锁的过程实际并不是原子的。因此还是会出现并发安全问题，这个问题可以通过lua脚本来解决，在lua脚本中实现这个逻辑，而不是在客户端中实现。
但是实际上还是有问题没有解决，比如说我们在加锁的时候会设置过期时间，但是过期时间应该设置多长时间呢？设置短了的话，出现网络超时或者服务还没有执行完业务，锁就失效了。设置长了话，其他服务节点等待获取锁的时间就会变长，降低了服务的性能。
Redisson实际上就是一个封装了Redis *** 作的客户端，实现了对于常见的Redis *** 作的封装。如对于Redis的设置锁的步骤以及删除锁的步骤都进行了封装。在设置锁的 *** 作中，还引入了自动给锁续期的机制，SDK检测到业务未完成，但是锁要到期后，执行定续期。这样并可以动态的调节过期时间，避免锁在业务未完成情况下被释放的问题。
同时还封装了删除锁的时候执行的业务判断后再删除的逻辑，这样我们在使用Redisson *** 作Redis的时候，就和我们使用JDK一样。
为了解决Redis作为分布式锁存在的单点问题，Redis的作者又提出了Redlock的解决方案，该解决方案依赖多个Redis的Master节点，官方推荐使用5个Master节点，他们彼此之间是独立的。大致的交互步骤如下所示：
1、首先获取当前节点的系统时间；
2、客户端尝试向所有的Redis实例顺序地发送加锁的请求（官方推荐Redis集群至少5个实例），在设置锁的过程中，使用相同的key以及随机值value，同时请求的超时时间需要远小于锁的有效时间。这样做的目的是为了防止节点不可用的时候导致请求锁的时候被阻塞，当实例没响应的时候可以快速跳过，向下一个节点继续请求锁。
3、假设Redis集群规模为5，那么如果客户端在大多数实例中（超过3个实例）获得了锁，同时计算了当前的时间减去步骤1中获得的时间，这个事件差如果小于锁的有效时间，那么此时可以认为加锁成功，可以 *** 作执行后续的业务；
4、如果不满足步骤3是条件，那么就表示加锁失败，客户端需要向所有的Redis节点发起锁释放请求。
为什么Redlock要在集群中多个实例上加锁呢？实际目的是通过锁的冗余来实现分布式锁的高容错性。试想一下如果只有一个Redis实例，一旦它挂掉了，客户端就无法进行加锁 *** 作了或者锁信息就会丢失，影响业务功能。通过在集群中多实例中冗余锁信息，即使出现Redis挂了的情况，其他节点中依然存在锁信息，从而提升了分布式锁的可用性。
那么为什么还要计算几所时间呢？由于我们加锁的时候，每个节点都设置了超时时间，如果整个加锁的时间过长，整个过程的累加时间超过了锁的有效时间，那么加锁完成之后就会哦出现锁失效的情况了，因此我们需要确保加锁的事件尽可能的短，这也是为什么加锁请求都有超时时间的原因了，发现超时立马跳到下一个节点，避免单个节点耗时过长。
虽然Redlock看上去是比较完善的分布式解决方案，但是实际上这个方案是比较重的，需要维护一个Redis集群，另外过程中依赖系统时间，但是如果出现了时间跳变，那么对于整个分布式锁都有非常大的影响。
基于Zookeeper的分布式锁实现方案 实现原理Zookeeper是一个分布式的应用协调服务中间件，通过它也可以实现分布式锁的效果，这里介绍的是基于临时有序的ZNode分布式锁实现方案。在介绍方案之前，先补充下Zookeeper中和分布式锁息息相关的特性。
我们来看下Zookeeper的数据结构，实际上它是一种树形模型，类似于Linux的文件系统。Zookeeper使用类似于文件目录的层级目录数据结构来组织自身的数据存储节点，这些节点就被称作为ZNode，每个节点都用一个以斜杠（/）分隔的路径来表示，而且每个节点都有父节点（根节点除外）。另外在Zookeeper中，如果我们使用不同的创建参数，可以创建不同类型的ZNode。
1、持久化ZNode：当createMode为PERSISTENT会创建持久化ZNode，节点存储的数据会永久保存在Zookeeper中，如果createMode为PERSISTENT_SEQUENTIAL，则会创建有序持久化ZNode，和之前的持久化节点不通的是，有序持久化节点的节点名称会附加上全局有序的递增序号；
2、临时ZNode：当createMode为EPHEMERAL时，创建的节点临时节点，在与客户端的session过期后，对应的临时节点也会被删除。当createMode为EPHEMERAL_SEQUENTIAL时创建出来的为有序的临时节点，当session过期之后，节点及其存储的数据也是会被删除的。
通过上述对于节点特性的描述，可以看出来它的全局递增有序以及过期删除的特性与分布式锁实现的原理非常契合。因此通过Zookeeper实现分布式锁的大致可以分为以下几个步骤：
1、首先创建一个持久化节点也就是父节点，这个持久化节点代表着一个分布式锁实例；
2、当有线程想要申请分布式锁的时候，则在该持久化节点下创建临时有序节点；
3、如果此时新建的临时有序节点是该父节点小所有有序节点中序号最小的节点，那么此时就表示申请到了分布式锁；
4、如果新建的临时节点当前不是最小序号的节点，则需要不断检查是否最小，知道最终获取到锁，或者节点超时。实际上这个是通过Zookeeper的watch机制实现的，在当前节点的上一序号的节点设置监听器，检查是否为最小节点的任务可以一直阻塞，直到收到上一节点被删除的时间事件，则唤醒检查事件，检查当前节点是不是最小序号节点。
5、当线程执行完业务之后，可以手动删除该临时节点以便于释放持有的锁。另外即使服务挂掉，由于对应的session失效，对应的临时节点也会被删除，防止出现死锁问题。
和Redisson类似，我们在实际使用Zookeeper作为分布式锁的时候可以用Curator来作为开发SDK，它同样封装了很多实现，包括可重入锁的实现，减轻了使用者的负担。
看上去通过Zookeeper实现分布式锁还是比较好的一种解决方案，但是它是完美的吗？从上面的分布式锁的流程可知，客户端线程想要获取锁就需要创建临时节点，这个时候客户端和Zookeeper之间就会维护一个session，来表示该客户端还在排队等待获取锁。因此这个方案的潜在问题就在于一旦出现网络异常，或者客户端发生STW GC，那么就可能导致session关闭，从而导致临时节点被关闭，此时就会出现原来客户端持有的锁被删除了，如果有另外的客户端过来加锁的话可以成功获取，那么此时就出现并发安全问题了。因此在这种极端条件下，Zookeeper的分布式锁实现方案也不是100%保证安全的。
另外实际上还有基于etcd的分布式锁实现方案，其基本原理和Zookeeper差不多，感兴趣的同学可以再进行了解下。
分布式锁方案到底选哪个？通过上述几种分布式锁方案原理的阐述以及问题分析，每个方案都有自己的长处以及缺点。所以在实际项目落地的时候，我么需要结合实际来进行分布式锁方案的选择。比如如果平台中本身已经有Redis集群了，但是没有Zookeeper集群，那么我们就可以借助于现有的基础实施来落地分布式锁，不需要再去维护一套Zookeeper集群。
另外根据实际的业务场景，如果并发量并不是很高，也可以通过简单的数据库的分布式锁方案来实现。
总结本文首先对从单机时代到分布式场景下的分布式锁的产生的背景进行了分析，通过对分布式锁的本质问题的探究，引出了数据库分布式锁方案、Redis分布式锁方案以及Zookeeper分布式锁方案，并对每一种方案的优点以及不足进行了分析，相信大家可以在落地实现分布式锁的时候可以按照自身的情况选择合适的方案。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）