分布式锁

之前分析了分布式事务及其保证方式，在分布式家族中，自然而然的又想到分布式锁。首先思考几个问题：

 

0、单机环境下的锁有哪些实现方式？单机环境下的锁为何解决不了分布式环境锁相关问题

1、为什么需要分布式锁？

2、分布式事务和分布式锁有关系吗？有什么关系？

3、分布式锁的实现方式有哪些？（哪些方式可以实现分布式锁？）

主要参考文章:

《基于Redis分布式锁的实现》

https://juejin.im/post/5cc165816fb9a03202221dd5#heading-10

 

• 一、锁的基础知识
  • 1、可重入锁
  • 2、读写锁
  • 3、乐观锁、悲观锁
  • 4、可中断锁
  • 5、公平锁、非公平锁
  • 6、数据库中锁的概念
• 二、单机环境下锁的实现方式
  • 1、synchronized关键字
  • 2、volatile关键字
  • 3、Lock类
• 三、分布式环境下锁
  • 1、分布式锁一般面临如下问题：
  • 2、分布式锁的实现方式：
• 四、Redis如何实现分布式锁
  • 4.1 Redis单节点下可用的锁方式
    • 4.1.1 加锁过程
      •  
      • 1、setnx + expire命令 实现分布式锁代码实现（错误的实现方式）
      • 2、使用Lua脚本来保证原子性（包含setnx和expire两条指令）
      • 3、使用 set key value [EX seconds] [PX milliseconds] [NX | XX] 命令 （redis集群环境存在问题）
    • 4.1.2 释放锁过程
    • 4.1.3 这三种加锁方式特点
  • 4.2 Redlock算法 与 Redisson 实现
    • 1、RedLock算法
    • 2、Redisson实现简单的分布式锁
  • 4.3 可重入加锁的判断
    • 1、setnx 是否是可重入的 （不是可重入的）
    • 2、lua脚本是否可重入（不是可重入的）
    • 3、使用 set key value [EX seconds] [PX milliseconds] [NX | XX] 命令 是否可重入（不是可重入的）
    • 4、红锁（Redission锁）（可重入的）
  • 4.4 业务时间大于过期时间
    • 1、setnx  能否保证  业务时间大于过期时间时锁被延迟释放（不能）
    • 2、lua脚本  能否保证  业务时间大于过期时间时锁被延迟释放（不能）
    • 3、使用 set key value [EX seconds] [PX milliseconds] [NX | XX] 命令 能否保证  业务时间大于过期时间时锁被延迟释放（不能）
    • 4、红锁（Redission锁） 能否保证  业务时间大于过期时间时锁被延迟释放（不能）
    • 5、什么方式可以保证 业务时间大于过期时间时 锁被延迟释放
• 五、Mysql中如何实现分布式锁
  • 5.1 创建锁表实现分布式锁
  • 5.2 基于 数据库版本标识 做乐观锁
  • 5.3 基于数据库表做悲观锁
• 六、Zookeeper中实现分布式锁

 

一、锁的基础知识

1、可重入锁

java下的实现方式：java.util.concurrent.locks.ReentrantLock（接口）

可重入是指，任意线程在获取到锁之后能够再次获取该锁，而不会被该锁所阻塞，该特性的实现需要解决两个问题：

1）线程再次获取锁：锁需要去识别获取锁的线程是否是当前占据锁的线程，如果是则再次获取锁成功

2）锁的最终释放：线程重复n次获取了该锁，随后在第n次释放该锁后，其他线程能够获取到该锁。锁的最终释放要求锁对于获取的次数进行计数自增，计数表示当前锁被重复获取的次数，而锁被释放时，计数自减，当计数为0时表示锁已经成功释放。

2、读写锁

读写锁将对一个资源的访问分成了2个锁，如文件，一个读锁和一个写锁。正因为有了读写锁，才使得多个线程之间的读操作不会发生冲突。

java下的实现方式：java.util.concurrent.locks.ReadWriteLock（接口）就是读写锁

实现类：ReentrantReadWriteLock，可以通过readLock()获取读锁，通过writeLock()获取写锁。

3、乐观锁、悲观锁

乐观锁：认为数据一般情况下的操作不会造成冲突，在数据进行更新提交的时候再判断是否有其他线程争用共享数据，没有那就操作就成功了；如果共享数据有争用，产生了冲突，那就在采取其他的补偿措施，比如更新失败

悲观锁：总是认为不去做正确的同步措施就肯定会出现问题，所以先对操作对象加锁在进行操作。

4、可中断锁

可中断锁，即可以中断的锁。在Java中，synchronized就不是可中断锁，而Lock是可中断锁。
如果某一线程A正在执行锁中的代码，另一线程B正在等待获取该锁，可能由于等待时间过长，线程B不想等待了，想先处理其他事情，我们可以让它中断自己或者在别的线程中中断它，这种就是可中断锁。Lock接口中的 lockInterruptibly()方法 就体现了Lock的可中断性。

5、公平锁、非公平锁

公平锁即尽量以请求锁的顺序来获取锁。同时有多个线程在等待一个锁，当这个锁被释放时，等待时间最久的线程（最先请求的线程）会获得该锁，这种就是公平锁。

synchronized是非公平锁，它无法保证等待的线程获取锁的顺序。对于ReentrantLock和ReentrantReadWriteLock，默认情况下是非公平锁，但是可以设置为公平锁。

6、数据库中锁的概念

数据库中锁有很多不同的划分方式：

数据库锁的范围	行锁、表锁	备注
数据库锁的属性	共享锁（读锁、S锁）、排他锁（写锁、X锁）
数据库锁的模式	乐观锁、悲观锁
数据库锁的算法	临间锁、间隙锁、记录锁	不明白
数据库锁的状态	意向共享锁、意向拍他锁	不明白

二、单机环境下锁的实现方式

1、synchronized关键字

这是java中最基本的互斥同步的手段。synchronized关键字经过编译之后，会在同步块的前后形成monitorenter和monitorexit两个字节码指令，这两个字节码指令都需要一个reference类型的参数来指明要锁定和解锁的对象。如果Java程序中的synchronized明确指定了对象的参数，那就是这个对象的reference；如果没有明确指定，那就根据synchronized修饰的是实例方法还是类方法，去取对应的对象实例或者是Class对象作为所对象。

synchronized实现的同步互斥是一种阻塞同步，属于一种悲观的并发策略。

synchronized 是在 JVM 层面上实现的，synchronized在锁定时如果方法块抛出异常，JVM 会自动将锁释放掉，不会因为出了异常没有释放锁造成线程死锁。

2、volatile关键字

volatile在多线程并发编程中synchronized和Volatile都扮演着重要的角色，Volatile是轻量级的synchronized，它在多处理器开发中保证了共享变量的“可见性”。可见性的意思是当一个线程修改一个共享变量时，另外一个线程能读到这个修改的值。

关于synchronized和volatile的底层实现，专门整理了一个wiki.

 

3、Lock类

Lock的锁定是通过代码实现的，出现异常时必须在 finally 将锁释放掉，否则将会引起死锁。

在资源竞争不是很激烈的情况下，偶尔会有同步的情形下，synchronized是很合适的。原因在于，编译程序通常会尽可能的进行优化synchronize，另外可读性非常好。

Lock可以提高多个线程进行读操作的效率。（可以通过readwritelock实现读写分离）。性能上来说，在资源竞争不激烈的情形下，Lock性能稍微比synchronized差点（编译程序通常会尽可能的进行优化synchronized）。但是当同步非常激烈的时候，synchronized的性能一下子能下降好几十倍。而ReentrantLock确还能维持常态。

三、分布式环境下锁

1、分布式锁一般面临如下问题：

互斥性 ： 同一时刻只能有一个线程拿到锁

锁超时 ： 不能无限制时间的拿到一个锁，防止死锁

支持阻塞和非阻塞 ： 能够及时从阻塞状态被唤醒

可重入性 ： 同一个服务节点上的同一个线程如果获取了一个锁后能够再次获取该锁

高性能、高可用 ：加锁和解锁需要高效，同时也需要保证高可用，防止分布式锁失效

2、分布式锁的实现方式：

1. 数据库乐观锁；2. 基于Redis的分布式锁；3. 基于ZooKeeper的分布式锁。

思考：为什么加锁（并发安全性），redis如何加锁（setnx）, 系统抛出异常如何保证锁的正常释放（finally）, 宕机如何保证锁的正常释放（超时设置），如何保证A线程不会释放掉B线程的锁（保证线程拿到的锁有该线程的标识），如何保证线程内逻辑在超时时间内完成（延长锁超时时间），一个线程逻辑内多次加锁（可重入锁）。如果解决了所有这些是否就没有问题（No, CAP）， 如何基于Redis实现保证分布式的一致性（红锁)

四、Redis如何实现分布式锁

Redis实现分布式锁，主要借助了SETNX命令(set if not exits), setnx key value .    将key设置为value，当键不存在时，才能成功，若键存在，什么也不做，成功返回1，失败返回0 .

分布式锁还需要超时机制，所以我们利用expire命令来设置，setnx + expire命令 是实现分布式锁的主要命令。

4.1 Redis单节点下可用的锁方式

这里说的单节点指的是没有主从的意思，不是说集群只有一个redis服务节点。（But, 既然都存在多个多个服务节点了，肯定是要做主从的？另外我们自己的业务中一般就是单节点而已，因为我们的业务不够复杂）

4.1.1 加锁过程

对于Java用户而言，我们经常使用Jedis，Jedis是Redis的Java客户端。注意，使用Jedis， 需要加入依赖：

redis.clients     jedis     2.9.0

1、setnx + expire命令 实现分布式锁代码实现（错误的实现方式）

import redis.clients.jedis.Jedis;

public class Goods {

    private Jedis jedis = new Jedis();

    public boolean tryLock(String key, String requset, int timeout) {

        Long result = jedis.setnx(key, requset);

        // 拿到锁

        if (result == 1L) {

            System.out.println(jedis.get(key));  -----------------（1）

            return jedis.expire(key, timeout) == 1L;

        } else { // 没有拿到锁

            return false;

        }

    }

}

存在问题：

setnx 和 expire是分两步进行的，不具有原子性，如果在（1）处抛出了异常，锁将无法过期！

改善方式：

使用Lua脚本来保证原子性（包含setnx和expire两条指令）

 

当然还存在其他问题，看本节第3部分。

2、使用Lua脚本来保证原子性（包含setnx和expire两条指令）

// timeout 单位是s

public boolean tryLockWithLua(String key, String requset, int timeout){

    String lua_scripts = "if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then " +

            "redis.call('expire',KEYS[1],ARGV[2]) return 1 else return 0 end";

    List keys = new ArrayList<>();

    List values = new ArrayList<>();

    keys.add("qin");

    values.add("wenjiang");

    values.add(String.valueOf(timeout));

    Object result = jedis.eval(lua_scripts, keys, values);

    //判断是否成功

    return result.equals(1L);

}

优点：解决了setnx 和 expire两个命令不具备原子性的特点

存在问题：lua脚本阅读不方便

当然还存在其他问题，看本节第3部分。

3、使用 set key value [EX seconds] [PX milliseconds] [NX | XX] 命令 （redis集群环境存在问题）

先来解释下这个命令：

• EX seconds: 设定过期时间，单位为秒
• PX milliseconds: 设定过期时间，单位为毫秒
• NX: 仅当key不存在时设置值
• XX: 仅当key存在时设置值

set命令的nx选项，就等同于setnx命令。

源码：

public String set(final String key, final String value, final String nxxx, final String expx, final int time)

public Boolean tryLockSet(String key, String requset, int timeout){

    String result = jedis.set(key, requset, "NX", "EX", timeout);

    return "OK".equals(result);

}

优点：解决了setnx 和 expire两个命令不具备原子性的特点；解决lua脚本阅读不方便问题

 

思考：上面一直说到的还存在的问题是什么呢？

在实际业务中，多个客户端同时操作，并发是必然存在的，思考这样一个场景：

1.客户端1获取锁成功

2.客户端1在某个操作上阻塞了太长时间

3.设置的key过期了，锁自动释放了

4.客户端2获取到了对应同一个资源的锁

5.客户端1从阻塞中恢复过来，因为value值是一样，所以执行释放锁操作时就会释放掉客户端2持有的锁，这样就会造成问题

即如何保证并发情况下A线程不会释放掉B线程的锁

可以让线程在获取某个对象的锁时，设置的value值包含该线程相关的信息，或者包含一个唯一的字符串（UUID来做），在释放锁时对value值进行验证，判断是否是当前线程持有的锁。

（这里说的value值对应上面例子中方法参数中的request参数，在实际业务中获取锁时，目的是为了保证某个对象被锁定，而不是设置value值，当然也有只是为了设置value值的场景，这种下面在思考 ）

思考：还存在问题吗？当然存在，上面的例子中都设置了过期时间，如果业务执行时间超过了这个过期时间呢？看下面4.4节

4.1.2 释放锁过程

上面已经分析了，解锁时，需要判断锁是否是当前线程自己的锁，判断方式是基于value值判断。

public Boolean releaseLockWityLua(String key,String value){

    String luaScript = "if redis.call('get',KEYS[1]) == ARGV[1] then " +

            "return redis.call('del',KEYS[1]) else return 0 end";

    return jedis.eval(luaScript, Collections.singletonList(key), Collections.singletonList(value)).equals(1L);

}

分析：这里使用了lua脚本的方式实现释放锁，

使用 set key value [EX seconds][PX milliseconds][NX|XX] 命令 看上去很OK，实际上在Redis集群的时候也会出现问题，比如说A客户端在Redis的master节点上拿到了锁，但是这个加锁的key还没有同步到slave节点，master故障，发生故障转移，一个slave节点升级为master节点，B客户端也可以获取同个key的锁，但客户端A也已经拿到锁了，这就导致多个客户端都拿到锁。

思考：为什么lua脚本就能可以呢？看到后面会发现就能功能优秀的红锁底层的实现也是lua脚本的形式，lua脚本这么神奇么？

 

4.1.3 这三种加锁方式特点

事实上这类琐最大的缺点就是它加锁时只作用在一个Redis节点上，即使Redis通过sentinel保证高可用，如果这个master节点由于某些原因发生了主从切换，那么就会出现锁丢失的情况：

1. 在Redis的master节点上拿到了锁；

2. 但是这个加锁的key还没有同步到slave节点；

3. master故障，发生故障转移，slave节点升级为master节点；

4. 导致锁丢失。（自认为拿到了锁，实际上没有拿到）

正因为如此，Redis作者antirez基于分布式环境下提出了一种更高级的分布式锁的实现方式：Redlock。笔者认为，Redlock也是Redis所有分布式锁实现方式中唯一能让面试官高潮的方式。

4.2 Redlock算法 与 Redisson 实现

一种更高级的分布式锁的实现——红锁

1、RedLock算法

假设有5个独立的Redis节点（ 这5个节点完全互相独立，不存在主从复制 或者 其他集群协调机制）：

• 获取当前Unix时间，以毫秒为单位
• 依次尝试从5个实例，使用相同的key和具有唯一性的value(例如UUID)获取锁，当向Redis请求获取锁时，客户端应该设置一个网络连接和响应超时时间，这个超时时间应用小于锁的失效时间，例如你的锁自动失效时间为10s，则超时时间应该在5~50毫秒之间，这样可以避免服务器端Redis已经挂掉的情况下，客户端还在死死地等待响应结果。如果服务端没有在规定时间内响应，客户端应该尽快尝试去另外一个Redis实例请求获取锁
• 客户端使用当前时间减去开始获取锁时间（步骤1记录的时间）就得到获取锁使用的时间，当且仅当从大多数(N/2+1，这里是3个节点)的Redis节点都取到锁，并且使用的时间小于锁失败时间时，锁才算获取成功。
• 如果取到了锁，key的真正有效时间等于有效时间减去获取锁所使用的时间（步骤3计算的结果）
• 如果某些原因，获取锁失败（没有在至少N/2+1个Redis实例取到锁或者取锁时间已经超过了有效时间），客户端应该在所有的Redis实例上进行解锁（即便某些Redis实例根本就没有加锁成功，防止某些节点获取到锁但是客户端没有得到响应而导致接下来的一段时间不能被重新获取锁）

思考：红锁算法的前提是n个完全独立的节点，这里的完全独立到底什么意思？

我理解的这里的完全独立是相当于部署了n个redis服务（为了区分可以叫为 Redission node），Redission node 节点既可以是单机模式(single)，也可以是主从模式(master/salve)，哨兵模式(sentinal)，或者集群模式(cluster)。这就意味着，不能跟以往这样只搭建 1个 cluster、或 1个 sentinel 集群，或是1套主从架构就了事了，需要为 RedissonRedLock 额外搭建多几套独立的 Redission 节点。 比如可以搭建3个 或者5个 Redission节点，具体可看视资源及业务情况而定。

（为了小数点后的一点点性能的提高，真的是无所不用极其啊！！！！）

 

2、Redisson实现简单的分布式锁

redisson已经有对redlock算法封装。

对于Java用户而言，我们经常使用Jedis，Jedis是Redis的Java客户端，除了Jedis之外，Redisson也是Java的客户端，Jedis是阻塞式I/O，而Redisson底层使用Netty可以实现非阻塞I/O，该客户端封装了锁，继承了J.U.C的Lock接口，所以我们可以像使用ReentrantLock一样使用Redisson，具体使用过程如下。

1、首先加入依赖

org.redisson     redisson     3.10.6

2、代码

import java.util.concurrent.CountDownLatch;



import org.redisson.Redisson;

import org.redisson.api.RLock;

import org.redisson.api.RedissonClient;

import org.redisson.config.Config;



public class RedissonTest {

    public static void lockByClient() {

        // redisson配置

        Config config = new Config();

        config.useSingleServer().setAddress("redis://127.0.0.1:6379").setDatabase(0);



        // redisson客户端

        RedissonClient redissonClient = Redisson.create(config);

        // 通过名字返回一个锁实例

        RLock lock = redissonClient.getLock("redlock");



        // 获取锁， 如果拿不到则线程被阻塞休眠直到获取到锁

        lock.lock();



        // 结果立即返回，如何可以立即拿到锁返回true, 否则返回false

        Boolean result = lock.tryLock();

        System.out.println("reuslt = " + result);

        try {

            System.out.println("current thread name is:" + Thread.currentThread().getName());

            System.out.println("获取锁成功，实现业务逻辑");

            Thread.sleep(1000);

        } catch (InterruptedException e) {

            e.printStackTrace();

        } finally {

            lock.unlock();

            lock.unlock();

        }

    }



    public static void main(String[] args) {

        final CountDownLatch latch = new CountDownLatch(3);



        Thread thread1 = new Thread(new Runnable() {

            @Override

            public void run() {

                lockByClient();

                latch.countDown();

            }

        });

        Thread thread2 = new Thread(new Runnable() {

            @Override

            public void run() {

                lockByClient();

                latch.countDown();

            }

        });

        Thread thread3 = new Thread(new Runnable() {

            @Override

            public void run() {

                lockByClient();

                latch.countDown();

            }

        });

        thread1.start();

        thread2.start();

        thread3.start();

        try {

            latch.await();

        } catch (InterruptedException e) {

            e.printStackTrace();

        }

    }

}

分析：

1、如果用一个线程去运行，上面加两次锁，两次都可以拿到锁（可重入）

2、如果多个线程去运行，上面加一次锁，多个线程依次拿到锁并释放

3、如果多个线程去运行，上面加两次锁，但是finally中只unlock依次，只有一个线程拿到锁（再次验证了可重入性）

4、如果多个线程去运行，上面加两次锁， finally中unlock两次，多个线程可以依次拿到锁并释放（再次验证了可重入性）

 

Redission重要说明：

1、唯一ID : 实现分布式锁的一个非常重要的点就是set的value要具有唯一性，redisson的value是怎样保证value的唯一性呢？答案是UUID+threadId。通过lock.lock(); 追踪源码可以看到设置的value值

final UUID id;

protected String getLockName(long threadId) {

    return id + ":" + threadId;

}

2、获取锁

 RFuture tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand command) {

    internalLockLeaseTime = unit.toMillis(leaseTime);

    // 向redis集群中的n个节点都发送命令

    return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command,

              //首先分布式锁的KEY不能存在，如果确实不存在，那么执行hset命令（hset REDLOCK_KEY uuid+threadId 1），并通过pexpire设置失效时间（也是锁的租约时间）

              "if (redis.call('exists', KEYS[1]) == 0) then " +

                  "redis.call('hset', KEYS[1], ARGV[2], 1); " +

                  "redis.call('pexpire', KEYS[1], ARGV[1]); " +

                  "return nil; " +

              "end; " +

               

              // 如果分布式锁的KEY已经存在，并且value也匹配，表示是当前线程持有的锁，那么重入次数加1，并且设置失效时间

              "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +

                  "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +

                  "redis.call('pexpire', KEYS[1], ARGV[1]); " +

                  "return nil; " +

              "end; " +

              // 获取分布式锁的KEY的失效时间毫秒数

              "return redis.call('pttl', KEYS[1]);",

              // 这三个参数分别对应KEYS[1]，ARGV[1]和ARGV[2]

              Collections.