高并发环境下,Redisson实现redis分布式锁

原文:http://tlzl0526-gmail-com.iteye.com/blog/2378853

在一些高并发的场景中,比如秒杀,抢票,抢购这些场景,都存在对核心资源,商品库存的争夺,控制不好,库存数量可能被减少到负数,出现超卖的情况,或者 产生唯一的一个递增ID,由于web应用部署在多个机器上,简单的同步加锁是无法实现的,给数据库加锁的话,对于高并发,1000/s的并发,数据库可能由行锁变成表锁,性能下降会厉害。那相对而言,redis的分布式锁,相对而言,是个很好的选择,redis官方推荐使用的Redisson就提供了分布式锁和相关服务。 
下面介绍下如何使用Redisson。

Xml代码  

  1. <dependency>
  2. <groupId>org.redisson</groupId>
  3. <artifactId>redisson</artifactId>
  4. <version>2.7.0</version>
  5. </dependency>

使用redisson,最好采用redis 2.6.0以上版本,因为redosson一些后台命令采用eval的命令

Java代码  

  1. import org.redisson.Redisson;
  2. import org.redisson.api.RAtomicLong;
  3. import org.redisson.config.Config;
  4. public class RedissonManager {
  5. private static final String RAtomicName = "genId_";
  6. private static Config config = new Config();
  7. private static Redisson redisson = null;
  8. public static void init(String key,String value){
  9. try {
  10. /*            config.useClusterServers() //这是用的集群server
  11. .setScanInterval(2000) //设置集群状态扫描时间
  12. .setMasterConnectionPoolSize(10000) //设置连接数
  13. .setSlaveConnectionPoolSize(10000)
  14. .addNodeAddress("127.0.0.1:6379");*/
  15. if(key==null || "".equals(key)){
  16. key=RAtomicName;
  17. }
  18. config.useSingleServer().setAddress("127.0.0.1:6379");
  19. redisson = (Redisson) Redisson.create(config);
  20. //清空自增的ID数字
  21. RAtomicLong atomicLong = redisson.getAtomicLong(key);
  22. long pValue=1;
  23. if(value!=null && !"".equals(value)){
  24. pValue = Long.parseLong(value);
  25. }
  26. atomicLong.set(pValue);
  27. }catch (Exception e){
  28. e.printStackTrace();
  29. }
  30. }
  31. public static Redisson getRedisson(){
  32. return redisson;
  33. }
  34. /** 获取redis中的原子ID */
  35. public static Long nextID(){
  36. RAtomicLong atomicLong = getRedisson().getAtomicLong(RAtomicName);
  37. //原子性的获取下一个ID,递增1
  38. atomicLong.incrementAndGet();
  39. return atomicLong.get();
  40. }
  41. }

加锁和释放锁的方法,设置超时

Java代码  

  1. public class DistributedRedisLock {
  2. private static Redisson redisson = RedissonManager.getRedisson();
  3. private static final String LOCK_TITLE = "redisLock_";
  4. public static boolean acquire(String lockName){
  5. String key = LOCK_TITLE + lockName;
  6. RLock mylock = redisson.getLock(key);
  7. mylock.lock(2, TimeUnit.MINUTES); //lock提供带timeout参数,timeout结束强制解锁,防止死锁
  8. System.err.println("======lock======"+Thread.currentThread().getName());
  9. return  true;
  10. }
  11. public static void release(String lockName){
  12. String key = LOCK_TITLE + lockName;
  13. RLock mylock = redisson.getLock(key);
  14. mylock.unlock();
  15. System.err.println("======unlock======"+Thread.currentThread().getName());
  16. }
  17. }

在web端,controller中

Java代码  

  1. @RequestMapping("/redder")
  2. @ResponseBody
  3. public String redder() throws IOException{
  4. String key = "test123";
  5. DistributedRedisLock.acquire(key);
  6. Long result =  RedissonManager.nextID();
  7. DistributedRedisLock.release(key);
  8. return ""+result;
  9. }

程序首先要设置 RedissonManager.init("","");  进行初始化,这样的目的主要是可以根据实际情况,设置对应的信息,设置递增的初始值。

目前用jmeter的测试,1000的并发,确保ID设置为1001

原文地址:https://www.cnblogs.com/shihaiming/p/8535205.html

时间: 2024-10-10 11:17:24

高并发环境下,Redisson实现redis分布式锁的相关文章

高并发环境下生成唯一流水号

高并发环境下生成唯一流水号的主要思路有两种: 第一种是有一个控制全局的变量确保每个流水号的唯一性: 第二种是每台机器根据算法自己生成在系统中无冲突的流水号: 假设流水号的长度是128位(16字节): 第一种实现方法:(1)采用数据库的自增主键确保唯一性: Database.java package mine; import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import j

数据库 之 高并发环境下的规则

原文:数据库 之 高并发环境下的规则 本文大部分转至沈剑老师,加上自己的一些见解. 本文前提 高并发环境 规则要点 1) 数据库字符集使用utf8mb4 无乱码风险.万国码 2)禁止使用存储过程.视图.触发器.Event 高并发大数据的互联网业务,架构设计思路是"解放数据库CPU,将计算转移到服务层",并发量大的情况下,这些功能很可能将数据库拖死,业务逻辑放到服务层具备更好的扩展性,能够轻易实现"增机器就加性能".数据库擅长存储与索引,CPU计算还是上移吧 3)禁止

MQ在高并发环境下,如果队列满了,如何防止消息丢失?

1.为什么MQ能解决高并发环境下的消息堆积问题? MQ消息如果堆积,消费者不会立马消费所有的消息,不具有实时性,所以可以解决高并发的问题. 性能比较好的消息中间件:Kafka.RabbitMQ,RocketMQ. 2.什么情况下会产生消息丢失的现象? 消息队列满了的情况下. 3.如何解决消息丢失的问题? (1)生产者可以采用重试机制.因为消费者会不停的消费消息,可以重试将消息放入队列. 如果还是不行,可以将消息记录到数据库,后期做补偿.(不太推荐,不方便) (2)死信队列,可以理解为备胎.(推荐

如何在高并发环境下设计出无锁的数据库操作(Java版本) 转载

一个在线2k的游戏,每秒钟并发都吓死人.传统的hibernate直接插库基本上是不可行的.我就一步步推导出一个无锁的数据库操作. 1. 并发中如何无锁. 一个很简单的思路,把并发转化成为单线程.Java的Disruptor就是一个很好的例子.如果用java的concurrentCollection类去做,原理就是启动一个线程,跑一个Queue,并发的时候,任务压入Queue,线程轮训读取这个Queue,然后一个个顺序执行. 在这个设计模式下,任何并发都会变成了单线程操作,而且速度非常快.现在的n

高并发环境下低级死循环bug

业务背景 在内存中,对mq消息进行分类计数. 问题描述 生产环境,运行一段时间后,发现消息队列有大量堆积.如果把计数逻辑注释掉,只接收用户访问消息而不进行处理,则mq队列无堆积.mq栈dump信息如下: ConsumeMessageThread_75    TID: 214 STATE: WAITING ConsumeMessageThread_75    sun.misc.Unsafe.park(Native Method) ConsumeMessageThread_75    java.ut

【高并发】高并发环境下诡异的加锁问题(你加的锁未必安全)

声明 特此声明:文中有关支付宝账户的说明,只是用来举例,实际支付宝账户要比文中描述的复杂的多.也与文中描述的完全不同. 前言 很多网友留言说:在编写多线程并发程序时,我明明对共享资源加锁了啊?为什么还是出问题呢?问题到底出在哪里呢?其实,我想说的是:你的加锁姿势正确吗?你真的会使用锁吗?错误的加锁方式不但不能解决并发问题,而且还会带来各种诡异的Bug问题,有时难以复现! 在上一篇<[高并发]如何使用互斥锁解决多线程的原子性问题?这次终于明白了!>一文中,我们知道在并发编程中,不能使用多把锁保护

redis分布式锁深入

分布式架构中,高并发场景下,简单的线程锁无法保证线程安全,我们需要使用分布式锁来保证线程安全.在诸多的分布式锁实现中,redis分布式锁的应用应该是最为常见的,下面就让我们来看一下分布式锁实现中需要考虑到的诸多方面: 首先使用redis实现分布式锁需要用到redis的setnx key命令,(如果key不存在才允许设置) 下面我们来看一下redis分布式锁需要考虑的问题: 1.设置锁之后,解锁失败,即使使用try finally也是无法解决无法解锁的问题,因为分布式锁的设置时多个后端系统在争抢,

Redis分布式锁的实现原理

一.写在前面 现在面试,一般都会聊聊分布式系统这块的东西.通常面试官都会从服务框架(Spring Cloud.Dubbo)聊起,一路聊到分布式事务.分布式锁.ZooKeeper等知识. 所以咱们这篇文章就来聊聊分布式锁这块知识,具体的来看看Redis分布式锁的实现原理. 说实话,如果在公司里落地生产环境用分布式锁的时候,一定是会用开源类库的,比如Redis分布式锁,一般就是用Redisson框架就好了,非常的简便易用. 大家如果有兴趣,可以去看看Redisson的官网,看看如何在项目中引入Red

【分布式缓存系列】集群环境下Redis分布式锁的正确姿势

一.前言 在上一篇文章中,已经介绍了基于Redis实现分布式锁的正确姿势,但是上篇文章存在一定的缺陷——它加锁只作用在一个Redis节点上,如果通过sentinel保证高可用,如果master节点由于某些原因发生了主从切换,那么就会出现锁丢失的情况: 客户端1在Redis的master节点上拿到了锁 Master宕机了,存储锁的key还没有来得及同步到Slave上 master故障,发生故障转移,slave节点升级为master节点 客户端2从新的Master获取到了对应同一个资源的锁 于是,客