分布式锁--（mysql-redis方式）

new DFP

已于 2022-10-28 21:36:13 修改

阅读量1.3k

点赞数

文章标签：分布式 java 开发语言

于 2022-10-02 17:14:44 首次发布

本文链接：https://blog.csdn.net/weixin_53472653/article/details/127141960

版权

1.背景介绍

在多线程高并发场景下，为了保证资源的线程安全问题， jdk 为我们提供了 synchronized 关键字和

ReentrantLock 可重入锁，但是它们只能保证一个 jvm 内的线程安全。在分布式集群、微服务、云原生

横行的当下，如何保证不同进程、不同服务、不同机器的线程安全问题， jdk 并没有给我们提供既有的解决方案。此时，我们就必须借助于相关技术手动实现了。目前主流的实现有三种方式：

1. 基于 mysql 关系型实现

2. 基于 redis 非关系型数据实现

3. 基于 zookeeper 实现

2.案例演示（超买现象）并且使用jvm提供的锁

2.1 新建一个数据库（将数据库的库存改为5000）

CREATE TABLE `db_stock` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `product_code` varchar(255) DEFAULT NULL COMMENT '商品编号', `stock_code` varchar(255) DEFAULT NULL COMMENT '仓库编号', `count` int(11) DEFAULT NULL COMMENT '库存量', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;

2.2 测试工具

使用压力测试工具

配置的100*50=5000次请求

2.3 代码演示

先不加锁演示

执行完成5000次但是数据库显示还有库存，这个时候就会发生超卖情况。

加锁

重启项目运用工具数控库存重置5000

这个时候就不会出现超卖的现象

因此jvm的锁也是可以处理一定问题的。但是也有例外

2.4 jvm锁失效的场景

多例模式

上述情况不出现超卖是因为添加了独占的排他锁，同一时刻只有一个请求能够获取到锁，并减库存。此时，所有请求只会one-by-one执行下去，也就不会发生超卖现象。这样多例模式下不是同一个service对象这样就会出现超卖的问题。

添加事务

失效的原理是a用户访问资源的时候，做了一系列操作在释放锁和提交事务之间的时候，b用户访问到了a事务未提交的操作。

多服务集群

就是分布式服务多太机器压根就不是一个jvm虚拟机。

复制3个上述案例工程

改造代码，配置nginx做代理转发

###nginx配置
#user  nobody;
worker_processes  1;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;
upstream distributedlock{
	server 127.0.0.1:1100;
	server 127.0.0.1:1110;
	server 127.0.0.1:1120;
}

    server {
        listen       80;
        server_name  localhost;
 charset gbk;

        location / {
		proxy_pass http://distributedlock;
        }
}
}

配置在不同的端口

访问80端口有效并且回进行负载均衡，通过工具进行压力测试。启动3个项目

演示集群锁失效

3.mysql分布式锁解决锁失效问题

3.1 基于一条sql语句解决锁失效

update delete insert 语句本身就是自带加锁

重启3个项目使用工具测试

优缺点：

1.表记锁定，当我们操作记录a并且锁定的时候，不能操作该表下的记录b

2.无法解决一对多的表记录。

3.无法使用该记录更新前后的状态。

4.解决了失效问题（多例模式，事务，集群）都可以解决

3.2 悲观锁

SELECT ... FOR UPDATE （悲观锁）

使用行级悲观锁的前提条件

1.查询字段必须是索引

2.查询条件必须是用= ，in关键字不能用like

行级别悲观锁可以解决的问题就是

* 在一般的查询语句中我们这条记录先查询到记录a的数据但是在这之间
* 其他用户操作了记录a的数据导致 2着数据不一致引起的问题
* 当我们加入悲观锁之后，做查询的时候已经为我们添加了锁，意味着这个查询上的锁没有结束别的操作不能进行

使用悲观锁之后就可以解决一条sql语句的缺陷

但是悲观锁的缺点如下

性能低（加了事务）
可能回发生死锁，保证加锁的顺序
操作需要统一，在其他查询该表的语句都需要加for update

3.3 乐观锁

乐观锁的就是需要在添加的时候判断版本号

修改数据库

修改代码

缺点：效率低，需要不停的检查版本号，读写分离的情况下不可靠。

3.4总结mysql锁

性能：一个sql > 悲观锁 > jvm锁 > 乐观

如果追求极致性能、业务场景简单并且不需要记录数据前后变化的情况下。

优先选择：一个sql

如果写并发量较低（多读），争抢不是很激烈的情况下优先选择：乐观锁

如果写并发量较高，一般会经常冲突，此时选择乐观锁的话，会导致业务代码不间断的重试。

优先选择：mysql悲观锁

不推荐jvm本地锁。

4.redis锁

关于redis事务在我之前的文章有锁介绍

redis事务介绍

4.1 redis乐观锁

利用redis监听 + 事务

redis配置这里不介绍了

缺点效率非常低

4.2 redis分布式锁

注意点

防止死锁

防止误删

接下来还是用工具进行压力测试，这里不演示了都是同一个api接口

存在的问题：

释放锁的判断和释放锁不是原子性的，所以会有一定的可能回照成错删，没有保证到释放锁和释放锁判断的原子性

解决上述问题引入 lua脚本（详细搜索一下）

修改代码将上图释放锁框内的修改如下

 // 先判断是否自己的锁，再解锁
        String script = "if redis.call('get', KEYS[1]) == ARGV[1] " +
            "then " +
            "   return redis.call('del', KEYS[1]) " +
            "else " +
            "   return 0 " +
            "end";
        this.redisTemplate.execute(new DefaultRedisScript<>(script, Boolean.class), Arrays.asList("lock"), uuid);

优化手写分布式锁添加自动延期,可重入锁。

添加构建工程

自动续期

重入锁

总结

特征：

1. 独占排他：setnx

2. 防死锁：

   redis客户端程序获取到锁之后，立马宕机。给锁添加过期时间

   不可重入：可重入

3. 防误删：

   先判断是否自己的锁才能删除

4. 原子性：

   加锁和过期时间之间：set k v ex 3 nx

   判断和释放锁之间：lua脚本

5. 可重入性：hash（key field value） + lua脚本 

6. 自动续期：Timer定时器 + lua脚本

7. 在集群情况下，导致锁机制失效：

   1. 客户端程序10010，从主中获取锁
   2. 从还没来得及同步数据，主挂了
   3. 于是从升级为主
   4. 客户端程序10086就从新主中获取到锁，导致锁机制失效


锁操作：

加锁：

1. setnx：独占排他   死锁、不可重入、原子性

2. set k v ex 30 nx：独占排他、死锁 		不可重入 

3. hash + lua脚本：可重入锁

   1. 判断锁是否被占用（exists），如果没有被占用则直接获取锁（hset/hincrby）并设置过期时间（expire）
   2. 如果锁被占用，则判断是否当前线程占用的（hexists），如果是则重入（hincrby）并重置过期时间（expire）
   3. 否则获取锁失败，将来代码中重试

4. Timer定时器 + lua脚本：实现锁的自动续期

   判断锁是否自己的锁（hexists == 1），如果是自己的锁则执行expire重置过期时间

解锁 

1. del：导致误删
2. 先判断再删除同时保证原子性：lua脚本
3. hash + lua脚本：可重入 
   	1. 判断当前线程的锁是否存在，不存在则返回nil，将来抛出异常
     2. 存在则直接减1（hincrby -1），判断减1后的值是否为0，为0则释放锁（del），并返回1
     3. 不为0，则返回0

重试：递归 循环

4.3 redisson中的分布式锁

官方文档

https://github.com/redisson/redisson/wiki/1.-%E6%A6%82%E8%BF%B0

我们使用data-redis手写的分布式锁会比较麻烦并且也比较复制，如果处理的不好还会出现一些问题，redisson为我们封装好了如何方便使用分布式锁的api。

引入依赖

<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.11.2</version>
</dependency>

4.3.1 可重入锁

基于Redis的Redisson分布式可重入锁RLock Java对象实现了java.util.concurrent.locks.Lock接口。

大家都知道，如果负责储存这个分布式锁的Redisson节点宕机以后，而且这个锁正好处于锁住的状态时，这个锁会出现锁死的状态。为了避免这种情况的发生，Redisson内部提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期。默认情况下，看门狗检查锁的超时时间是30秒钟，也可以通过修改Config.lockWatchdogTimeout来另行指定。

RLock对象完全符合Java的Lock规范。也就是说只有拥有锁的进程才能解锁，其他进程解锁则会抛出IllegalMonitorStateException错误。

另外Redisson还通过加锁的方法提供了leaseTime的参数来指定加锁的时间。超过这个时间后锁便自动解开了。

 public Object redissonLock() {
        int reduce = 1;
        //获取锁加锁
        RLock lock = redissonClient.getLock("lock");
        lock.lock();
//        lock.lock(30,TimeUnit.MINUTES);//设置过期时间
        /**
         * 默认30s过期时间并且在实例消失之前回自动续期
         * 就是说假设你的业务逻辑大于30s 但是你并没有设置过期时间那么他会自动续期保证业务
         */
        try {
            //mysql操作
            // 先查询库存是否充足
            List<Stock> list = this.stockMapper.selectList(new QueryWrapper<Stock>().eq("product_code", "10011"));
            if (CollUtil.isEmpty(list))
                return "不存在商品";
            //业务选取仓库 演示第一个
            Stock stock = list.get(0);
            //判断
            if (stock.getCount() < reduce)
                return "库存不足！";
            //减少
            stock.setCount(stock.getCount() - reduce);
            stockMapper.updateById(stock);
            //可重入锁
//            this.morelock();
        } finally {
            lock.unlock();
        }
        return null;
    }

    private void morelock() {
        //重入锁必须相同
        RLock lock = redissonClient.getLock("lock");
        lock.lock();
        log.info("重入锁");
        lock.unlock();
    }

new DFP

关注

0
点赞
踩
4

收藏

觉得还不错? 一键收藏
1
评论
分布式锁--（mysql-redis方式）

在多线程高并发场景下，为了保证资源的线程安全问题，jdk为我们提供了关键字和可重入锁，但是它们只能保证一个jvm内的线程安全。在分布式集群、微服务、云原生横行的当下，如何保证不同进程、不同服务、不同机器的线程安全问题，jdk并没有给我们提供既有的解决方案。此时，我们就必须借助于相关技术手动实现了。目前主流的实现有三种方式：1.基于mysql关系型实现2.基于redis非关系型数据实现3.基于zookeeper实现2.案例演示（超买现象）并且使用jvm提供的锁。
复制链接

扫一扫