基于redis实现分布式锁的原理与方法
前言
系统的不断扩大，分布式锁是最基本的保障。与单机的多线程不一样的是，分布式跨多个机器。线程的共享变量无法跨机器。
为了保证一个在高并发存场景下只能被同一个线程操作，java并发处理提供ReentrantLock或Synchronized进行互斥控制。但是这仅仅对单机环境有效。我们实现分布式锁大概通过三种方式。
- redis实现分布式锁
- 数据库实现分布式锁
- zk实现分布式锁
今天我们介绍通过redis实现分布式锁。实际上这三种和java对比看属于一类。都是属于程序外部锁。
原理剖析
- 上述三种分布式锁都是通过各自为依据对各个请求进行上锁，解锁从而控制放行还是拒绝。redis锁是基于其提供的setnx命令。
- setnx当且仅当key不存在。若给定key已经存在，则setnx不做任何动作。setnx是一个原子性操作。
- 和数据库分布式相比，因为redis内存轻量。所以redis分布式锁性能更好
实现
原理很简单。结合springboot项目我们实现一套通过注解形式对接口进行库存上锁案例进行理解
编写注解
我们编写注解。方便我们在接口上添加注解提供拦截信息
/**
*@author张新华
*@versionV1.0
*@Packagecom.ay.framework.order.redis.product
*@date2020年03月26日,002610:29
*@Copyright©2020安元科技有限公司
*/
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
public@interfaceStockLock{
/**
*@authorzxhtom
*@Description锁key的前缀
*@Date15:252020年03月25日,0025
*@Param[]
*@returnjava.lang.String
*/
Stringprefix()default"";
/**
*@authorzxhtom
*@Descriptionkey的分隔符
*@Date15:272020年03月25日,0025
*@Param[]
*@returnjava.lang.String
*/
Stringdelimiter()default":";
}
/**
*@author张新华
*@versionV1.0
*@Packagecom.ay.framework.order.redis.product
*@date2020年03月26日,002611:09
*@Copyright©2020安元科技有限公司
*/
@Target({ElementType.PARAMETER,ElementType.METHOD,ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
public@interfaceStockParam{
/**
*@authorzxhtom
*@Description组成key
*@Date11:112020年03月26日,0026
*@Param[]
*@returnjava.lang.String[]
*/
String[]names()default{""};
}
拦截器拦截
redis分布式锁实现的关键就是拦截器的编写。上面的注解只是为了实现拦截的一个辅助。
@Around("execution(public**(..))&&@annotation(com.ay.framework.order.redis.product.StockLock)")
通过springboot的Around进行针对StockLock注解的拦截。通过拦截我们可以获取到拦截的方法、参数、及需要的锁的参数。
我们获取到需要锁的名称这里叫做【a】之后通过redis的原子性操作对该key进行递减操作。
为了方便我们在削减库存的时候可以对库存进行更新操作。我们在递减库存前还需要借助于另一把锁。这一把锁我们叫做【a_key】
换句话说我们接口想访问就必须获取【a】锁，拿到【a】锁需要减少库存。减少库存之前需要获取【a_key】锁。
拿到锁之后处理完逻辑之后我们需要释放对应锁。
RedisAtomicLongentityIdCounter=newRedisAtomicLong(lockKey,redisTemplate.getConnectionFactory());
if(redisTemplate.hasKey(CoreConstants.UPDATEPRODUCTREDISLOCKKEY+lockKey)){
//表示lockKey的库存信息有变动。此时无法进行交易
thrownewBusinessException("库存变动。暂无法交易");
}
Longincrement=entityIdCounter.decrementAndGet();
if(increment>=0){
try{
Objectproceed=pjp.proceed();
}catch(Throwablethrowable){
//所占资源需要释放回资源池
while(!redisLock.tryGetLock(CoreConstants.UPDATEPRODUCTREDISLOCKKEY+lockKey,"")){
}
//表示lockKey的库存信息有变动。此时无法进行交易
longl=entityIdCounter.incrementAndGet();
if(l<1){
redisTemplate.opsForValue().set(lockKey,1);
}
redisLock.unLock(CoreConstants.UPDATEPRODUCTREDISLOCKKEY+lockKey);
throwable.printStackTrace();
}
}else{
redisTemplate.opsForValue().set(lockKey,0);
thrownewBusinessException("库存不足！无法操作");
}
因为我们上锁就需要释放锁。但是程序在中途处理业务是发生异常导致没有走到释放锁的步骤。这个时候就导致我们的分布式锁一直被锁。俗称【死锁】。为了避免这种场景的发生。我们常常在上锁的时候给一个有效期。有效期已过自动释放锁。这个特性恰好和redis的过期策略不摩尔和。
上述提及工具
RedisLock
publicBooleantryGetLock(Stringkey,Stringvalue){
returntryGetLock(key,value,-1,TimeUnit.DAYS);
}
publicBooleantryGetLock(Stringkey,Stringvalue,Integerexpire){
returntryGetLock(key,value,expire,TimeUnit.SECONDS);
}
publicBooleantryGetLock(Stringkey,Stringvalue,Integerexpire,TimeUnittimeUnit){
ValueOperationsoperations=redisTemplate.opsForValue();
if(operations.setIfAbsent(key,value)){
//说明redis没有该key,换言之加锁成功设置过期时间防止死锁
if(expire>0){
redisTemplate.expire(key,expire,timeUnit);
}
returntrue;
}
returnfalse;
}
publicBooleanunLock(Stringkey){
returnredisTemplate.delete(key);
}
StockKeyGenerator
@Component()
@Primary
publicclassStockKeyGeneratorimplementsCacheKeyGenerator{
@Override
publicStringgetLockKey(ProceedingJoinPointpjp){
//获取方法签名
MethodSignaturesignature=(MethodSignature)pjp.getSignature();
Methodmethod=signature.getMethod();
//获取方法cacheLock注解
StockLockstockLock=method.getAnnotation(StockLock.class);
//获取方法参数
Object[]args=pjp.getArgs();
Parameter[]parameters=method.getParameters();
StringBuilderbuilder=newStringBuilder();
for(inti=0;itemArgMap=(Map)arg;
String[]names=stockParam.names();
for(Stringname:names){
if(builder.length()>0){
builder.append(stockLock.delimiter());
}
builder.append(temArgMap.get(name));
}
}
}
returnbuilder.toString();
}
}
问题分析
上面分析了一个死锁的场景，理论上出了死锁我们redis分布锁很好的解决了分布式问题。但是还是会出现问题。下面列举写小编遇到的问题。
业务处理时间>上锁过期时间
a线程获取到锁，开始进行业务处理需要8S，
在8S内，锁的有效期是5S，在锁过期后也就是第6S，b线程进入开始获取锁这个时候b是可以获取到新锁的。这个时候就是有问题的。
假设b线程业务处理只需要3S，但是因为a线程释放了锁，所以在第8S的时候虽然b线程没有释放锁，b的锁也没有过期但是这时候也没有了锁。从而导致C线程也可以进入
总结
到此这篇基于redis实现分布式锁的原理与方法的文章就介绍到这了,更多相关redis分布式锁内容请搜索毛票票以前的文章或继续浏览下面的相关文章希望大家以后多多支持毛票票！