数据库分布式锁？分布式锁是什么

各位老铁们好，相信很多人对数据库分布式锁都不是特别的了解，因此呢，今天就来为大家分享下关于数据库分布式锁以及分布式锁是什么的问题知识，还望可以帮助大家，解决大家的一些困惑，下面一起来看看吧！

高并发没锁可不行,三种分布式锁详解

Java中的锁主要包括synchronized锁和JUC包中的锁，这些锁都是针对单个JVM实例上的锁，对于分布式环境如果我们需要加锁就显得无能为力。在单个JVM实例上，锁的竞争者通常是一些不同的线程，而在分布式环境中，锁的竞争者通常是一些不同的线程或者进程。如何实现在分布式环境中对一个对象进行加锁呢？答案就是分布式锁。

目前分布式锁的实现方案主要包括三种：

基于数据库实现分布式锁主要是利用数据库的唯一索引来实现，唯一索引天然具有排他性，这刚好符合我们对锁的要求：同一时刻只能允许一个竞争者获取锁。加锁时我们在数据库中插入一条锁记录，利用业务id进行防重。当第一个竞争者加锁成功后，第二个竞争者再来加锁就会抛出唯一索引冲突，如果抛出这个异常，我们就判定当前竞争者加锁失败。防重业务id需要我们自己来定义，例如我们的锁对象是一个方法，则我们的业务防重id就是这个方法的名字，如果锁定的对象是一个类，则业务防重id就是这个类名。

基于缓存实现分布式锁：理论上来说使用缓存来实现分布式锁的效率最高，加锁速度最快，因为Redis几乎都是纯内存操作，而基于数据库的方案和基于Zookeeper的方案都会涉及到磁盘文件IO，效率相对低下。一般使用Redis来实现分布式锁都是利用Redis的 SETNX key value这个命令，只有当key不存在时才会执行成功，如果key已经存在则命令执行失败。

基于Zookeeper：Zookeeper一般用作配置中心，其实现分布式锁的原理和Redis类似，我们在Zookeeper中创建瞬时节点，利用节点不能重复创建的特性来保证排他性。

在实现分布式锁的时候我们需要考虑一些问题，例如：分布式锁是否可重入，分布式锁的释放时机，分布式锁服务端是否有单点问题等。

上面已经分析了基于数据库实现分布式锁的基本原理：通过唯一索引保持排他性，加锁时插入一条记录，解锁是删除这条记录。下面我们就简要实现一下基于数据库的分布式锁。

id字段是数据库的自增id，unique_mutex字段就是我们的防重id，也就是加锁的对象，此对象唯一。在这张表上我们加了一个唯一索引，保证unique_mutex唯一性。holder_id代表竞争到锁的持有者id。

如果当前sql执行成功代表加锁成功，如果抛出唯一索引异常(DuplicatedKeyException)则代表加锁失败，当前锁已经被其他竞争者获取。

解锁很简单，直接删除此条记录即可。

是否可重入：就以上的方案来说，我们实现的分布式锁是不可重入的，即是是同一个竞争者，在获取锁后未释放锁之前再来加锁，一样会加锁失败，因此是不可重入的。解决不可重入问题也很简单：加锁时判断记录中是否存在unique_mutex的记录，如果存在且holder_id和当前竞争者id相同，则加锁成功。这样就可以解决不可重入问题。

锁释放时机：设想如果一个竞争者获取锁时候，进程挂了，此时distributed_lock表中的这条记录就会一直存在，其他竞争者无法加锁。为了解决这个问题，每次加锁之前我们先判断已经存在的记录的创建时间和当前系统时间之间的差是否已经超过超时时间，如果已经超过则先删除这条记录，再插入新的记录。另外在解锁时，必须是锁的持有者来解锁，其他竞争者无法解锁。这点可以通过holder_id字段来判定。

数据库单点问题：单个数据库容易产生单点问题：如果数据库挂了，我们的锁服务就挂了。对于这个问题，可以考虑实现数据库的高可用方案，例如MySQL的MHA高可用解决方案。

使用Jedis来和Redis通信。

可以看到，我们加锁就一行代码：

jedis.set(String key, String value, String nxxx, String expx, int time);

这个set()方法一共五个形参：

第一个为key,我们使用key来当锁，因为key是唯一的。

第二个为value，这里写的是锁竞争者的id，在解锁时，我们需要判断当前解锁的竞争者id是否为锁持有者。

第三个为nxxx，这个参数我们填的是NX，意思是SET IF NOT EXIST，即当key不存在时，我们进行set操作；若key已经存在，则不做任何操作。

第四个为expx，这个参数我们传的是PX，意思是我们要给这个key加一个过期时间的设置，具体时间由第五个参数决定；

第五个参数为time，与第四个参数相呼应，代表key的过期时间。

总的来说，执行上面的set()方法就只会导致两种结果：1.当前没有锁（key不存在）,那么久进行加锁操作，并对锁设置一个有效期，同时value表示加锁的客户端。2.已经有锁存在，不做任何操作。

上述解锁请求中， SET_IF_NOT_EXIST(不存在则执行)保证了加锁请求的排他性，缓存超时机制保证了即使一个竞争者加锁之后挂了，也不会产生死锁问题：超时之后其他竞争者依然可以获取锁。通过设置value为竞争者的id，保证了只有锁的持有者才能来解锁，否则任何竞争者都能解锁，那岂不是乱套了。

解锁的步骤：

注意到这里解锁其实是分为2个步骤，涉及到解锁操作的一个原子性操作问题。这也是为什么我们解锁的时候用Lua脚本来实现，因为Lua脚本可以保证操作的原子性。那么这里为什么需要保证这两个步骤的操作是原子操作呢？

设想：假设当前锁的持有者是竞争者1，竞争者1来解锁，成功执行第1步，判断自己就是锁持有者，这是还未执行第2步。这是锁过期了，然后竞争者2对这个key进行了加锁。加锁完成后，竞争者1又来执行第2步，此时错误产生了：竞争者1解锁了不属于自己持有的锁。可能会有人问为什么竞争者1执行完第1步之后突然停止了呢？这个问题其实很好回答，例如竞争者1所在的JVM发生了GC停顿，导致竞争者1的线程停顿。这样的情况发生的概率很低，但是请记住即使只有万分之一的概率，在线上环境中完全可能发生。因此必须保证这两个步骤的操作是原子操作。

是否可重入：以上实现的锁是不可重入的，如果需要实现可重入，在 SET_IF_NOT_EXIST之后，再判断key对应的value是否为当前竞争者id，如果是返回加锁成功，否则失败。

锁释放时机：加锁时我们设置了key的超时，当超时后，如果还未解锁，则自动删除key达到解锁的目的。如果一个竞争者获取锁之后挂了，我们的锁服务最多也就在超时时间的这段时间之内不可用。

Redis单点问题：如果需要保证锁服务的高可用，可以对Redis做高可用方案：Redis集群+主从切换。目前都有比较成熟的解决方案。

利用Zookeeper创建临时有序节点来实现分布式锁：

其基本思想类似于AQS中的等待队列，将请求排队处理。其流程图如下：

解决不可重入：客户端加锁时将主机和线程信息写入锁中，下一次再来加锁时直接和序列最小的节点对比，如果相同，则加锁成功，锁重入。

锁释放时机：由于我们创建的节点是顺序临时节点，当客户端获取锁成功之后突然session会话断开，ZK会自动删除这个临时节点。

单点问题：ZK是集群部署的，主要一半以上的机器存活，就可以保证服务可用性。

Zookeeper第三方客户端curator中已经实现了基于Zookeeper的分布式锁。利用curator加锁和解锁的代码如下：

分布式锁及其常见实现方式

在分布式系统中，为了保证对数据的修改有最终一致性，通常使用分布式锁或者分布式事务。比如常见的多个系统同时修改商品，既依赖于现有数据也要修改数据，如果没有限制，高并发情况下很可能最终数据是错误的。

与单机锁不同，分布式锁更加复杂，需要考虑网络延迟、服务阻塞等，通常具有如下特点：

利用数据库主键唯一的特性，可以基于唯一主键保证多次操作只有一次成功。在数据库中创建一个表，表中包含方法名等字段，并在方法名字段上创建唯一索引，想要执行某个方法，就使用这个方法名向表中插入数据，成功插入则获取锁，执行完成后删除对应的行数据释放锁。释放锁时，直接删除数据库记录即可。

此方案存在的问题是强依赖数据库，容易形成热点，数据库锁表导致的超时会影响性能，或者数据库宕机会导致服务不可用。并且，数据库本身没有失效机制，如果任务崩溃会导致数据库中的锁不能被释放。数据库插入操作本身没有阻塞机制，故无法实现分布式锁的阻塞等待，任务线程可能需要重复尝试插入。由于唯一主键的存在，持有锁的线程也无法重复获得锁，其他线程竞争锁的过程中也无法根据优先级进行分配。

在数据库中为表增加一个版本号字段，每次操作时判断版本号，只有版本号一致才能进行对应的修改，修改后版本号加 1，通过 CAS的方式进行修改。

此实现会增加数据库操作的次数，高并发情况下可能性能不好。

for update是一种行级锁，又叫排它锁，一旦用户对某个行施加了行级加锁，则该用户可以查询也可以更新被加锁的数据行，其它用户只能查询但不能更新被加锁的数据行。我们可以认为获得排他锁的线程即获得分布式锁，任务执行完成后通过 commit来释放锁。for update语句会在执行成功后立即返回，在执行失败时一直处于阻塞状态，直到成功。

但是 MySQL会对查询进行优化，即便在条件中使用了索引字段，但是否使用索引来检索数据是由 MySQL通过判断不同执行计划的代价来决定的，如果 MySQL认为全表扫效率更高，比如对一些很小的表，它就不会使用索引，这种情况下 InnoDB将使用表锁，而不是行锁。

setnx的含义就是 SET if Not Exists，主要有两个参数 setnx(key, value)。该方法是原子的，如果 key不存在，则设置当前 key成功，返回 1；如果当前 key已经存在，则设置当前 key失败，返回 0。setnx命令不能设置 key的超时时间，只能通过 expire()来设置。

锁的实现步骤：

这个方案如果在第一步 setnx执行成功后，在 expire()命令执行成功前，发生了宕机的现象，那么就依然会出现死锁的问题。

这个方案是对上一个方案的优化版本。

getset()命令主要有两个参数 getset(key，newValue)。该方法是原子的，对 key设置 newValue这个值，并且返回 key原来的旧值。假设 key原来是不存在的，那么首次执行的返回值是 null。

锁的实现步骤：

这个方案在任务处理超时或发生宕机时，无需担心锁超时问题，下次请求可以判断出实际上锁已经超时了。

zookeeper由多个节点构成（单数），采用 zab一致性协议。因此可以将 zk看成一个单点结构，对其修改数据其内部自动将所有节点数据进行修改而后才提供查询服务。

zookeeper数据是目录树的形式，每个目录称为 znode， znode中可存储数据（一般不超过 1M），还可以在其中增加子节点。

子节点有三种类型。

zookeeper提供了 Watch机制，client可以监控每个节点的变化，当产生变化会给 client产生一个事件。

可以利用临时节点与 watch机制实现分布式锁。每个锁占用一个普通节点/lock，当需要获取锁时在/lock目录下创建一个临时节点，创建成功则表示获取锁成功，失败则 watch/lock节点，有删除操作后再去争锁。临时节点好处在于当进程挂掉后锁的节点自动删除不会发生死锁。

缺点在于所有取锁失败的进程都监听父节点，很容易发生羊群效应，即当释放锁后所有等待进程一起来创建节点，并发量很大。

一个可行的优化方案是上锁改为创建临时有序节点，每个上锁的节点均能创建节点成功，只是其序号不同。只有序号最小的可以拥有锁，如果这个节点序号不是最小的则 watch序号比本身小的前一个节点(公平锁)。watch事件到来后，再次判断是否序号最小。取锁成功则执行代码，最后释放锁（删除该节点）。

性能上可能没有缓存服务那么高，因为每次在创建锁和释放锁的过程中，都要动态创建、销毁临时节点来实现锁功能。zookeeper中创建和删除节点只能通过 Leader服务器来执行，然后将数据同步到所有的 Follower机器上。

分布式锁比较复杂，也比较容易发生死锁。目前主流的实现方式包括：

分布式锁及其常见实现方式-程序之心

分布式锁是什么

什么是分布式锁？实现分布式锁的三种方式

在很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。那具体什么是分布式锁，分布式锁应用在哪些业务场景、如何来实现分布式锁呢？

一为什么要使用分布式锁

我们在开发应用的时候，如果需要对某一个共享变量进行多线程同步访问的时候，可以使用我们学到的锁进行处理，并且可以完美的运行，毫无Bug！

注意这是单机应用，后来业务发展，需要做集群，一个应用需要部署到几台机器上然后做负载均衡，大致如下图：

上图可以看到，变量A存在三个服务器内存中（这个变量A主要体现是在一个类中的一个成员变量，是一个有状态的对象），如果不加任何控制的话，变量A同时都会在分配一块内存，三个请求发过来同时对这个变量操作，显然结果是不对的！即使不是同时发过来，三个请求分别操作三个不同内存区域的数据，变量A之间不存在共享，也不具有可见性，处理的结果也是不对的！

如果我们业务中确实存在这个场景的话，我们就需要一种方法解决这个问题！

为了保证一个方法或属性在高并发情况下的同一时间只能被同一个线程执行，在传统单体应用单机部署的情况下，可以使用并发处理相关的功能进行互斥控制。但是，随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的应用并不能提供分布式锁的能力。为了解决这个问题就需要一种跨机器的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

二、分布式锁应该具备哪些条件

在分析分布式锁的三种实现方式之前，先了解一下分布式锁应该具备哪些条件：

1、在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行；

2、高可用的获取锁与释放锁；

3、高性能的获取锁与释放锁；

4、具备可重入特性；

5、具备锁失效机制，防止死锁；

6、具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败。

三、分布式锁的三种实现方式

目前几乎很多大型网站及应用都是分布式部署的，分布式场景中的数据一致性问题一直是一个比较重要的话题。分布式的CAP理论告诉我们“任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两项。”所以，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。

在很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候，我们需要保证一个方法在同一时间内只能被同一个线程执行。

基于数据库实现分布式锁；

基于缓存（Redis等）实现分布式锁；

基于Zookeeper实现分布式锁；

四、基于数据库的实现方式

基于数据库的实现方式的核心思想是：在数据库中创建一个表，表中包含方法名等字段，并在方法名字段上创建唯一索引，想要执行某个方法，就使用这个方法名向表中插入数据，成功插入则获取锁，执行完成后删除对应的行数据释放锁。

（1）创建一个表：

DROP TABLE IF EXISTS `method_lock`;CREATE TABLE `method_lock`(

`id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT'主键',

`method_name` varchar(64) NOT NULL COMMENT'锁定的方法名',

`desc` varchar(255) NOT NULL COMMENT'备注信息',

`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY(`id`), UNIQUE KEY `uidx_method_name`(`method_name`) USING BTREE

) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';

（2）想要执行某个方法，就使用这个方法名向表中插入数据：

INSERT INTO method_lock(method_name, desc) VALUES('methodName','测试的methodName');

因为我们对method_name做了唯一性约束，这里如果有多个请求同时提交到数据库的话，数据库会保证只有一个操作可以成功，那么我们就可以认为操作成功的那个线程获得了该方法的锁，可以执行方法体内容。

（3）成功插入则获取锁，执行完成后删除对应的行数据释放锁：

delete from method_lock where method_name='methodName';

注意：这只是使用基于数据库的一种方法，使用数据库实现分布式锁还有很多其他的玩法！

使用基于数据库的这种实现方式很简单，但是对于分布式锁应该具备的条件来说，它有一些问题需要解决及优化：

1、因为是基于数据库实现的，数据库的可用性和性能将直接影响分布式锁的可用性及性能，所以，数据库需要双机部署、数据同步、主备切换；

2、不具备可重入的特性，因为同一个线程在释放锁之前，行数据一直存在，无法再次成功插入数据，所以，需要在表中新增一列，用于记录当前获取到锁的机器和线程信息，在再次获取锁的时候，先查询表中机器和线程信息是否和当前机器和线程相同，若相同则直接获取锁；

3、没有锁失效机制，因为有可能出现成功插入数据后，服务器宕机了，对应的数据没有被删除，当服务恢复后一直获取不到锁，所以，需要在表中新增一列，用于记录失效时间，并且需要有定时任务清除这些失效的数据；

4、不具备阻塞锁特性，获取不到锁直接返回失败，所以需要优化获取逻辑，循环多次去获取。

5、在实施的过程中会遇到各种不同的问题，为了解决这些问题，实现方式将会越来越复杂；依赖数据库需要一定的资源开销，性能问题需要考虑。

五、基于Redis的实现方式

1、选用Redis实现分布式锁原因：

（1）Redis有很高的性能；

（2）Redis命令对此支持较好，实现起来比较方便

2、使用命令介绍：

（1）SETNX

SETNX key val：当且仅当key不存在时，set一个key为val的字符串，返回1；若key存在，则什么都不做，返回0。

（2）expire

expire key timeout：为key设置一个超时时间，单位为second，超过这个时间锁会自动释放，避免死锁。

（3）delete

delete key：删除key

在使用Redis实现分布式锁的时候，主要就会使用到这三个命令。

3、实现思想：

（1）获取锁的时候，使用setnx加锁，并使用expire命令为锁添加一个超时时间，超过该时间则自动释放锁，锁的value值为一个随机生成的UUID，通过此在释放锁的时候进行判断。

（2）获取锁的时候还设置一个获取的超时时间，若超过这个时间则放弃获取锁。

（3）释放锁的时候，通过UUID判断是不是该锁，若是该锁，则执行delete进行锁释放。

4、分布式锁的简单实现代码：

#连接redis

redis_client= redis.Redis(host="localhost",

port=6379,

password=password,

db=10)

#获取一个锁

lock_name：锁定名称

acquire_time:客户端等待获取锁的时间

time_out:锁的超时时间

def acquire_lock(lock_name, acquire_time=10, time_out=10):

"""获取一个分布式锁"""

identifier= str(uuid.uuid4()) end= time.time()+ acquire_time

lock="string:lock:"+ lock_name while time.time()< end: if redis_client.setnx(lock, identifier):

#给锁设置超时时间,防止进程崩溃导致其他进程无法获取锁

redis_client.expire(lock, time_out) return identifier

elif not redis_client.ttl(lock):

redis_client.expire(lock, time_out)

time.sleep(0.001) return False

#释放一个锁

def release_lock(lock_name, identifier):

"""通用的锁释放函数"""

lock="string:lock:"+ lock_name

pip= redis_client.pipeline(True) while True:

try:

pip.watch(lock)

lock_value= redis_client.get(lock) if not lock_value: return True if lock_value.decode()== identifier:

pip.multi()

pip.delete(lock)

pip.execute() return True

pip.unwatch() break

except redis.excetions.WacthcError:

pass return False

5、测试刚才实现的分布式锁

例子中使用50个线程模拟秒杀一个商品，使用–运算符来实现商品减少，从结果有序性就可以看出是否为加锁状态。

def seckill():

identifier=acquire_lock('resource') print(Thread.getName(),"获得了锁")

release_lock('resource',identifier)for i in range(50):

t= Thread(target=seckill)

t.start()

六、基于ZooKeeper的实现方式

ZooKeeper是一个为分布式应用提供一致性服务的开源组件，它内部是一个分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名。基于ZooKeeper实现分布式锁的步骤如下：

（1）创建一个目录mylock；

（2）线程A想获取锁就在mylock目录下创建临时顺序节点；

（3）获取mylock目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁；

（4）线程B获取所有节点，判断自己不是最小节点，设置监听比自己次小的节点；

（5）线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是不是最小的节点，如果是则获得锁。

这里推荐一个Apache的开源库Curator，它是一个ZooKeeper客户端，Curator提供的InterProcessMutex是分布式锁的实现，acquire方法用于获取锁，release方法用于释放锁。

优点：具备高可用、可重入、阻塞锁特性，可解决失效死锁问题。

缺点：因为需要频繁的创建和删除节点，性能上不如Redis方式。

七、总结

上面的三种实现方式，没有在所有场合都是完美的，所以，应根据不同的应用场景选择最适合的实现方式。

在分布式环境中，对资源进行上锁有时候是很重要的，比如抢购某一资源，这时候使用分布式锁就可以很好地控制资源。

当然，在具体使用中，还需要考虑很多因素，比如超时时间的选取，获取锁时间的选取对并发量都有很大的影响，上述实现的分布式锁也只是一种简单的实现，主要是一种思想。

好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！