分布式锁的原理,并基于redis,zookeeper和mysql方式实现

最新推荐文章于 2023-09-13 14:13:36 发布
最新推荐文章于 2023-09-13 14:13:36 发布
阅读量576 收藏 4
点赞数 3
分类专栏： JAVA 分布式 文章标签： 分布式 java
原创作品，转载请标明出处，如有疑问，请联系 [email protected]
本文链接：https://blog.csdn.net/shuchuntang2729/article/details/108267854
版权

分布式锁的原理,并基于redis,zookeeper和mysql方式实现

一. 背景

在分布式环境下 为了解决 资源抢占问题 和 幂等性 等问题 ，单机锁已经无法解决这个问题了，所以会使用到分布式锁，

这一篇主要介绍：

  1. 利用redis实现 非公平性分布式锁 （核心思想）
  2. 浅谈redisson组件实现 非公平性分布式锁
  3. 基于mysql实现 非公平性分布式锁
  4. 基于zookeeper实现 公平性分布式锁

所以接下来的内容会比较多，而且涉及到redis, lua脚本, redisson, zk的使用，所以希望大家可以耐心看下去。

在单机环境下，我们可以直接使用Lock锁或者synchronized，前面的篇章也介绍了ReentrantLock锁的源码解读，

感兴趣的小伙伴可以看一下 ↓↓↓

传送门：并发编程之AQS与ReentrantLock锁源码/原理剖析

二. 利用redis实现分布式锁

1. 原始版本

我们如果想利用redis实现分布式锁，首先能想到的就是针对redis中的某一个key进行操作，如果线程A把这个 key插入到了 redis，那么就相当于线程A获取到该锁，然后执行业务代码，执行完业务代码之后释放锁，然后其他的线程去做相同的操作，根据这个思想，下面是代码实现：

/**
* 原始版本
* 1. 先查看是否可用锁
* 2. 若可用 则占用锁
*/
public void version1(){
    String key = "lock";
    Object value = redisTemplate.opsForValue().get(key);
    if (value == null){
        value = Thread.currentThread().getName();
        redisTemplate.opsForValue().set(key,value);
        // 业务操作
        try{
            System.out.println("执行业务操作...");
        }catch (Exception e){
            e.printStackTrace();
        }finally {
            redisTemplate.delete(key);
        }
    }
}

代码解读：

1) 首先查看redis中是否存在key=‘lock’的数据。
2) 如果没有，就插入这条数据，其中key = 'lock', value = '当前线程的线程ID'。
3）如果执行了步骤2就相当于获取了锁，然后执行业务代码，执行完之后，删除该条数据，释放锁。
4) 如果执行步骤1的时候发现redis中已经有这条数据了 就表示已经有线程抢占到了锁 则获取锁失败。

这里会存在什么问题呢：

1) 假设执行 redisTemplate.opsForValue().get(key) 之后, 发现redis中没有这条数据，然后执行 redisTemplate.opsForValue().set(key,value) 去上锁，但是在这两步中间，有其他线程首先上锁成功了，那么就会出现不同线程持有锁的问题。
2) 假设线程A上锁成功，但是由于业务代码阻塞或者直接卡死，再或者机器宕机了，没有执行redisTemplate.delete(key) ，那么这个锁永远没法释放，就会形成死锁。
3) 同一个线程不能实现锁的重入。

然后我们思考，如何解决这三个问题：

  • 针对与第一个问题，需要做的是 redisTemplate.opsForValue().get(key) 和 redisTemplate.opsForValue().set(key,value) 这两步能原子性执行，我们首先想到的是redis的事务，其实除了直接使用redis的事务，还有一种比较友好和灵活的方式，就是可以利用 lua脚本 实现原子性，大家都知道redis工作方式是单线程的，redis在执行lua脚本中的指令时，可以保证原子性，中途不会被其他线程插入。

  • 针对于第二个问题，我们可以利用redis的过期时间机制来实现。

  • 针对于第三个问题，我们可以利用redis的hash表的数据结构实现，也就是说redis中在保存lock锁的同时，将线程ID当作hash表中的key，然后将重入次数当作hash表中的value。

在这里插入图片描述

2. 改良版本

根据我们发现的问题和进行思考得到的解决方案，进一步优化和完善，下面是改良版本的代码：

/**
* 改良版本
* 1. 先查看是否可用锁
* 2. 若可用 则占用锁
* 3. 给锁设置过期时间
* 上面这三个步骤利用 lua 脚本保证"原子性"(相比于不使用事务)
* 4. 利用 lua 脚本释放锁
*/
public void version2(){

    String key = "lock";
    String hkey = Thread.currentThread().getId();
	// 执行上锁的lua脚本
    Boolean result = lockLua(key, hkey);
    if (result){
        // 业务操作
        try{
            System.out.println("执行业务操作...");
        }catch (Exception e){
            e.printStackTrace();
        }finally {
            // 执行释放锁的lua脚本
            unLockLua(key, hkey);
        }
    }
}

/**
* 执行上锁的lua脚本
* hkey:当前线程的线程ID
* 暂时这里过期时间写死10秒
*/
private Boolean lockLua(String key, String hkey){
    try{
        DefaultRedisScript<Boolean> script = new DefaultRedisScript<>();
        script.setScriptSource(new StaticScriptSource("if (redis.call('exists', KEYS[1]) == 0) then" +
                "    redis.call('hset', KEYS[1], ARGV[1], 1);" +
                "    redis.call('expire', KEYS[1], ARGV[2]);" +
                "    return true;" +
                "end;" +
                "if (redis.call('hexists', KEYS[1], ARGV[1]) == 1) then" +
                "    redis.call('hincrby', KEYS[1], ARGV[1], 1);" +
                "    redis.call('expire', KEYS[1], ARGV[2]);" +
                "    return true;" +
                "end;" +
                "return false;"));
        script.setResultType(Boolean.class);

        List<String> keys = Collections.singletonList(key);
        return redisTemplate.execute(script, keys, hkey, 10);
    }catch (Exception e){
        logger.error(e.getMessage(),e);
        return false;
    }
}

/**
* 执行释放锁的lua脚本
* hkey:当前线程的线程ID
* 暂时这里过期时间写死10秒
*/
private void unLockLua(String key, String hkey){
    try{
        DefaultRedisScript<Boolean> script = new DefaultRedisScript<>();
        script.setScriptSource(new StaticScriptSource("if (tonumber(redis.call('hget', KEYS[1], ARGV[1])) == 1) then" +
                "    redis.call('del', KEYS[1]);" +
                "    return true;" +
                "end;" +
                "if (tonumber(redis.call('hget', KEYS[1], ARGV[1])) > 1) then" +
                "    redis.call('hincrby', KEYS[1], ARGV[1], -1);" +
                "    return true;" +
                "end;" +
                "return false;"));
        script.setResultType(Boolean.class);

        List<String> keys = Collections.singletonList(key);
        redisTemplate.execute(script, keys, hkey);
    }catch (Exception e){
        logger.error(e.getMessage(),e);
    }
}

代码解读：

1) 首先利用 redis提供的 RedisScript创建两个lua脚本执行器，一个是lockLua()方法用来上锁，一个是unLockLua()方法用来释放锁, 如果上面代码的lua指令不明白的 可以找一下相关资料 这里就不多说了。
2) 执行业务代码之前 跑lockLua()方法的lua脚本 抢占锁。
3) 若抢占锁成功 执行业务代码 此时该线程允许对该锁的重入。
4) 执行完业务代码 调用unLockLua()方法释放锁，这个时候并不是直接删除key，而是查看当前线程的重入次数是否大于1，若大于1 则对重入次数的数值减1， 如果等于1 则直接删除该key 释放锁。

可能有些小伙伴觉得这个方案没什么问题了 ，但是仔细思考一下 ，是不是有这么一个问题，就是假设我的过期时间设置了10S，而突然某些时刻我的业务代码因为各种各样的原因 执行时间超过了10秒，也就是说我的 业务代码还没有执行完成 由于redis的过期机制 自动删除了该锁 ，那么就会存在多个线程重叠执行，也就相当于锁失效了。

如何解决这个问题呢： 大致思路是可以设置一个当前线程的 守护线程 ，当然这个守护线程是 逻辑上的，不是真正的Daemon守护线程，这个守护线程的 生命周期跟持有锁的线程的生命周期一样 ，这个守护线程的作用就是定时检查当前锁是否快要过期了 而且业务线程还没有结束 如果是这样就给锁 续期 。

3. 最终版本

根据改良版本的实现和思考，进而进行优化和完善，下面直接上代码：

/**
* 最终版本
* 1. 先查看是否可用锁
* 2. 若可用 则占用锁
* 3. 给锁设置过期时间
* 上面这三个步骤利用 lua 脚本保证"原子性"(相比于不使用事务)
* 4. 利用 lua 脚本释放锁
* 5. 启动一个逻辑上的守护线程, 给锁续期
* 6. 如果没有获取到锁 则自旋等待
*/
public void version3() throws InterruptedException {

    String key = "lock";
    String hkey = Thread.currentThread().getId();

    for(;;){
        // 自旋 去获取锁
        Boolean result = lockLua(key, hkey);
        if (result){
            break;
        }
        Thread.sleep(100);
    }
    // 起一个线程 给锁续期
    Thread refreshLock = new RefreshLock(key, 10L, 3, 3L, redisTemplate, refreshRedisScript);
    try{
        refreshLock.start();
        // 业务操作
        System.out.println("执行业务操作...");
    }catch (Exception e){
        e.printStackTrace();
    }finally {
        // 释放锁
        unLockLua(key, hkey);
        // 中断守护线程
        refreshLock.interrupt();
    }
}

/**
* 执行上锁的lua脚本
* hkey:当前线程的线程ID
* 暂时这里过期时间写死10秒
*/
private Boolean lockLua(String key, String hkey){
    try{
        DefaultRedisScript<Boolean> script = new DefaultRedisScript<>();
        script.setScriptSource(new StaticScriptSource("if (redis.call('exists', KEYS[1]) == 0) then" +
                "    redis.call('hset', KEYS[1], ARGV[1], 1);" +
                "    redis.call('expire', KEYS[1], ARGV[2]);" +
                "    return true;" +
                "end;" +
                "if (redis.call('hexists', KEYS[1], ARGV[1]) == 1) then" +
                "    redis.call('hincrby', KEYS[1], ARGV[1], 1);" +
                "    redis.call('expire', KEYS[1], ARGV[2]);" +
                "    return true;" +
                "end;" +
                "return false;"));
        script.setResultType(Long.class);

        List<String> keys = Collections.singletonList(key);
        return redisTemplate.execute(script, keys, hkey, 10);
    }catch (Exception e){
        logger.error(e.getMessage(),e);
        return false;
    }
}

/**
* 执行释放锁的lua脚本
* hkey:当前线程的线程ID
* 暂时这里过期时间写死10秒
*/
private void unLockLua(String key, String hkey){
    try{
        DefaultRedisScript<Boolean> script = new DefaultRedisScript<>();
        script.setScriptSource(new StaticScriptSource("if (tonumber(redis.call('hget', KEYS[1], ARGV[1])) == 1) then" +
                "    redis.call('del', KEYS[1]);" +
                "    return true;" +
                "end;" +
                "if (tonumber(redis.call('hget', KEYS[1], ARGV[1])) > 1) then" +
                "    redis.call('hincrby', KEYS[1], ARGV[1], -1);" +
                "    return true;" +
                "end;" +
                "return false;"));
        script.setResultType(Boolean.class);

        List<String> keys = Collections.singletonList(key);
        redisTemplate.execute(script, keys, hkey);
    }catch (Exception e){
        logger.error(e.getMessage(),e);
    }
}

/**
* 守护线程
*/
public class RefreshLock extends Thread{

    // 上的锁的redis中的key
    private final String lockKey;

    // 上锁的最大时间
    private final Long expireTime;

    // 总共允许续期几次
    private final Integer count;

    // 隔几秒刷新
    private final Long refreshTime;

    private final RedisTemplate redisTemplate;

    private final DefaultRedisScript<Boolean> refreshRedisScript;

    RefreshLock(String lockKey, Long expireTime, Integer count, Long refreshTime, RedisTemplate redisTemplate, DefaultRedisScript<Boolean> refreshRedisScript){
        this.lockKey = lockKey;
        this.expireTime = expireTime;
        this.count = count;
        this.refreshRedisScript = refreshRedisScript;
        this.refreshTime = refreshTime;
        this.redisTemplate = redisTemplate;
    }

    @Override
    public void run() {
        int countValue = count;
        // 每一次自旋都检查是否被中断 如果是 则说明业务线程执行结束
        while (!Thread.currentThread().isInterrupted() && countValue > 0){
            try {
                // 每隔0.5秒检查一次(可自定义)
                Thread.sleep(500);
                Boolean result = (Boolean) redisTemplate.execute(refreshRedisScript, Collections.singletonList(lockKey),expireTime,refreshTime);
                if (result != null && result.equals(true)) {
                    countValue--;
                }
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

代码解读：

1） 创建一个RefreshLock线程类 作为守护线程，它的run方法逻辑就是：每隔0.5秒去检查一下redis中的锁是否快要过期，如果剩余时间少于我们指定的一个 阈值 :refreshTime ，则给锁续期。

2） 防止无线续期 设置一个 阈值: count 最多续期次数，因为如果续期了多次 业务代码还未执行结束 则考虑是代码性能的问题 ，就需要优化代码了 为不是无限给锁续期。

3） 在执行业务代码之前 我们加了一段 自旋逻辑 去抢占锁 因为当一个线程没有抢占到锁的时候 它更想做的是 阻塞等待抢占到锁 而不是直接返回 。

4） 如何保证守护线程会随着业务线程的结束而结束呢，这里用到的是发送 interrupt() 命令，当业务线程执行完业务代码之后，会在 finally代码块 中向守护线程发送interrupt()友好中断指令，而在守护线程的自旋中 会判断是否被中断 如果中断 则结束，然后会 被JVM回收。

在这里插入图片描述

注意： 如果出现lua脚本数据类型转换错误的话，则可能是因为序列化的问题，可以自定义redis的序列化方式：

@Configuration
public class RedisSerializer {

    @Bean
    public RedisTemplate<Object, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
        // 创建 redisTemplate 模版
        RedisTemplate<Object, Object> template = new RedisTemplate<>();
        // 关联 redisConnectionFactory
        template.setConnectionFactory(redisConnectionFactory);
        // 创建 序列化类
        GenericToStringSerializer<Object> genericToStringSerializer = new GenericToStringSerializer<>(Object.class);
        // 设置 value 的转化格式和 key 的转化格式
        template.setValueSerializer(genericToStringSerializer);
        template.setKeySerializer(new StringRedisSerializer());
        template.afterPropertiesSet();
        return template;
    }

}
4.小结

从上面的原始版本到最终版本，我们的思路一步步清晰和完善，总结一下思路和需要注意的细节：

  • 利用lua保证相对原子性 将多条命令在同一事务中执行
  • 利用redis的hash表结构 实现相同线程可重入锁
  • 没有抢占到锁的线程会自旋获取锁 不会直接失败
  • 起一个业务线程的守护线程 去维护锁的过期时间 并且利用interrupt友好中断 保证守护线程和主线程同时结束
5.补充补充补充!

针对上面利用redis实现的分布式锁，由于性能问题和扩展性问题，结合公司内部使用情况，设计并且落地了最新的版本：

  • 将锁续期的守护线程改为利用 时间轮+线程池 的方式实现
  • 支持可重入与不可重入
  • 采用 AOP+注解 的方式实现简单使用

架构图：

感兴趣的可以去文章最下面的github传送门。

三. 浅谈redisson实现分布式锁

按照我们上面利用redis实现分布式锁最后一个版本的思想，我们会发现要封装出来一个比较完善的分布式锁工具，其实还是要考虑和配置很多信息的 那么有没有市场上比较成熟的框架能帮我们实现呢 ，那就是redisson了 ，当然不仅仅只有redisson ，因为redisson是redis官方推出的 所以下面主要介绍一下它。

这里只是大致说一下如何使用redisson， 并不会对它的源码进行解读。

如果你认真 从文章开头读到了这里 ，那么其实你已经理解redisson的原理和设计了 。

先上一张架构图：

在这里插入图片描述

从这张图就能看出来，它的思想和我们前面利用redis一步步推到最后的实现思想几乎一样，是不是发现还有意外收获，不经意间就理解了redisson的设计原理和思想，接下来简单介绍一下在springboot中如何使用reidsson的分布式锁:

  1. pom依赖

            <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>
        <dependency>
            <groupId>org.redisson</groupId>
            <artifactId>redisson-spring-boot-starter</artifactId>
            <version>3.10.6</version>
        </dependency>

  2. yml配置

    spring:
  # redis
  redis:
    host: localhost
    port: 6379
    redisson:
      # 配置单点模式
      config: classpath:redisson-single.yml

  3. redisson配置

    # 单节点配置
singleServerConfig:
  # 连接空闲超时，单位：毫秒
  idleConnectionTimeout: 10000
  pingTimeout: 1000
  # 连接超时，单位：毫秒
  connectTimeout: 10000
  # 命令等待超时，单位：毫秒
  timeout: 3000
  # 命令失败重试次数,如果尝试达到 retryAttempts（命令失败重试次数） 仍然不能将命令发送至某个指定的节点时，将抛出错误。
  # 如果尝试在此限制之内发送成功，则开始启用 timeout（命令等待超时） 计时。
  retryAttempts: 3
  # 命令重试发送时间间隔，单位：毫秒
  retryInterval: 1500
  # 重新连接时间间隔，单位：毫秒
  reconnectionTimeout: 3000
  # 执行失败最大次数
  failedAttempts: 3
  # 密码
  password: null
  # 单个连接最大订阅数量
  subscriptionsPerConnection: 5
  # 客户端名称
  clientName: null
  # 节点地址
  address: redis://47.103.5.190:6379
  # 发布和订阅连接的最小空闲连接数
  subscriptionConnectionMinimumIdleSize: 1
  # 发布和订阅连接池大小
  subscriptionConnectionPoolSize: 50
  # 最小空闲连接数
  connectionMinimumIdleSize: 32
  # 连接池大小
  connectionPoolSize: 64
  # 数据库编号
  database: 0
  # DNS监测时间间隔，单位：毫秒
  dnsMonitoringInterval: 5000
# 线程池数量,默认值: 当前处理核数量 * 2
threads: 0
# Netty线程池数量,默认值: 当前处理核数量 * 2
nettyThreads: 0
# 编码
codec: !<org.redisson.codec.JsonJacksonCodec> {}
# 传输模式
transportMode : "NIO"

  4. java代码

    @Component
public class RedissonLockDemo implements ApplicationRunner {

    private final RedissonClient redissonClient;

    public RedissonLockDemo(RedissonClient redissonClient) {
        this.redissonClient = redissonClient;
    }

    @Override
    public void run(ApplicationArguments args) throws Exception {
        String lockKey = "lock";
        // 利用redisson创建锁实例
        RLock lock = redissonClient.getLock(lockKey);
		// 上锁 并设置过期时间为10秒
        lock.lock(10, TimeUnit.SECONDS);
        try{
            System.out.println("执行业务代码...");
        }catch (Exception e){
            e.printStackTrace();
        }finally {
            // 释放锁
            lock.unlock();
        }
    }

1） 配置好redisson之后 直接使用RedissonClient创建指定锁的实例，并利用该实例进行上锁，设置过期时间和释放锁，使用起来很简单，特别是如果你理解了前面的内容，你应该立刻就知道他的里面的代码实现的思想和逻辑了。

2） redisson还提供了很多关于分布式锁的API 和其他的功能，强烈向小伙伴们推荐它。

四. 利用mysql实现分布式锁

1. 悲观锁

首先回顾一下什么是悲观锁，悲观锁，正如其名，具有强烈的独占和排他特性。它指的是对数据被外界(包括本系统当前的其他事务，以及来自外部系统的事务处理)修改持保守态度。之所以叫做悲观锁，是因为这是一种对数据的修改抱有悲观态度的并发控制方式。我们一般认为数据被并发修改的概率比较大，所以需要在修改之前先加锁。

关于mysql中InnoDB的事务和锁机制，之前的篇章也介绍过，不太了解或者感兴趣的小伙伴也可以看一下 ↓↓↓

传送门: InnoDB引擎的事务与锁

相信从传送门回来的小伙伴对mysql中 InnoDB引擎的排他锁 已经熟悉了，我们在一个事务中，对指定的数据行进行select … for update 或者 在insert/update的时候 是会上排他锁的 ，而该事务结束之前 其他想要获取到该条数据的事务 是会阻塞的，我们就是利用这个机制实现分布式锁。

首先创建一张记录锁信息的表：

CREATE TABLE `lock` (
  `lock_key` varchar(11) NOT NULL,
  PRIMARY KEY (`lock_key`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
  • lock_key字段l作为锁的key。

下面是代码实现，环境是springboot：

@Component
public class MysqlLockServer implements ApplicationRunner{

    /** 事务管理器顶层接口 PlatformTransactionManager */
    private final PlatformTransactionManager platformTransactionManager;

    /** jdbcTemplate */
    private final JdbcTemplate jdbcTemplate;

    /** 默认的事务定义 */
    private final TransactionDefinition transactionDefinition = new DefaultTransactionDefinition();

    public MysqlLockServer(PlatformTransactionManager platformTransactionManager, JdbcTemplate jdbcTemplate) {
        this.platformTransactionManager = platformTransactionManager;
        this.jdbcTemplate = jdbcTemplate;
    }

    @Override
    public void run(ApplicationArguments args) throws Exception {
        TransactionStatus transaction = platformTransactionManager.getTransaction(transactionDefinition);
        try{
            try{
                // 尝试插入key获取锁
                jdbcTemplate.execute("insert into `lock`(`lock_key`) values ('lockKey');");
                // 抢占锁
                jdbcTemplate.execute("select 1 from `lock` where lock_key = 'lockKey' for update;");
            }catch (Exception e){
                // 如果抛出异常 说明该key已经存在 则直接去抢占锁
                jdbcTemplate.execute("select 1 from `lock` where lock_key = 'lockKey' for update;");
            }
            // 业务代码
            System.out.println("业务代码");

            // 删除锁
            jdbcTemplate.execute("delete from `lock` where lock_key = 'lockKey';");
            // 提交事务
            platformTransactionManager.commit(transaction);
        }catch (Exception e){
            e.printStackTrace();
            // 回滚事务
            platformTransactionManager.rollback(transaction);
        }
    }
}

思路解析：

1）因为我们在springboot环境，所以springboot会自动注入 事务管理器顶层接口PlatformTransactionManager 的Bean实例和JdbcTemplate实例。

2）首先尝试执行insert语句 将锁对应的key值插入到数据库，但是我们不能保证刚好 有他线程插入了该数据 ，但是因为我们加了 唯一索引 ，所以在插入的时候会抛出异常，所以我们需要在catch块中也做补偿即可，所以不管insert成功还是失败，都会执行select… for update 尝试获取锁。

3）若获取锁成功，则直接执行业务代码。

4）若获取锁失败，则会阻塞在select…for update的地方 等待获取到锁，再继续向下执行业务代码。

5）最后提交事务，并删除该key的数据，提交事务后，mysql的排他锁会自动释放，其他线程会从select…for update中被唤醒。

6）需要注意的是，要在最外层的catch块中添加事务回滚的逻辑，否则可能会出现死锁的问题。

悲观锁的缺点：

使用悲观锁会存在一定的性能和死锁问题，所以在使用悲观锁的时候 要考虑到死锁问题，而且上面实现的悲观锁，并不能支持锁的重入，所以 我们更倾向于使用乐观锁实现分布式锁，下面介绍基于mysql乐观锁的实现。

2. 乐观锁

乐观锁机制采取了更加宽松的加锁机制。乐观锁是相对悲观锁而言，也是为了避免业务处理时间过长等原因引起数据处理错误的一种机制，但乐观锁不会刻意使用数据库本身的锁机制，而是依据数据本身来保证数据的正确性。

首先创建一张记录锁信息的表：

CREATE TABLE `lock` (
  `lock_key` varchar(11) NOT NULL,
  `thread_id` bigint(22) DEFAULT NULL,
  `entry_count` int(11) unsigned zerofill DEFAULT NULL,
  PRIMARY KEY (`lock_key`) USING BTREE,
  UNIQUE KEY `lock` (`thread_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

  • lock_key字段l作为锁的key，

  • thread_id字段作为持有该锁的线程ID，

  • entry_count字段作为当前持有锁的线程的重入次数。

下面是代码实现，环境是springboot：

@Component
public class MysqlLockServer implements ApplicationRunner{

    /** 事务管理器顶层接口 PlatformTransactionManager */
    private final PlatformTransactionManager platformTransactionManager;

    /** jdbcTemplate */
    private final JdbcTemplate jdbcTemplate;

    /** 默认的事务定义 */
    private final TransactionDefinition transactionDefinition = new DefaultTransactionDefinition();

    public MysqlLockServer(PlatformTransactionManager platformTransactionManager, JdbcTemplate jdbcTemplate) {
        this.platformTransactionManager = platformTransactionManager;
        this.jdbcTemplate = jdbcTemplate;
    }

    @Override
    public void run(ApplicationArguments args) throws Exception {
        TransactionStatus transaction = platformTransactionManager.getTransaction(transactionDefinition);
        try{
            Long threadId = null;
            String lockKey = "lockKey";
            int result = 0;
            try{
                // 尝试插入key获取锁
                threadId = Thread.currentThread().getId();
                jdbcTemplate.execute("insert into lock(lock_key,thread_id) values (" + lockKey +","+ threadId +");");
                // 抢占锁
                lock(result,threadId);
            }catch (Exception e){
                // 如果抛出异常 说明该key已经存在 则直接去抢占锁
                lock(result,threadId);
            }
            // 业务代码
            System.out.println("业务代码");

            // 释放锁 并不是直接释放  而是先减少重入次数
            jdbcTemplate.execute("update lock set entry_count = entry_count - 1 where thread_id is not null and thread_id = " + threadId);
            // 若不存在重入次数 则删除锁
            jdbcTemplate.execute("update lock set thread_id = null where lock_key = "+ lockKey +" and entry_count <= 0;");
            // 提交事务
            platformTransactionManager.commit(transaction);
        }catch (Exception e){
            e.printStackTrace();
            // 回滚事务
            platformTransactionManager.rollback(transaction);
        }
    }

    /**
     * 自旋获取锁
     */
    private void lock(int result,Long threadId){
        while(result == 0){
            result = jdbcTemplate.update("update lock set entry_count = entry_count + 1 where thread_id is not null and thread_id = " + threadId);
        }
    }

}

思路解析：

1）首先尝试执行insert语句 将锁对应的key值和线程ID插入到数据库，但是我们不能保证刚好 有他线程插入了该数据 ，不过因为我们加了 唯一索引 ，所以在插入的时候会抛出异常，所以我们需要在catch块中也做 补偿 ，所以不管insert成功还是失败，都会执行 lock() 方法尝试获取锁。

2）若获取锁成功，则直接执行业务代码。

3）若获取锁失败，则线程会阻塞在lock()方法中的自旋地方 等待获取到锁，再继续向下执行业务代码。

4）最后提交事务，并不会直接删除该key，而是先减少重入次数，然后再检查重入次数是否已经小于等于0了，如果是则删除该lock的数据，提交事务后，其他事务会在lock()方法的自旋中执行成功，然后执行业务代码。

五. 基于zookeeper实现分布式锁

使用过zk的小伙伴应该都清楚，zk的功能很强大，不仅仅对于实现分布式锁，很多中间件都是利用zk的通讯机制实现服务注册和数据监听等功能，本章主要针对于使用zk实现分布式锁，先大致说一下使用zk实现分布式锁利用的特性：

  • 节点的有序性(实现公平锁)
  • 心跳机制(防止抢占锁的线程异常中断)
  • 事件监听(通知获取锁)
  • 持久节点(锁的唯一key)
  • 临时节点(争抢同一个锁的线程)

思路：

1）首先创建一个该锁的持久节点，这个节点是一直在zk中，不会被删除。

2）当线程要争夺该锁，则在该锁的目录下创建一个临时节点，由于zk的特性，它会对所有临时节点排序，节点名称后面自动有一个数字编号，zk默认会对编号递增( + 1)，即先来先到。

3）排在第一个节点的线程，就相当于获取到了锁，执行完业务数据之后，释放锁删除该节点。

4）每个抢夺锁的线程都会监听前一个节点的删除事件，若前一个结点释放锁删除节点之后，当前线程会重新检查是否已经排在第一了，如果是，则重复上一步操作。

5）如果线程在抢占锁的时候发生了异常，由于zk的心跳机制，发现该服务无法通信，则会删除该临时节点，防止出现死锁问题。

在这里插入图片描述

下面是代码demo：

# 配置信息：
zookeeper:
  address: 127.0.0.1:2181

创建 zkClient：

@Configuration
public class ZookeeperConfig {

    @Value("${zookeeper.address}")
    private  String connectString;

    @Bean(name = "zkClient")
    public ZooKeeper zkClient(){
        ZooKeeper zooKeeper=null;
        try {
            final CountDownLatch countDownLatch = new CountDownLatch(1);
            zooKeeper = new ZooKeeper(connectString, 10000, event -> {
                if(Watcher.Event.KeeperState.SyncConnected==event.getState()){
                    countDownLatch.countDown();
                }
            });
            countDownLatch.await();
            System.out.println("zk connect success...");
            // 创建锁的持久化节点
            zooKeeper.create("/lock", "0".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
        }catch (Exception e){
            e.printStackTrace();
        }
        return zooKeeper;
    }

}

锁的细节实现：

@Component
public class ZookeeperLock implements ApplicationRunner {

    // 前一个节点的临时节点
    private String watchLock;
    // 当前拥有的节点
    private String currentLock;
    // 阻塞等待锁的线程
    private CountDownLatch countDownLatch = new CountDownLatch(1);

    // 临时节点的前缀名 例:lock-00000001
    private static final String LOCK_PRE ="lock-";

    private final ZooKeeper zkClient;

    public ZookeeperLock(ZooKeeper zkClient) {
        this.zkClient = zkClient;
    }

    /**
     * 抢占锁
     */
    private boolean tryLock() throws KeeperException, InterruptedException {
        if (currentLock == null){
            synchronized (this){
                if (currentLock == null){
                    // 创建临时节点
                    currentLock = zkClient.create("/lock/" + LOCK_PRE, "0".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL);
                    System.out.println(currentLock);
                }
            }
        }
        return isFirstNode();
    }

    /**
     * 判断是否是第一个节点
     */
    private boolean isFirstNode() throws KeeperException, InterruptedException {
        List<String> childrenList = zkClient.getChildren("/lock", false);
        TreeSet<String> sortedSet = new TreeSet<>();
        for (String children : childrenList) {
            sortedSet.add("/lock/" + children);
        }
        //获得当前节点中的最小的子节点;
        String firstNode = sortedSet.first();
        SortedSet<String> lessThenCurrentNode = sortedSet.headSet(currentLock);
        //通过当前节点与最小节点进行比较 , 如果相等则获取所成功;
        if (currentLock.equals(firstNode)) {
            return true;
        }
        // 获得比当前节点更小的最后一个节点，进行监听
        if (!lessThenCurrentNode.isEmpty()) {
            watchLock = lessThenCurrentNode.last();
            // 发起事件监听
            waitLock();
            // 阻塞等待前一个节点的删除事件 等待唤醒
            countDownLatch.await();
            //重新判断当前节点是否排在第一
            isFirstNode();
        }
        return false;
    }

    /**
     * 发起事件监听
     */
    private void waitLock() throws KeeperException, InterruptedException {
        zkClient.exists(watchLock, event -> {
            // 捕获到前一个节点的删除事件
            if (event.getType() == Watcher.Event.EventType.NodeDeleted){
                // 唤醒阻塞等待的线程
                countDownLatch.countDown();
            }
        });
    }

    /**
     * 释放锁
     */
    private void unLock() throws KeeperException, InterruptedException {
        // 设置version为-1 强制删除
        zkClient.delete(currentLock,-1);
    }

    @Override
    public void run(ApplicationArguments args) throws Exception {
        try{
            if (tryLock()){
                // 执行业务代码
                System.out.println(1);
            }
        }catch (Exception e){
            e.printStackTrace();
        }finally {
            unLock();
        }
    }

}

分析：通过代码我们会发现几个细节

1）zk并没有告诉我们当前节点是否是第一个节点，所以我们需要手写方法实现。

2）所有临时节点都会有一个事件监听，在事件未发生之前，会一直阻塞，所有可以考虑不采用阻塞的机制，而是采用自旋的方式判断自己是否已经是第一个节点了。

扩展： 上述的zk分布式锁的实现思想仍然是基于悲观锁的思想，那么zk能不能也采用 乐观锁 的机制实现呢，其实也是可以的，zk在创建节点的时候， 会为这个节点维护一份元数据信息 ，其中有一个名为dataversion的字段，就是表示这个节点的版本号，每一次修改，该版本号都递增，因此，我们如果想利用该信息实现乐观模式的分布式锁，具体的步骤这里就不过述了。

六. 总结

分布式锁是为了解决资源抢夺和幂等性的问题，那么我们想做的就是在一个时刻 只允许一个线程拥有资源，所以：

利用zk的临时文件特性，事件监听和心跳机制特点实现 公平性 分布式锁；

利用mysql中innoDB引擎的排他锁机制和乐观锁实现 非公平性 分布式锁；

利用redis的单线程(react模型)，过期机制和内存效率等特点实现 非公平性 分布式锁；

从这些实现方案，可以总结出来，分布式锁的核心在于几个点：

  • 锁的过期机制
  • 锁不会被其他线程抢夺
  • 不会出现死锁
  • 阻塞等待或事件通知机制
  • 锁的续期
  • …

基于这些点，不管我们用什么工具去实现甚至自己手写去实现，只要考虑周全，其实都是没什么大问题的。

传送门：git源码

言淮Lee
关注
  • 3
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 6
    评论
专栏目录
基于Redis实现简单的分布式锁
12-14
分布式锁实现的方案有很多，比如基于ZooKeeper实现、或者基于Mysql实现等等，我们来一起看看如何基于Redis实现分布式锁服务。 　分布式锁要点 　对于分布式锁的目标，我们必须首先明确三点： 　1、任何一个时间点...
windows下分布式部署Mysql、Redis、Zookeeper、Nginx、FastDFS集合
11-21
在学习分布式集群的时候发现好多文档有问题，不能完整的部署环境，决定自己写一个大杂烩 Mysql、Redis、Zookeeper、Nginx、FastDFS集合
集成分布式锁架包（MySQL、Redis、Zookeeper）
hanxiaozhang的博客
01-02 644
疫情当下，大环境不好，自己又去了一家令人非常失望的单位，一直在996加班忙于业务代码，技术方面几乎等于零成长。但是，作为一个Coder，必须要挤出时间去学习与总结，不然就会被无情的淘汰。Coder加油吧!
分别使用Redis、MySQL、ZooKeeper构建分布式锁
最新发布
三两肉的博客
09-13 7742
分别使用Redis、MySQL、ZooKeeper构建分布式锁
基于Mysql、Redis和zookeeper实现分布式锁，解决超卖问题
qq_37032116的博客
10-29 1242
基于Mysql、Redis和zookeeper实现分布式锁，解决超卖问题
使用MySQL实现一个分布式锁
09-08
在分布式系统中，分布锁是一个最基础的工具类。这篇文章主要介绍了用MySQL实现一个分布式锁，本文通过实例代码相结合给大家介绍的非常详细，具有一定的参考借鉴价值,需要的朋友可以参考下
基于Redis+Zookeeper+MySQL实现高并发秒杀系统（一）
01-12 681
基于Redis+Zookeeper+MySQL实现高并发秒杀系统 第一篇 为什么使用Redis ： MySQL并发操作，单机最多支撑1000个，了不起了。无论是从性能还是安全来说，Redis的集成都大大解决了系统的并发问题。利用Redis的原子性操作。 为什么使用Zookeeper : 虽然Redis性能非常之高，但是少不了就是应用服务于Redis之间的通信，每一次的通信至少是需要时间的。所以我们应该在应用程序增加本地缓存，但是本地缓存会存在一个问题，在分布式部署下，多台服务器的多个应用程序，缓存不一致，一
基于Redis+Zookeeper+MySQL实现高并发秒杀系统（二）终极篇【源码开源发布】
01-17 399
<h1 id="基于rediszookeepermysql实现高并发秒杀系统（二）终极篇【源码开源发布】">基于Redis+Zookeeper+MySQL实现高并发秒杀系统（二）终极篇【源码开源发布】
使用 Mysql 实现分布式锁
weixin_36001569的博客
06-02 1023
mysql 分布式锁
​【五一创作】基于mysql关系型实现分布式锁
一个菜鸡的博客
05-02 3196
在多线程高并发场景下，为了保证资源的线程安全问题，jdk为我们提供了synchronized关键字和ReentrantLock可重入锁，但是它们只能保证一个jvm内的线程安全。在分布式集群、微服务、云原生横行的当下，如何保证不同进程、不同服务、不同机器的线程安全问题，jdk并没有给我们提供既有的解决方案。此时，我们就必须借助于相关技术手动实现了。目前主流的实现有三种方式：1. 基于mysql关系型实现2. 基于redis非关系型数据实现3. 基于zookeeper实现。
分布式锁三种实现方式及对比
12-14
2. 基于缓存（Redis等）实现分布式锁； 3. 基于Zookeeper实现分布式锁； 一， 基于数据库实现分布式锁 1. 悲观锁 利用select … where … for update 排他锁 注意: 其他附加功能与实现一基本一致，这里需要注意的是...
基于ssm redis solr dubbo zookeeper mysql等大型分布式电商系统.zip
08-20
springboot、Dubbo、MySQL，源码web系统，框架，代码均经过严格测试，可直接运行，有需要可自取
Redis分布式锁解决接口幂等的两种方案
12-21
本文是通过使用 Redis 实现分布式锁，当然也可用使用各大数据库，比如 Mysql、Oracle 自持的行级锁、大厂的 Zookeeper 等方案实现。 分布式锁的基本思想 我们既然称其为“锁”，那就是说只有唯一的一把钥匙才能将锁...
调度算法 - 时间轮
言淮的博客
10-17 1935
调度算法 - 时间轮 一. 背景 在我们的业务场景中，经常会使用到定时任务功能，比如定时发送消息，定时执行数据同步，比如之前的文章介绍的分布式事务中的本地事务表方式的解决方案等等，特别是在现在大数据量和分布式服务环境下，定时任务调度越来越频繁，所以对应的定时任务调度的算法实现也越来越完善。在之前的单机环境下，我们可以使用 ScheduledThreadPool 起一个延迟任务线程池，定时的执行任务，又或者使用spring提供的 @Schedule 注解配合上 cron表达式 开启一个定时任务，又或者是lin
分布式事务解决方案和原理
言淮的博客
08-20 1311
分布式事务解决方案和原理,以及引发的思考 一. 背景： 我们都知道, 在以前的 all in one 的项目开发模式下, 所有事务问题都是本地事务问题, 基本上利用mysql的优化方案和java提供的API, 可以解决绝大多数本地事务问题，而在现在的分布式及微服务的模式下，很多事务问题就不是简单的本地事务问题了，正是由于在为服务环境下存在的网络延迟问题，机器不可用问题，以及一次操作由多个系统协同完成而产生的各类问题，导致了逻辑上的一次事务违反了ACID中的特性问题。 之前的文章介绍了事务中的ACID和事务的
InnoDB引擎的事务与锁
言淮的博客
08-10 1057
InnoDB引擎的事务与锁 一. 背景：事务和事务引发的问题 1. ACID 原子性：表示整个事务是不可分割的，要么都执行成功，要么都执行失败。 一致性：保证完整性约束没有被破坏。 隔离性： 事务不可见行，事务与事务之间分离不可见。 持久性:事务一旦提交，其结果就是永久性的，即使发生宕机，数据也是可以恢复的。 2. 事务的分类 1. 扁平事务 扁平事务是事务中最简单的一种，也是使用最频繁的，在扁平事务中，所有操作都处于同一层次，由BEGIN开始，COMMIT 或者ROLLBACK结束，其操作都是原子性的。
JVM详解(类加载，内存分配，GC，内存模型)
言淮的博客
01-02 674
一. 背景 1. 前言 作为一位Java开发工作者，在关心业务代码开发的同时，我们也需要了解java底层时如何运作的，了解为什么说java是跨平台的语言，所以这一篇对JVM(java虚拟机)进行剖析和详解，首先让我们来看一张JDK的概念图( 下文都是围绕HotSpot虚拟机展开 )： 从上图可以看出，概念图中最上层的是工具包和工具，往下是部署包和组件，再往下是基础库，而最下层的就是JVM虚拟机，所以说，整个JDK都架于JVM之上，由此可见 了解和深入JVM对我们以后工作和学习的深度和广度都有很大的影响。
并发编程之AQS与ReentrantLock锁源码/原理剖析
言淮的博客
08-13 295
背景： JUC并发包提供了很多线程并发问题的解决方案，包括ConcurrentHashMap哈希Map，ConcurrentLinkedDeque阻塞队列，Executor线程池以及locks包，Atomic原子类的包等数据结构和逻辑思想，本章节主要讨论AbstractQueuedSynchronizer（AQS），基于AQS实现的Lock锁，以及基于AQS和Lock锁扩展的Condition等待队列，其余部分会有专门章节分析。 一. AQS(AbstractQueuedSynchronizer) 1. A
分布式锁， mysql、 redisson、 redlock、zookeeper络拓扑图
07-28
3. Redlock：Redlock是一个基于Redis的分布式锁实现，旨在解决Redis主节点故障时的可用性问题。它通过在多个Redis实例之间协调获取锁，并使用算法来确保锁的互斥性。 4. ZooKeeper：ZooKeeper是一个分布式协调服务...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 6
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值