redis分布式锁及其应用

最新推荐文章于 2024-11-04 20:00:00 发布
最新推荐文章于 2024-11-04 20:00:00 发布
阅读量301 收藏
点赞数
文章标签： redis 分布式 java Powered by 金山文档
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_42223524/article/details/129704812
版权

  1. java锁的回顾：

  • 我们在学习java线程的时候都知道，当有多个线程访问共享资源的时候有可能会产生线程安全的问题，那解决的办法大多数就是使用锁了。

  • java中加锁的方式有很多，例如使用synchronized关键字，或者ReentrantLock可重入锁等。当然在使用锁的时候我们一定要考虑的问题就是: (1) 死锁问题 (2) 锁的性能问题。

  • 对于死锁问题，我们都是在使用锁的时候尽量避免锁的嵌套或者能保证锁可以得到释放等;

  • 而对于提升锁的性能问题，我们往往会选择锁粒度更小的加锁方式 (比如Lock使用起来可以控制锁的范围粒度，而synchronized就没那么灵活虽然idk1.6之后对synchronized也做了升级)缩短持有锁的时间、读写操作分离等手段。

  1. 分布式锁:

  • 我们之前介绍的使用synchronized或者ReentrantLock加锁可以保证多个线程访问共享资源的安全性，但是那有一个前提:就是我们多个线程访问的都在同一个服务器节点，这时候我们使用synchronized或者ReentrantLock可以保证这个服务器上JVM中数据的安全性; 但是如果我们我们有多个服务器节点 (分布式)功能处理业务呢? 这时候使用的锁只能保证一台服务器上线程的安全，并不能保证分布式的环境下的线程的安全。

  • 以常见的电商减库存为典例，在分布式的情况下如果不做处理，很容易出现超买超卖的情况。原因就是，当一个交易线程下单成功之后我们需要减库存，但是如果修改库存的时候另外一个服务器处理的线程也要下订单减库存此时它读取到的还是没有减的库存认为还有商品卖所以就导致了超卖了。

  • 那怎么解决分布式情况下多个线程访问不安全的问题呢? 那就是使用分布式锁了!当然分布式锁的实现方式还是有几种，例如:

使用ZooKeeper，基于临时有序节点。

使用Redis，基于set命令

  • Redis 分布式锁本质上就是“占位置”，当一个线程操作redis缓存的时候Redis就为其占位 (使用setnx命令: 表示当且仅当key不存在的时候创建。若给定key已经存在，则setnx不做任何动作)，并且只允许被一个客户端占位置;当别的进程也要来占时，发现已经有了，就只好放弃或者稍后再试。当占位的线程访问完之后redis会通过 del删除占位。

  • 当然这中间会出现一些问题，比如当线程占位成功了也就是获取锁成功，但是在释放锁前出现了问题那么就会导致死锁，所以使用redis加锁最好是给一个过期时间也就是使用expire。又因为expire和setnx两条指令的执行不是原子性的，所以也可能出现在setnx之后expire设置成功之前出现故障导致添加有效期失败，所以redis在2.8后对set命令进行了扩展，可以把setnx 和 expire一起执行，这样就解决了redis分布式锁的一些乱象。命令格式如下:

  • 当然分布式锁不能解决锁超时问题，我们还需要保证锁的可重入性。如果一个锁支持同一个线程的多次加锁，那么这个锁就是可重入的。比如 Java 里有个 ReentrantLock 就是可重入锁。Redis 分布式锁如果要支持可重入，需要对客户端的 set 方法进行包装，使用线程的Threadlocal 变量存储当前持有锁的计数。

  1. 分布式锁实现一（减库存案例）

@Autowired
    private RedisTemplate redisTemplate;

    private static final String LOCK="goods_luck";

    @PostMapping("/buy01")
    public String buy01(Long gid){

        //获取redis分布式锁
        String uuid = UUID.randomUUID().toString().replace("-","");
        try{
            Boolean flag = redisTemplate.opsForValue().setIfAbsent(LOCK, uuid, 3L, TimeUnit.SECONDS);
            if (!flag){
                return "获取锁失败，商品减库存失败！";
            }
            log.info(uuid+" 获取锁成功！");
            //获取库存
            String nums = (String) redisTemplate.opsForValue().get("buy-" + gid);
            long totalNums = nums == null? 0: Integer.valueOf(nums);
            // 减库存
            if (totalNums >0){
                long nowTotal = totalNums -1;
                redisTemplate.opsForValue().set("buy-" + gid,String.valueOf(nowTotal));
                return "商品购买成功，当前库存量为："+nowTotal;
            }
        }catch (Exception e){

        }finally {
            //释放锁
            redisTemplate.delete(LOCK);
        }
        return "减库存失败！";
    }

缺陷: 如果因意外情况如服务器卡顿或者业务处理太慢，导致处理时间超过了key的有效期，也就是说key在处理业务卡顿的时候就已经释放了锁被其他进程占用了锁，那么当之前key的业务处理完之后有释放锁的行为就会释放其他key的锁，这样

就很严重。

分布式锁实现二(value值比较放置误删，也就是说释放锁失败或者释放了其他的锁)：

@PostMapping("/buy02")
    public String buy02(Long gid){
        //获取redis分布式锁
        String uuid = UUID.randomUUID().toString().replace("-","");
        try{
            Boolean flag = redisTemplate.opsForValue().setIfAbsent(LOCK, uuid, 3L, TimeUnit.SECONDS);
            if (!flag){
                return "获取锁失败，商品减库存失败！";
            }
            log.info(uuid+" 获取锁成功！");
            //获取库存
            String nums = (String) redisTemplate.opsForValue().get("buy-" + gid);
            long totalNums = nums == null? 0: Integer.valueOf(nums);
            // 减库存
            if (totalNums >0){
                long nowTotal = totalNums -1;
                redisTemplate.opsForValue().set("buy-" + gid,String.valueOf(nowTotal));
                return "商品购买成功，当前库存量为："+nowTotal;
            }
        }catch (Exception e){

        }finally {
            /*
                释放锁优化1：
                    释放锁一定确认释放的是自己的锁

                   缺点：
                    因为我们还是分了两步首先先从redis中获取值，然后再删除锁。这两步redis的操作并不是原子性的。
                    可能会出现在刚获取值比较成功之后，还没有删除lock此时本身的key有效期到了，它就会自动
                    释放锁了，跟之前说的情况一样。
             */
            if (redisTemplate.opsForValue().get(LOCK).equals(uuid)){
                redisTemplate.delete(LOCK);
            }
        }
        return "减库存失败！";
       
    }

  • 该方式的实现跟方式一几乎差不多，只不过是在finally中释放锁的时候进行了一次锁value的校验，这样释放锁能够确保释放的是自己的锁而不是其他key的锁。

  • 缺陷: 在finally中我们先从redis中获取lock的值进行比较，然后再进行delete删除锁，但是这两个操作在redis中并不是原子性操作，在高并发下也可能会出现比较值成功了要马上删除锁，但是锁的时效时间却到了其他的key可以获取锁了，这时候就出现跟方式二类似的问题。

分布式锁实现三（lua脚本解决原子性删除问题）：

先准备两个lua文件放到resource目录下，lua脚本的内容分别如下:

@PostMapping("/buy03")
    public String buy02(Long gid){

        //获取redis分布式锁
        String uuid = UUID.randomUUID().toString().replace("-","");
        try{
            //泛型为 锁资源的类型  当前商品数量为Long型
            DefaultRedisScript<Long> redisScript = new DefaultRedisScript();
            redisScript.setResultType(Long.class);
            //指定lua脚本目录
            redisScript.setScriptSource(new ResourceScriptSource(new ClassPathResource("redis_lock.lua")));
            Object result = redisTemplate.execute(redisScript, Arrays.asList(LOCK), Collections.singletonList(uuid), 3);
            if ("0".equals(result)){
                return "抢夺分布式锁失败！，商品减库存失败！";
            }
            //            Boolean flag = redisTemplate.opsForValue().setIfAbsent(LOCK, uuid, 3L, TimeUnit.SECONDS);
//            if (!flag){
//                return "获取锁失败，商品减库存失败！";
//            }
            log.info(uuid+" 获取锁成功！");
            //获取库存
            String nums = (String) redisTemplate.opsForValue().get("buy-" + gid);
            long totalNums = nums == null? 0: Integer.valueOf(nums);
            // 减库存
            if (totalNums >0){
                long nowTotal = totalNums -1;
                redisTemplate.opsForValue().set("buy-" + gid,String.valueOf(nowTotal));
                return "商品购买成功，当前库存量为："+nowTotal;
            }
        }catch (Exception e){

        }finally {
            /*
                释放锁优化2：
                    Redis作者推荐使用Lua脚本进行加锁和释放锁。
                    （1）在Lua写入一些redis指令进行原子性操作，中间可以使用判断等逻辑处理
                    （2）使用RedisTemplate可以 运行加载并脚本

                 Lua不足之处：
                    Lua脚本的分布式锁的加锁和释放锁能够满足单机redis的需要，也满足很多中小型公司需要。
                    Lua脚本方式不能满足Redis集群模式的使用。
                    RedLock解决方式可以解决集群模式的分布式锁的使用，在集成框架Redssion中有实现。
             */
            DefaultRedisScript<Long> redisScript = new DefaultRedisScript();
            redisScript.setResultType(Long.class);
            //指定lua脚本目录
            redisScript.setScriptSource(new ResourceScriptSource(new ClassPathResource("redis_unlock.lua")));
            Object result = redisTemplate.execute(redisScript, Arrays.asList(LOCK), Collections.singletonList(uuid), 3);
            if ("0".equals(result)){
                log.info("释放锁失败！");
            }else{
                log.info("释放锁成功！");
            }
        }
        return "减库存失败！";
    }

缺陷: 无法适用到redis集群的复杂环境中。redis作者就推荐使用一种RedLock的锁解决redis集群分布式锁的问题，这里不再详细介绍RedLock了有兴趣可以去了解。目前RedLock在Redisson中有集成实现。

地中海未来
关注
redis分布式锁与zk分布式锁的对比
qq_27877781的博客
03-12 4116
·
redis分布式锁的问题与解决方法
09-09
本篇文章将深入探讨Redis分布式锁的问题及其解决方案。 首先，让我们了解什么是分布式锁。分布式锁是一种在分布式系统中协调不同节点对共享资源进行访问的机制。它主要用于解决并发场景下的数据一致性问题，防止多...
Java中synchronized关键字与ReentrantLock实现扣减库存
qq_37400096的博客
10-12 2566
本篇讲解单体应用中实现扣减库存，分别使用synchronized和ReentrantLock实现锁，不会出现扣除超卖的现象。
Redis实现分布式可重入锁——CAS操作
qq_26678049的博客
03-30 1907
WATCH：监控某些键值对；MULTI：用于开启一个事务；EXEC：执行事务；DISCARD：取消事务；UNWATCH：取消监控。通过watch命令，实现对某些Key的监听，当一个事务提交时，会优先检测监听的key是否发生改变，如果已发生改变，取消事务，若并未改变，执行事务。Lua是一种小巧的脚本语言，redis提供了对lua脚本执行的能力。通过将多个请求通过脚本的形式一次发送，redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。EVAL。
Redis实现分布式锁及其应用场景
Crime11的博客
04-13 2799
Redis实现分布式锁的原理是通过在Redis中创建一个key-value对，其中key为锁的名称，value为锁的值。当一个进程或线程需要获取锁时，它会向Redis发送一个SETNX命令，如果该命令返回1，则表示获取锁成功，否则获取锁失败。当一个用户下单时，它会尝试获取库存锁，如果获取成功，则可以继续下单，否则需要等待其他用户完成下单后再尝试获取锁。当一个任务开始执行时，它会尝试获取任务锁，如果获取成功，则可以执行任务，否则跳过任务。当任务执行完成后，会释放锁，其他任务就可以获取锁并执行。
Redis应用详解（一）分布式锁
博客
02-08 448
在某些场景中，多个进程必须以互斥的方式独占共享资源，这时用分布式锁是最直接有效的。随着技术快速发展，数据规模增大，分布式系统越来越普及，一个应用往往会部署在多台机器上（多节点），在有些场景中，为了保证数据不重复，要求在同一时刻，同一任务只在一个节点上运行，即保证某一方法同一时刻只能被一个线程执行。在单机环境中，应用是在同一进程下的，只需要保证单进程多线程环境中的线程安全性，通过 JAVA 提供的 volatile、ReentrantLock、synchronized 以及 concurrent 并发包下一些
Redis分布式锁及其常见问题解决方案
栗筝i的博客
09-21 5364
Redis 提供了一种简单有效的分布式锁实现方式。其基本思想是使用 Redis 的 SETNX 命令，这个命令可以在键不存在时设置值，如果键已存在则不做任何操作。通过这个原子操作，我们可以实现在多个节点之间的互斥访问。 然而，虽然 Redis 分布式锁的实现相对简单，但在实际使用中还需要考虑很多问题，例如锁的超时和续期问题、锁的公平性问题、网络分区的问题等。在接下来的文章中，我们将详细介绍这些问题以及解决方案。
Redis分布式锁及其应用场景
海角12138的博客
08-05 1889
RedLock分布式锁 基于 Redis 实现分布式锁的方式名叫 Redlock 安全特性：互斥访问，即永远只有一个 client 能拿到锁 避免死锁：最终 client 都可能拿到锁，不会出现死锁的情况，即使原本锁住某资源的 client crash 了或者出现了网络分区（两个完全不连通的区域，美国的网咱们登不上去） 容错性：只要大部分 Redis 节点存活就可以正常提供服务 Redis集群及应用场景 热点数据 存取数据优先从 Redis 操作，如果不存在再从文
redis分布式锁的实现问题与解决方案详解
qq_38917476的博客
10-17 1250
分布式锁是一种在分布式系统中用于控制多个节点对共享资源的并发访问的机制。它可以确保在分布式环境下，多个服务实例或进程在访问关键资源时不会发生竞争。分布式锁的目标是保证每次只有一个节点可以持有锁，并在操作完成后及时释放锁，以便其他节点可以继续操作资源。在分布式环境下，传统的单机锁（如Java中的或Lock）不再适用，因为这些锁无法在多个进程或服务器之间共享。因此，分布式锁的机制通常基于共享的存储系统（如Redis、Zookeeper等）来实现。
redis分布式锁及会出现的问题解决
12-14
以下是对Redis分布式锁及其可能出现的问题的详细解释： 1. **加锁原理** - **使用 SETNX 命令**：`SETNX` 是 `Set if Not eXists` 的缩写，当试图设置的键不存在时，才会设置成功。在分布式锁中，通常会以业务相关...
redis分布式锁.zip
06-08
本资料"redis分布式锁.zip"主要探讨了如何利用Redis实现分布式锁及其相关策略。 首先，分布式锁的基本概念是确保在分布式环境中，同一时刻只有一个客户端能够获取锁并执行临界区的代码。Redis提供的`SETNX`命令可以...
Redis-发布/订阅交互模式
sq2048935747@163.com的博客
10-31 392
消息代理”（Message Broker）是一种软件组件，它在不同的应用程序之间传递消息。在Redis的上下文中，消息代理的功能允许Redis作为一个中间人，帮助应用程序之间进行异步通信。具体来说，Redis支持发布/订阅（pub/sub）模式，这是一种消息传递机制，其中一个或多个发布者（publishers）发送消息到一个频道（channel），而订阅者（subscribers）监听这些频道以接收消息。
docker部署nginx+nacos+redis+java镜像和容器
xiaogg3678的专栏
11-01 881
docker部署nginx+nacos+redis+java镜像和容器
redis详细教程（5.AOP和RDB持久化）
2301_81490350的博客
10-30 531
AOF（Append Only File）日志和RDB（Redis Database Backup）持久化是Redis中两种重要的数据持久化机制。 RDB持久化机制原理RDB是Redis提供的一种数据快照保存机制，它将某个时间点的数据库状态保存到一个RDB文件中。这个文件非常适合用于灾难恢复，因为它是自包含的，并且可以被复制到任何其他支持RDB格式的Redis服务器上。 RDB RDB的触发方式有两种： 自动触发：Redis可以在配置文件中设置自动保存点，例如save 60 1000，意味着如果60
Redis ——发布订阅
weixin_62946182的博客
10-31 444
发布订阅：基于哈希表与链表结构实现 map结构key值保存用户订阅的兴趣事件，而value保存发布者对象信息，以链表的形式连接对同一事件感兴趣的对象，当消息队列中出现关于订阅事件的发布信息时，Redis可以快速的将该信息按照以key值对应的value链表为订阅的转发顺序；
Redis-基本全局命令
最新发布
ketil27的博客
11-04 250
Redis 有5种数据结构，但它们都是键值对种的值，对于键来说有⼀些通⽤的命令。返回所有满⾜样式（pattern）的key。⽀持如下统配样式。命令有效版本：1.0.0之后时间复杂度：O(N)返回值：匹配pattern的所有key。
用 Redis 查询 “附近的人”
周沐子
11-01 771
针对“附近的人”这一位置服务领域的应用场景，常见的可使用PG、MySQL和MongoDB等多种DB的空间索引进行实现。而Redis另辟蹊径，结合其有序队列zset以及geohash编码，实现了空间搜索功能，且拥有极高的运行效率。 本文将从源码角度对其算法原理进行解析，并推算查询时间复杂度。
Redis特性和应用场景以及安装
chaodddddd的博客
10-31 820
介绍Redis特性和应用场景以及安装
Redis 初学者指南
特立独行的博客
10-31 911
Redis是一个开源的、基于内存的、支持持久化的日志型Key-Value数据库。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值