目錄原理剖析實(shí)現(xiàn)編寫注解攔截器攔截上述提及工具問題分析業(yè)務(wù)處理時間>上鎖過期時間

為了保證一個在高并發(fā)存場景下只能被同一個線程操作，java并發(fā)處理提供ReentrantLock或Synchronized進(jìn)行互斥控制。但是這僅僅對單機(jī)環(huán)境有效。我們實(shí)現(xiàn)分布式鎖大概通過三種方式。

redis實(shí)現(xiàn)分布式鎖 數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖 zk實(shí)現(xiàn)分布式鎖

實(shí)際上這三種和java對比看屬于一類。都是屬于程序外部鎖。

原理剖析

上述三種分布式鎖都是通過各自為依據(jù)對各個請求進(jìn)行上鎖，解鎖從而控制放行還是拒絕。redis鎖是基于其提供的setnx命令。setnx當(dāng)且僅當(dāng)key不存在。若給定key已經(jīng)存在，則setnx不做任何動作。setnx是一個原子性操作。和數(shù)據(jù)庫分布式相比，因為redis內(nèi)存輕量。所以redis分布式鎖性能更好

實(shí)現(xiàn)

原理很簡單。結(jié)合springboot項目我們實(shí)現(xiàn)一套通過注解形式對接口進(jìn)行庫存上鎖案例進(jìn)行理解

編寫注解

我們編寫注解。方便我們在接口上添加注解提供攔截信息

/** * @author 張新華 */@Target(ElementType.METHOD)@Retention(RetentionPolicy.RUNTIME)@Documented@Inheritedpublic @interface StockLock { /** * @author zxhtom * @Description 鎖key的前綴 * @Date 15:25 2020年03月25日, 0025 * @Param [] * @return java.lang.String */ String prefix() default ''; /** * @author zxhtom * @Description key的分隔符 * @Date 15:27 2020年03月25日, 0025 * @Param [] * @return java.lang.String */ String delimiter() default ':';}

/** * @author 張新華 */@Target({ElementType.PARAMETER , ElementType.METHOD , ElementType.FIELD})@Retention(RetentionPolicy.RUNTIME)@Documented@Inheritedpublic @interface StockParam { /** * @author zxhtom * @Description 組成key * @Date 11:11 2020年03月26日, 0026 * @Param [] * @return java.lang.String[] */ String[] names() default {''};}攔截器攔截

redis分布式鎖實(shí)現(xiàn)的關(guān)鍵就是攔截器的編寫。上面的注解只是為了實(shí)現(xiàn)攔截的一個輔助。

@Around('execution(public * *(..)) && @annotation(com.ay.framework.order.redis.product.StockLock)') 通過springboot的Around進(jìn)行針對StockLock注解的攔截。通過攔截我們可以獲取到攔截的方法、參數(shù)、及需要的鎖的參數(shù)。 我們獲取到需要鎖的名稱這里叫做【a】之后通過redis的原子性操作對該key進(jìn)行遞減操作。 為了方便我們在削減庫存的時候可以對庫存進(jìn)行更新操作。我們在遞減庫存前還需要借助于另一把鎖。 這一把鎖我們叫做【a_key】 換句話說我們接口想訪問就必須獲取【a】鎖，拿到【a】鎖需要減少庫存。減少庫存之前需要獲取【a_key】鎖。 拿到鎖之后處理完邏輯之后我們需要釋放對應(yīng)鎖。

RedisAtomicLong entityIdCounter = new RedisAtomicLong(lockKey, redisTemplate.getConnectionFactory()); if (redisTemplate.hasKey(CoreConstants.UPDATEPRODUCTREDISLOCKKEY + lockKey)) {//表示lockKey的庫存信息有變動。此時無法進(jìn)行交易throw new BusinessException('庫存變動。暫無法交易'); } Long increment = entityIdCounter.decrementAndGet(); if (increment >= 0) {try { Object proceed = pjp.proceed();} catch (Throwable throwable) { //所占資源需要釋放回資源池 while (!redisLock.tryGetLock(CoreConstants.UPDATEPRODUCTREDISLOCKKEY + lockKey, '')) { } //表示lockKey的庫存信息有變動。此時無法進(jìn)行交易 long l = entityIdCounter.incrementAndGet(); if (l < 1) {redisTemplate.opsForValue().set(lockKey,1); } redisLock.unLock(CoreConstants.UPDATEPRODUCTREDISLOCKKEY + lockKey); throwable.printStackTrace();} } else {redisTemplate.opsForValue().set(lockKey,0);throw new BusinessException('庫存不足！無法操作'); }

因為我們上鎖就需要釋放鎖。但是程序在中途處理業(yè)務(wù)是發(fā)生異常導(dǎo)致沒有走到釋放鎖的步驟。這個時候就導(dǎo)致我們的分布式鎖一直被鎖。俗稱【死鎖】。為了避免這種場景的發(fā)生。我們常常在上鎖的時候給一個有效期。有效期已過自動釋放鎖。這個特性恰好和redis的過期策略不摩爾和。

上述提及工具

RedisLock

public Boolean tryGetLock(String key , String value) { return tryGetLock(key, value, -1, TimeUnit.DAYS);}public Boolean tryGetLock(String key , String value, Integer expire) { return tryGetLock(key, value, expire, TimeUnit.SECONDS);}public Boolean tryGetLock(String key , String value, Integer expire , TimeUnit timeUnit) { ValueOperations operations = redisTemplate.opsForValue(); if (operations.setIfAbsent(key, value)) {//說明 redis沒有該key , 換言之 加鎖成功 設(shè)置過期時間防止死鎖if (expire > 0) { redisTemplate.expire(key, expire, timeUnit);}return true; } return false;}public Boolean unLock(String key) { return redisTemplate.delete(key);}

StockKeyGenerator

@Component()@Primarypublic class StockKeyGenerator implements CacheKeyGenerator { @Override public String getLockKey(ProceedingJoinPoint pjp) {//獲取方法簽名MethodSignature signature = (MethodSignature) pjp.getSignature();Method method = signature.getMethod();//獲取方法cacheLock注解StockLock stockLock = method.getAnnotation(StockLock.class);//獲取方法參數(shù)Object[] args = pjp.getArgs();Parameter[] parameters = method.getParameters();StringBuilder builder = new StringBuilder();for (int i = 0; i < parameters.length; i++) { StockParam stockParam = parameters[i].getAnnotation(StockParam.class); Object arg = args[i]; if (arg instanceof Map) {Map<String, Object> temArgMap = (Map<String, Object>) arg;String[] names = stockParam.names();for (String name : names) { if (builder.length() > 0) {builder.append(stockLock.delimiter()); } builder.append(temArgMap.get(name));} }}return builder.toString(); }}問題分析

上面分析了一個死鎖的場景，理論上出了死鎖我們redis分布鎖很好的解決了分布式問題。但是還是會出現(xiàn)問題。下面列舉寫小編遇到的問題。

業(yè)務(wù)處理時間>上鎖過期時間 a線程獲取到鎖，開始進(jìn)行業(yè)務(wù)處理需要8S， 在8S內(nèi)，鎖的有效期是5S，在鎖過期后也就是第6S ， b線程進(jìn)入開始獲取鎖這個時候b是可以獲取到新鎖的。這個時候就是有問題的。 假設(shè)b線程業(yè)務(wù)處理只需要3S ， 但是因為a線程釋放了鎖，所以在第8S的時候雖然b線程沒有釋放鎖，b的鎖也沒有過期但是這時候也沒有了鎖。從而導(dǎo)致C線程也可以進(jìn)入

以上就是Java基于redis實(shí)現(xiàn)分布式鎖的詳細(xì)內(nèi)容，更多關(guān)于Java 實(shí)現(xiàn)分布式鎖的資料請關(guān)注好吧啦網(wǎng)其它相關(guān)文章！