高并发下的分布式锁
public String deductStrck() throws InterruptedException{
String lockKey = "product_001"; //用作一把分布式锁
String clientId = UUID.randomUUID().toString(); //记录锁的id,防止别的线程可以解开这把锁
try{
//开始锁住
//设置超时时间目的是为了防止程序突然中断而造成的死锁现象
//锁的续命操作:时间设置为10,可以再开一个线程每3分钟检查一下看看这把锁是否存在,如果存在将过期时间再延长
Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey,clientId,10,TimeUnit.SECONDS)
if(!result){
return error;
}
//业务逻辑
int stock Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
if(stock>0){
int realStock = stock-1;
stringRedisTemplate.opsForValue().set("stock",realStock);
System.out.println("扣减成功,剩余库存"+realStock);
}else{
System.out.println("扣减失败,库存不足");
}
}finally{//最终要解开这把锁
if(clientId.equals(stringRedisTemplate.opsForValue().get(lockKey))){//防止别的线程可以解开这把锁
stringRedisTemplate.opsForValue().deleted(lockKey);
}
}
}
redisson提供完善的分布式锁:https://redisson.org
相关文章
- 如何应对缓存穿透和缓存雪崩问题
分析:这两个问题,说句实在话,一般中小型传统软件企业,很难碰到这个问题。如果有大并发的项目,流量有几百万左右。这两个问题一定要深刻考虑。 缓存穿透,即黑客故意去请求缓存中不存在的数据,导致所有的请
- gitlab备份与恢复
一、gitlab备份 [root@localhost ~]# gitlab-rake gitlab:backup:create Dumping database ... Dumping Postgr
- aof恢复与rdb服务器迁移
一、不小心flushall或flushdb了怎么办??? 只有aof还不够。 因为如果发生重写,aof文件里就什么都没有了。 所以要及时shutdown nosave,防止aof重写!!! 然后将a
- 路由器
- redis aof日志持久化
一、aof的原理 问题: 1、每个命令重写一次aof? 2、某个key修改100次,产生100行记录,aof文件会很大,怎么解决? aof重写(简化) 二、aof的配置 appendfsync
随机推荐
- 如何应对缓存穿透和缓存雪崩问题
分析:这两个问题,说句实在话,一般中小型传统软件企业,很难碰到这个问题。如果有大并发的项目,流量有几百万左右。这两个问题一定要深刻考虑。 缓存穿透,即黑客故意去请求缓存中不存在的数据,导致所有的请
- gitlab备份与恢复
一、gitlab备份 [root@localhost ~]# gitlab-rake gitlab:backup:create Dumping database ... Dumping Postgr
- aof恢复与rdb服务器迁移
一、不小心flushall或flushdb了怎么办??? 只有aof还不够。 因为如果发生重写,aof文件里就什么都没有了。 所以要及时shutdown nosave,防止aof重写!!! 然后将a
- 路由器
- redis aof日志持久化
一、aof的原理 问题: 1、每个命令重写一次aof? 2、某个key修改100次,产生100行记录,aof文件会很大,怎么解决? aof重写(简化) 二、aof的配置 appendfsync