Redisson semaphore使用实践

已于 2024-11-22 16:09:56 修改
阅读量182 收藏
点赞数 1
CC 4.0 BY-SA版权
分类专栏： Redis 文章标签： redis
于 2024-11-22 15:58:57 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/qq_30166465/article/details/143976326
  1. semaphore.isExists()方法
  • 当调用RedissonClient.getSemaphore(name)后得到一个semaphore，返回false。
  • 调用semaphore.addPermits(int)后返回true。
  • 当这个semaphore剩余许可为0的时候，返回true。
  • 调用semaphore.drainPermits()后，也返回true。
  • 当expire设置的时间过期时，才返回false。
redisson中Semaphore的信号量介绍及其原理
爪哇人的博客
07-06 4555
Semaphore通常叫信号量，可以用来同时控制访问特定资源的线程数量，通过协调各个线程，保证合理的使用资源。// 获得一个permit//获得var1个permit//尝试获得permit//尝试获得var1个permit//尝试获得permit, 等待时间var1//尝试获得var1个permit, 等待时间var2//释放1个permit//释放var1个permit//信号量的permits数//清空permits//设置permits数。
Redisson 源码初探（十） Semaphore 模式
wangxuelei036的博客
02-27 1625
redisson 内部实现的还有一种semaphore 信号量的模式，这个是个什么模式？ 大白话说就是资源池中存在一部分共享的资源，多个线程可以从资源池里面去获取资源，如果资源被获取完，那么其他向获取资源的线程就需要等待，别人释放资源。 其实逻辑很清晰 （1）设置资源池的数量 也就是设置对应的semaphore key的 value值 （2）尝试获取资源，如果足够 对资源池key 对应的value - 数量，如果不足够，进入死循环，不停的尝试获取 （3）释放资源，其实就是将对应的key的value.
Redisson之Semaphore使用记录
dailingnan0827的博客
10-22 8503
最近在公司一个项目需要用到限流，就想到concurrent包下的Semaphore（信号量）。不过实际场景中并不能用，一个原因是项目采用的微服务架构，分布式场景并不适用。第二个场景是限流采用令牌桶算法，每秒钟某个接口限流多少，超过丢弃。   后面实现采用的redis分布式限流方案，每分钟设置一个计数器，计数器一旦达到限流次数，后面的请求被直接挡回。   后面无意中看到有Redisson这个...
只用了半个Redisson的Semaphore实现并发控制
BASK2312的博客
02-10 211
线程池肯定是用不了了，我猛然想起前天晚上做梦，大师似乎跟我讲了信号量可以用来控制并发，考虑到线上环境有多个节点，同时Redisson也提供了Semaphore，打算用一下试试。所以新建了一个对象，封装一下获取和释放两个方法，之后项目中所有信号量的相关业务，都用这个对象，redisson的信号量概念就不会再出现在具体的业务中了，可以提高业务代码的可读性，也会信号量相关操作的修改控制在这个类中。企业微信的这个并发限制，没有明文规定，那上线之后，大概是要在违法的边缘多试探试探的，所以就涉及到更新信号量的问题了。
微服务SpringBoot整合Redis基于Redis的Stream消息队列实现异步秒杀下单
11-10
【微服务SpringBoot整合Redis基于Redis的Stream消息队列实现异步秒杀下单】这篇文章主要讲解了如何在微服务架构中使用SpringBoot整合Redis来构建...对于需要处理大量并发请求的微服务应用，这是一个有价值的实践方案。
springboot集成redisson的几种方式
weixin_44186675的博客
12-07 1965
本文主要描述springboot继承redisson的几种方式以及redisson分布式锁的使用；一、redisson简介？Redisson是架设在Redis基础上的一个Java驻内存数据网格（In-Memory Data Grid）。Redisson在基于NIO的Netty框架上，充分的利用了Redis键值数据库提供的一系列优势，在Java实用工具包中常用接口的基础上，为使用者提供了一系列具有分布式特性的常用工具类。
Redisson框架
hanxiaozhang的博客
06-29 1269
Redisson锁中，使用订阅发布模式去通知等待锁的客户端：锁已经释放，可以进行抢锁。
Redis教程(十九)：Redis的Redisson布隆过滤器
十三月的博客
05-27 899
布隆过滤器（Bloom Filter）是一种空间效率极高的概率型数据结构，用于快速检测一个元素是否存在于一个集合中。由于其独特的特性，布隆过滤器可以在需要节省空间且可以接受一定误判率的场合下，非常有效地使用。
群邑-品牌安全手册（英文）-2020.6-28页精品报告2020.pdf
04-24
在北欧的一项与丰田、Radisson Blue Group和Kvik合作的研究中，可见广告的在线转化率提高了83%（跟踪的宣传册下载）、67%（跟踪的房间预订）和79%（店内访问），分别体现了品牌安全对业绩提升的显著作用。...
Redisson中RSemaphore的使用场景及例子
qq_40592590的博客
08-01 752
redisson
【分布式锁】05-使用Redisson中Semaphore和CountDownLatch原理
meser88的博客
05-10 2127
前言 前面已经写了Redisson大多的内容，我们再看看Redisson官网共有哪些组件： 剩下还有Semaphore和CountDownLatch两块，我们就趁热打铁，赶紧看看Redisson是如何实现的吧。 我们在JDK中都知道Semaphore和CountDownLatch两兄弟，这里就不多赘述，不了解的可以再回头看看。 Semaphore使用示例 先看下Semaphore原理图如下： 接着我们看下Redisson中使用的案例： RSemaphore semaphore .
Redisson 的 AsyncSemaphore 源码剖析 聊聊 Semaphore 限流器
dying 搁浅
08-17 919
前阵子看了看 redisson 的源码，也搜看了些网上的一些文章，发现讲主逻辑和流程的文章比较多，而对于一些细节的实现做出解释的文章比较少，其实我的上一篇文章也是如此 ，所以在此对 redisson 分布式锁中使用到的数据结构逐个做下解析，一起学习下他们的设计逻辑和思想。......
redis面试（二十四）Semaphore锁实现
weixin_41011482的博客
08-27 623
redisson中semaphore锁的视线代码以及内部的lua原理
分布式锁—6.Redisson的同步器组件
weixin_55010563的博客
03-08 809
System.out.println(new Date() + "：线程[" + Thread.currentThread().getName() + "]成功获取到了Semaphore锁，开始工作");System.out.println(new Date() + "：线程[" + Thread.currentThread().getName() + "]收到通知，有3个线程都执行了countDown操作，可以继续往下执行");执行命令"get semaphore"，获取到semaphore的当前值。
Redisson的semaphore初始化在多个pod实例（jvm）的情况下 会被覆盖吗
NANA_Jp的博客
04-24 941
Redisson的semaphore初始化在多个pod实例（jvm）的情况下 会被覆盖吗 首先是结论，不会。 当我们在项目中使用redisson的时候，我们要首先给redisson内部设置一个信号量的大小。 @Configuration public class RedissonConfig { @Bean public RedissonClient redissonClient(){ Config config = new Config(); confi
分布式锁—Redisson的同步器组件
kfashfasf的博客
03-10 760
Redisson分布式锁包括：可重入锁、公平锁、联锁、红锁、读写锁。Semaphore也是Redisson支持的一种同步组件。Semaphore作为一个锁机制，可以允许多个线程同时获取一把锁。任何一个线程释放锁之后，其他等待的线程就可以尝试继续获取锁。CountDownLatch的基本原理：要求必须有n个线程来进行countDown，才能让执行await的线程继续执行。如果没有达到指定数量的线程来countDown，会导致执行await的线程阻塞。
Redisson分布式锁
范大的博客
01-11 7234
Redisson是一个在Redis的基础上实现的Java驻内存数据网格，它不仅提供了一系列的分布式的Java常用对象，还提供了许多分布式服务。
redision中锁续期线程是如何知道获取锁的线程结束或崩溃呢？
最新发布
08-02
<think>我们正在讨论Redisson的锁续期机制，特别是它如何检测持有锁的线程是否已经结束或崩溃。 根据引用[^1]，我们知道Redisson通过看门狗（Watchdog）机制来实现锁的续期。这个机制会定期检查持有锁的线程是否还活跃，如果活跃则延长锁的持有时间（即续期），如果线程已经结束或崩溃，则锁会被释放。 具体来说，Redisson的锁续期机制是通过一个后台线程（看门狗线程）来实现的。当客户端成功获取锁后，会启动一个看门狗线程，该线程会定期（默认是锁过期时间的1/3）去检查锁是否还被当前线程持有。如果锁仍然被当前线程持有，那么看门狗线程就会对锁进行续期（即重新设置锁的过期时间）。 那么，如何检测线程是否结束或崩溃呢？ 在Redisson中，当获取锁时，会记录当前线程的ID（在分布式环境中，这个ID通常由客户端生成，确保唯一性）。看门狗线程在续期时，会检查当前线程是否还存活（通过Java的Thread类提供的方法，如isAlive()方法）。如果线程已经终止（即不再存活），那么看门狗线程就不会再续期，从而让锁自然过期。 但是，这里有一个关键点：在分布式系统中，一个线程的崩溃（比如整个JVM崩溃）是无法通过另一个JVM（或另一个节点）来检测该线程是否存活的。因此，Redisson实际上并不是直接检测线程是否存活，而是通过以下方式： 1. 在同一个JVM内：如果持有锁的线程已经结束（正常结束或异常崩溃），那么看门狗线程（如果还在运行）会检测到当前线程已经不再存活，从而停止续期。但是，如果整个JVM崩溃，那么看门狗线程也会随之停止，因此不会进行续期操作。 2. 在分布式环境中：Redisson的锁续期机制依赖于与Redis的通信。看门狗线程会定期向Redis发送续期命令（通过Lua脚本）。如果持有锁的客户端崩溃了（比如整个JVM崩溃），那么看门狗线程也会停止，因此不会发送续期命令，锁在Redis中就会自动过期。 因此，看门狗机制的关键在于：它只在持有锁的客户端还存活并且能够与Redis通信的情况下才会续期。如果客户端崩溃，那么续期操作就会停止，锁就会自动释放。 总结一下，Redisson锁续期机制检测线程结束或崩溃的方式： - 对于同一个JVM内的线程结束：通过检查线程状态（isAlive()）来停止续期。 - 对于客户端崩溃（如JVM崩溃）：看门狗线程也会停止，因此不会续期，锁自动过期。 需要注意的是，锁的默认过期时间是30秒，看门狗线程每10秒（即30/3）续期一次，将锁的过期时间重置为30秒。 下面是一个简化的流程： 1. 线程A获取锁成功，Redisson启动一个看门狗线程（如果还没有的话）。 2. 看门狗线程每隔10秒检查一次： a. 检查当前线程（线程A）是否还持有该锁（通过比较Redis中存储的锁的值，该值包含了线程ID等信息）并且线程A是否还存活。 b. 如果线程A还持有锁且线程A还存活，则执行续期操作（将锁的过期时间重置为30秒）。 c. 如果线程A已经不再持有锁（比如被其他线程释放了）或者线程A已经结束（isAlive()返回false），则不再续期，并结束看门狗线程。 3. 如果线程A在持有锁期间崩溃（整个JVM崩溃），那么看门狗线程也会停止，因此不会续期，锁在30秒后自动过期。 这样，就避免了因为持有锁的线程崩溃而导致锁一直不被释放的问题。 引用[^1]提到了Radisson（应为Redisson）的看门狗机制，它类似于AQS的实现（在分布式环境中的实现），通过后台线程来监听锁的状态并续期。 因此，用户的问题得到解答：Redisson通过看门狗线程定期检查持有锁的线程是否存活（在同一个JVM内）以及通过续期操作的停止（在客户端崩溃时）来检测线程结束或崩溃。 现在，我们根据用户的问题，生成相关问题：</think>### Redisson 锁续期机制解析 Redisson 的锁续期机制（看门狗机制）通过以下方式检测线程结束或崩溃： 1. **线程状态监控** Redisson 在获取锁时为当前线程注册一个监控任务（看门狗线程），定期（默认10秒）检查持有锁的线程状态： - 通过 Java 的 `Thread.isAlive()` 方法判断线程是否存活 - 若线程已终止（`isAlive() == false`），立即停止续期并释放锁 - 示例代码逻辑： ```java if (!Thread.currentThread().isAlive()) { unlock(); // 释放锁 cancelRenewal(); // 停止续期 } ``` 2. **JVM 崩溃检测** 当整个 JVM 崩溃时： - 看门狗线程随进程终止而销毁 - Redis 中的锁 key 因**未续期而自动过期**（默认30秒） - 其他线程可在超时后重新获取锁 3. **续期失败处理** 续期操作通过 Redis Lua 脚本实现原子性验证： ```lua if redis.call("hexists", KEYS[1], ARGV[2]) == 1 then redis.call("pexpire", KEYS[1], ARGV[1]); return 1; end; return 0; ``` - 续期前验证线程ID是否匹配 - 若线程崩溃导致ID不匹配，续期失败触发锁释放 4. **双重超时保障** - **锁租约时间**：默认30秒，Redis 自动过期释放 - **续期间隔**：默认10秒（租约时间的1/3） - 任一超时均可触发锁释放 [^1] 引用说明：Redisson 通过线程状态检测和租约超时双重机制保障锁释放，避免因线程崩溃导致的死锁问题。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值