什么是分布式锁？-原创手记-慕课网

一、为什么要使用分布式锁？

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

二、什么是分布式锁？

分布式锁其实可以理解为：控制分布式系统有序的去对共享资源进行操作，通过互斥来保持一致性。举个不太恰当的例子：假设共享的资源就是一个房子，里面有各种书，分布式系统就是要进屋看书的人，分布式锁就是保证这个房子只有一个门并且一次只有一个人可以进，而且门只有一把钥匙。然后许多人要去看书，可以，排队，第一个人拿着钥匙把门打开进屋看书并且把门锁上，然后第二个人没有钥匙，那就等着，等第一个出来，然后你在拿着钥匙进去，然后就是以此类推

1.线程锁

主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如synchronized是共享对象头，显示锁Lock是共享某个变量(state)。

2.进程锁

为了控制同一操作系统中多个进程访问某个共享资源，因为进程具有独立性，各个进程无法访问其他进程的资源，因此无法通过synchronized等线程锁实现进程锁。

3.分布式锁

当多个进程不在同一个系统中，用分布式锁控制多个进程对资源的访问。

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

分布式锁应该具备以下条件：

1、在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行；
2、高可用的获取锁与释放锁；
3、高性能的获取锁与释放锁；
4、具备可重入特性；
5、具备锁失效机制，防止死锁；
6、具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败。

为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件：

　　1、互斥性：任意时刻，只能有一个客户端获取锁，不能同时有两个客户端获取到锁。

　　2、安全性：锁只能被持有该锁的客户端删除，不能由其它客户端删除。

　　3、死锁：获取锁的客户端因为某些原因(如down机等)而未能释放锁，其它客户端再也无法获取到该锁。

　　4、容错：当部分节点(redis节点等)down机时，客户端仍然能够获取锁和释放锁。

四、分布式锁实现原理

（1）互斥性：保证同一时间只有一个客户端可以拿到锁，也就是可以对共享资源进行操作

（2）安全性：只有加锁的服务才能有解锁权限，也就是不能让a加的锁，bcd都可以解锁，如果都能解锁那分布式锁就没啥意义了

可能出现的情况就是a去查询发现持有锁，就在准备解锁，这时候忽然a持有的锁过期了，然后b去获得锁，因为a锁过期，b拿到锁，这时候a继续执行第二步进行解锁如果不加校验，就将b持有的锁就给删除了

（3）避免死锁：出现死锁就会导致后续的任何服务都拿不到锁,不能再对共享资源进行任何操作了

（4）保证加锁与解锁操作是原子性操作

这个其实属于是实现分布式锁的问题，假设a用redis实现分布式锁

假设加锁操作，操作步骤分为两步：

1，设置key set（key，value）2，给key设置过期时间

假设现在a刚实现set后，程序崩了就导致了没给key设置过期时间就导致key一直存在就发生了死锁

五、分布式锁实现的核心要素是什么？

1. 加锁：要保证同一时间只有一个客户端可以拿到锁，得到锁之后开始执行相关业务。

2. 解锁：在业务执行完毕后，须及时释放锁，以便其他线程可以进入。

3. 锁超时：如果一个得到锁的线程在执行任务的过程中挂掉，来不及显式地释放锁，这块资源将会永远被锁住（死锁），别的线程再也别想进来。所以需要设置一个超时时间，以保证即使没有被显式释放，这把锁也要在一定时间后自动释放，避免死锁。

六、分布式锁的实现方式有哪些？

目前几乎很多大型网站及应用都是分布式部署的，分布式场景中的数据一致性问题一直是一个比较重要的话题。分布式的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）想要执行某个方法，就调用这个方法向数据表method_lock中插入数据：

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

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

（3）成功插入则表示获取到锁，插入失败则表示获取锁失败；插入成功后，就好继续方法体的内容，执行完成后删除对应的行数据释放锁：

delete from method_lock where method_name ='methodName';

存在的缺点：

●这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。

●这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。

●这把锁只能是非阻塞的，因为数据的insert操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。

●这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。

●这把锁是非公平锁，所有等待锁的线程凭运气去争夺锁。

以上这种方法只是采用数据库表实现分布式锁的一种方法，还有很多其他方法。

使用基于数据库表实现分布式锁的一些问题及优化：

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

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

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

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

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

●基于数据库排它锁实现分布式锁

利用我们的创建method_lock表，通过数据库的排他锁来实现分布式锁。基于MySql的InnoDB引擎，可以使用以下方法来实现加锁操作：

"select * from methodLock where method_name= '" + methodName + "' for update";  //悲观锁

伪代码：

public boolean lock(){
     connection.setAutoCommit(false)
     while(true){
         try{
             result = select * from methodLock where method_name=xxx for update;
             if(result==null){
                 return true;
             }
         }catch(Exception e){
 
         }
         sleep(1000);
     }
     return false;
 }

在查询语句后面增加for update，数据库会在查询过程中给数据库表增加排他锁。当某条记录被加上排他锁之后，其他线程无法再在该行记录上增加排他锁。

我们可以认为获得排它锁的线程即可获得分布式锁，当获取到锁之后，可以执行方法的业务逻辑，执行完方法之后，再通过以下方法解锁：

伪代码：

public void unlock(){
     connection.commit();
 }

通过connection.commit();操作来释放锁。

这种方法可以有效的解决上面提到的无法释放锁和阻塞锁的问题。

阻塞锁？ for update语句会在执行成功后立即返回，在执行失败时一直处于阻塞状态，直到成功。

锁定之后服务宕机，无法释放？使用这种方式，服务宕机之后数据库会自己把锁释放掉。

但是还是无法直接解决数据库单点、可重入和公平锁的问题。

总结一下使用数据库来实现分布式锁的方式，这两种方式都是依赖数据库的一张表，一种是通过表中的记录的存在情况确定当前是否有锁存在，另外一种是通过数据库的排他锁来实现分布式锁。

数据库实现分布式锁的优点：直接借助数据库，容易理解。

数据库实现分布式锁的缺点：

会有各种各样的问题，在解决问题的过程中会使整个方案变得越来越复杂。

操作数据库需要一定的开销，性能问题需要考虑。

二、基于缓存实现分布式锁

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

（1）Redis有很高的性能；
（2）Redis命令对此支持较好，实现起来比较方便

2、使用命令介绍：

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

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

（3）释放锁：
del key：删除key

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

除此之外，我们还可以使用set key value NX EX max-lock-time 实现加锁，并且使用 EVAL 命令执行lua脚本实现解锁。

EX seconds ：将键的过期时间设置为 seconds 秒。执行 SET key value EX seconds 的效果等同于执行 SETEX key seconds value 。

PX milliseconds ：将键的过期时间设置为 milliseconds 毫秒。执行 SET key value PX milliseconds 的效果等同于执行 PSETEX key milliseconds value 。

NX ：只在键不存在时，才对键进行设置操作。执行 SET key value NX 的效果等同于执行 SETNX key value 。

XX ：只在键已经存在时，才对键进行设置操作。

3、实现思想：

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

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

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

实例代码：

import redis.clients.jedis.Jedis;
import redis.clients.jedis.params.SetParams;

import java.util.Collections;

/**
 * @ClassName: RedisTool2
 * @Author: liuhefei
 * @Description: Redis实现分布式锁
 * @Date: 2020/6/9 17:57
 */
public class RedisTool2 {

    private static Jedis jedis = new Jedis("127.0.0.1",6379);

    private static final String LOCK_SUCCESS = "OK";

    private static final String SET_IF_NOT_EXIST = "NX";

    private static final String SET_WITH_EXPIRE_TIME = "PX";

    private static final Long RELEASE_SUCCESS = 1L;


    /**
     * EX seconds ： 将键的过期时间设置为 seconds 秒。 执行 SET key value EX seconds 的效果等同于执行 SETEX key seconds value 。
     *
     * PX milliseconds ： 将键的过期时间设置为 milliseconds 毫秒。 执行 SET key value PX milliseconds 的效果等同于执行 PSETEX key milliseconds value 。
     *
     * NX ： 只在键不存在时， 才对键进行设置操作。 执行 SET key value NX 的效果等同于执行 SETNX key value 。
     *
     * XX ： 只在键已经存在时， 才对键进行设置操作。
     */

    /**
 　　* 尝试获取分布式锁
 　　* @param lockKey 锁
 　　* @param requestId 请求标识
 　　* @param expireTime 超期时间(过期时间) 需要根据实际的业务场景确定
 　　* @return 是否获取成功
 　　*/
    public static boolean tryGetDistributedLock(String lockKey, String requestId, int expireTime) {
        SetParams params = new SetParams();
        String result = jedis.set(lockKey, requestId, params.nx().ex(expireTime));
        if (LOCK_SUCCESS.equals(result)) {
             return true;
        }
        return false;
    }


    /**
     * 尝试获取分布式锁
     * @param lockKey 锁
     * @param requestId 请求标识
     * @param expireTime 超期时间（过期时间）需要根据实际的业务场景确定
     * @return 是否获取成功
     */
    public static boolean tryGetDistributedLock1(String lockKey, String requestId, int expireTime){
        //只在键 key 不存在的情况下， 将键 key 的值设置为 value 。若键 key 已经存在， 则 SETNX 命令不做任何动作。设置成功返回1，失败返回0
        long code = jedis.setnx(lockKey, requestId);   //保证加锁的原子操作
        //通过timeOut设置过期时间保证不会出现死锁【避免死锁】
        jedis.expire(lockKey, expireTime);   //设置键的过期时间
        if(code == 1){
            return true;
        }
        return false;
    }

    /**
     * 解锁操作
     * @param key 锁标识
     * @param value 客户端标识
     * @return
     */

    public static Boolean unLock(String key,String value){

        //luaScript 这个字符串是个lua脚本，代表的意思是如果根据key拿到的value跟传入的value相同就执行del，否则就返回0【保证安全性】
        String luaScript = "if redis.call(\"get\",KEYS[1]) == ARGV[1] then return redis.call(\"del\",KEYS[1]) else  return 0 end";

        //jedis.eval(String,list,list);这个命令就是去执行lua脚本，KEYS的集合就是第二个参数，ARGV的集合就是第三参数【保证解锁的原子操作】
        Object var2 = jedis.eval(luaScript, Collections.singletonList(key), Collections.singletonList(value));

        if (RELEASE_SUCCESS == var2) {
            return true;
        }
        return false;
    }

    /**
     * 解锁操作
     * @param key  锁标识
     * @param value  客户端标识
     * @return
     */
    public static Boolean unLock1(String key, String value){
        //key就是redis的key值作为锁的标识，value在这里作为客户端的标识，只有key-value都比配才有删除锁的权利【保证安全性】
        String oldValue = jedis.get(key);
        long delCount = 0;  //被删除的key的数量
        if(oldValue.equals(value)){
            delCount = jedis.del(key);
        }
        if(delCount > 0){  //被删除的key的数量大于0，表示删除成功
            return true;
        }
        return false;
    }


    /**
     * 重试机制：
     * 如果在业务中去拿锁如果没有拿到是应该阻塞着一直等待还是直接返回，这个问题其实可以写一个重试机制，
     * 根据重试次数和重试时间做一个循环去拿锁，当然这个重试的次数和时间设多少合适，是需要根据自身业务去衡量的
     * @param key 锁标识
     * @param value 客户端标识
     * @param timeOut 过期时间
     * @param retry 重试次数
     * @param sleepTime 重试间隔时间
     * @return
     */
    public Boolean lockRetry(String key,String value,int timeOut,Integer retry,Long sleepTime){
        Boolean flag = false;
        try {
            for (int i=0;i<retry;i++){
                flag = tryGetDistributedLock(key,value,timeOut);
                if(flag){
                    break;
                }
                Thread.sleep(sleepTime);
            }
        }catch (Exception e){
            e.printStackTrace();
        }
        return flag;
    }

}

可能存在的问题及优化：

1、单点问题。解决办法：采用多台redis集群部署。

2、这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在redis中，其他线程无法再获得到锁。解决办法：redis的setExpire方法支持传入失效时间，到达时间之后数据会自动删除。

3、这把锁只能是非阻塞的，无论成功还是失败都直接返回。解决办法：采用while重复执行。

4、这把锁是非重入的，一个线程获得锁之后，在释放锁之前，无法再次获得该锁，因为使用到的key在redis中已经存在。无法再执行setNX操作。解决办法：在一个线程获取到锁之后，把当前主机信息和线程信息保存起来，下次再获取之前先检查自己是不是当前锁的拥有者。

5、这把锁是非公平的，所有等待的线程同时去发起setNX操作，运气好的线程能获取锁。解决办法：在线程获取锁之前先把所有等待的线程放入一个队列中，然后按先进先出原则获取锁。

三、基于zookeeper实现分布式锁

基于zookeeper临时有序节点可以实现的分布式锁

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

Zookeeper的数据存储结构就像一棵树，这棵树由节点组成，这种节点叫做Znode。

Znode分为四种类型：

1.持久节点（PERSISTENT）

默认的节点类型。创建节点的客户端与zookeeper断开连接后，该节点依旧存在。

2.持久节点顺序节点（PERSISTENT_SEQUENTIAL）

所谓顺序节点，就是在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号：

3.临时节点（EPHEMERAL）

和持久节点相反，当创建节点的客户端与zookeeper断开连接后，临时节点会被删除：

4.临时顺序节点（EPHEMERAL_SEQUENTIAL）

顾名思义，临时顺序节点结合和临时节点和顺序节点的特点：在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号；当创建节点的客户端与zookeeper断开连接后，临时节点会被删除。

基于ZooKeeper实现分布式锁的步骤如下：
（1）创建一个目录mylock；
（2）线程A想获取锁就在mylock目录下创建临时顺序节点；
（3）获取mylock目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁；
（4）线程B获取所有节点，判断自己不是最小节点，设置监听比自己次小的节点；
（5）线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是不是最小的节点，如果是则获得锁。

原文链接：https://www.cnblogs.com/liuqingzheng/p/11080501.html

大致思想即为：每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。

原文链接：https://blog.csdn.net/u010963948/article/details/79006572

使用zookeeper能解决的分布式问题：

锁无法释放？使用Zookeeper可以有效的解决锁无法释放的问题，因为在创建锁的时候，客户端会在ZK中创建一个临时节点，一旦客户端获取到锁之后突然挂掉（Session连接断开），那么这个临时节点就会自动删除掉。其他客户端就可以再次获得锁。

非阻塞锁？使用Zookeeper可以实现阻塞的锁，客户端可以通过在ZK中创建顺序节点，并且在节点上绑定监听器，一旦节点有变化，Zookeeper会通知客户端，客户端可以检查自己创建的节点是不是当前所有节点中序号最小的，如果是，那么自己就获取到锁，便可以执行业务逻辑了。

不可重入？使用Zookeeper也可以有效的解决不可重入的问题，客户端在创建节点的时候，把当前客户端的主机信息和线程信息直接写入到节点中，下次想要获取锁的时候和当前最小的节点中的数据比对一下就可以了。如果和自己的信息一样，那么自己直接获取到锁，如果不一样就再创建一个临时的顺序节点，参与排队。

单点问题？使用Zookeeper可以有效的解决单点问题，ZK是集群部署的，只要集群中有半数以上的机器存活，就可以对外提供服务。

公平问题？使用Zookeeper可以解决公平锁问题，客户端在ZK中创建的临时节点是有序的，每次锁被释放时，ZK可以通知最小节点来获取锁，保证了公平。

Zookeeper数据同步问题：

Zookeeper是一个保证了弱一致性即最终一致性的分布式组件。

Zookeeper采用称为Quorum Based Protocol的数据同步协议。假如Zookeeper集群有N台Zookeeper服务器(N通常取奇数，3台能够满足数据可靠性同时有很高读写性能，5台在数据可靠性和读写性能方面平衡最好)，那么用户的一个写操作，首先同步到N/2 + 1台服务器上，然后返回给用户，提示用户写成功。基于Quorum Based Protocol的数据同步协议决定了Zookeeper能够支持什么强度的一致性。

在分布式环境下，满足强一致性的数据储存基本不存在，它要求在更新一个节点的数据，需要同步更新所有的节点。这种同步策略出现在主从同步复制的数据库中。但是这种同步策略，对写性能的影响太大而很少见于实践。因为Zookeeper是同步写N/2+1个节点，还有N/2个节点没有同步更新，所以Zookeeper不是强一致性的。

用户的数据更新操作，不保证后续的读操作能够读到更新后的值，但是最终会呈现一致性。牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可。

推荐一个Apache的开源库Curator（https://github.com/apache/curator/），它是一个ZooKeeper客户端，Curator提供的InterProcessMutex是分布式锁的实现，acquire方法用于获取锁，release方法用于释放锁。

Zookeeper实现分布式的优缺点：
优点：具备高可用、可重入、阻塞锁特性，可解决失效死锁问题。

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

三种方式的对比：

从理解的难易程度角度（从低到高）

数据库 > 缓存 > Zookeeper

从实现的复杂性角度（从低到高）

Zookeeper >= 缓存 > 数据库

从性能角度（从高到低）

缓存 > Zookeeper >= 数据库

从可靠性角度（从高到低）

Zookeeper > 缓存 > 数据库

参考：https://blog.csdn.net/wuzhiwei549/article/details/80692278

https://blog.csdn.net/qq_40722827/article/details/102993655

https://blog.csdn.net/u010963948/article/details/79006572

https://www.cnblogs.com/liuqingzheng/p/11080501.html