一、前言
在同一個jvm進程中時叛溢,可以使用JUC提供的一些鎖來解決多個線程競爭同一個共享資源時候的線程安全問題,但是當多個不同機器上的不同jvm進程共同競爭同一個共享資源時候劲适,juc包的鎖就無能無力了楷掉,這時候就需要分布式鎖了。常見的有使用zk的最小版本霞势,redis的set函數(shù)靖诗,數(shù)據(jù)庫鎖來實現(xiàn),本節(jié)我們談談Redis單實例情況下使用set函數(shù)來實現(xiàn)分布式鎖支示。
二刊橘、使用Redis單實例實現(xiàn)分布式鎖
首先我們來具體看代碼:
package com.jiaduo.DistributedLock;
import java.util.Collections;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
public class DistributedLock {
private static final String LOCK_SUCCESS = "OK";
private static final String SET_IF_NOT_EXIST = "NX";
private static final String SET_WITH_EXPIRE_TIME = "PX";
private static final Long RELEASE_SUCCESS = 1L;
private static void validParam(JedisPool jedisPool, String lockKey, String requestId, int expireTime) {
if (null == jedisPool) {
throw new IllegalArgumentException("jedisPool obj is null");
}
if (null == lockKey || "".equals(lockKey)) {
throw new IllegalArgumentException("lock key is blank");
}
if (null == requestId || "".equals(requestId)) {
throw new IllegalArgumentException("requestId is blank");
}
if (expireTime < 0) {
throw new IllegalArgumentException("expireTime is not allowed less zero");
}
}
/**
*
* @param jedis
* @param lockKey
* @param requestId
* @param expireTime
* @return
*/
public static boolean tryLock(JedisPool jedisPool, String lockKey, String requestId, int expireTime) {
validParam(jedisPool, lockKey, requestId, expireTime);
Jedis jedis = null;
try {
jedis = jedisPool.getResource();
String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);
if (LOCK_SUCCESS.equals(result)) {
return true;
}
} catch (Exception e) {
throw e;
} finally {
if (null != jedis) {
jedis.close();
}
}
return false;
}
/**
*
* @param jedis
* @param lockKey
* @param requestId
* @param expireTime
*/
public static void lock(JedisPool jedisPool, String lockKey, String requestId, int expireTime) {
validParam(jedisPool, lockKey, requestId, expireTime);
while (true) {
if (tryLock(jedisPool, lockKey, requestId, expireTime)) {
return;
}
}
}
/**
*
* @param jedis
* @param lockKey
* @param requestId
* @return
*/
public static boolean unLock(JedisPool jedisPool, String lockKey, String requestId) {
validParam(jedisPool, lockKey, requestId, 1);
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
Jedis jedis = null;
try {
jedis = jedisPool.getResource();
Object result = jedis.eval(script, Collections.singletonList(lockKey),
Collections.singletonList(requestId));
if (RELEASE_SUCCESS.equals(result)) {
return true;
}
} catch (Exception e) {
throw e;
} finally {
if (null != jedis) {
jedis.close();
}
}
return false;
}
}
首先Redis的 public String set(final String key, final String value, final String nxxx, final String expx,
final int time)方法參數(shù)說明:
- 其中前面兩個是key,value值;
- nxxx為模式颂鸿,這里我們設置為NX促绵,意思是說如果key不存在則插入該key對應的value并返回OK,否者什么都不做返回null嘴纺;
- 參數(shù)expx這里我們設置為PX败晴,意思是設置key的過期時間為time 毫秒
通過tryLock方法嘗試獲取鎖,內部是具體調用Redis的set方法栽渴,多個線程同時調用tryLock時候會同時調用set方法尖坤,但是set方法本身是保證原子性的,對應同一個key來說闲擦,多個線程調用set方法時候只有一個線程返回OK慢味,其它線程因為key已經存在會返回null,所以返回OK的線程就相當與獲取到了鎖墅冷,其它返回null的線程則相當于獲取鎖失敗纯路。
另外這里我們要保證value(requestId)值唯一是為了保證只有獲取到鎖的線程才能釋放鎖,這個下面釋放鎖時候會講解。
通過lock 方法讓使用tryLock獲取鎖失敗的線程本地自旋轉重試獲取鎖寞忿,這類似JUC里面的CAS驰唬。
Redis有一個叫做eval的函數(shù),支持Lua腳本執(zhí)行,并且能夠保證腳本執(zhí)行的原子性叫编,也就是在執(zhí)行腳本期間辖佣,其它執(zhí)行redis命令的線程都會被阻塞。這里解鎖時候使用下面腳本:
if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end
其中keys[1]為unLock方法傳遞的key搓逾,argv[1]為unLock方法傳遞的requestId;腳本redis.call('get', KEYS[1])的作用是獲取key對應的value值卷谈,這里會返回通過Lock方法傳遞的requetId, 然后看當前傳遞的RequestId是否等于key對應的值,等于則說明當前要釋放鎖的線程就是獲取鎖的線程恃逻,則繼續(xù)執(zhí)行redis.call('del', KEYS[1])腳本,刪除key對應的值藕施。
三寇损、總結
本文使用redis單實例結合redis的set方法和eval函數(shù)實現(xiàn)了一個簡單的分布式鎖,但是這個實現(xiàn)還是明顯有問題的裳食。雖然使用set方法設置了超時時間矛市,以避免線程獲取到鎖后redis掛了后鎖沒有被釋放的情況,但是超時時間設置為多少合適那诲祸?如果設置太小浊吏,可能會存在線程獲取鎖后執(zhí)行業(yè)務邏輯時間大于鎖超時時間,那么就會存在邏輯還沒執(zhí)行完救氯,鎖已經因為超時自動釋放了找田,而其他線程可能獲取到鎖,那么之前獲取鎖的線程的業(yè)務邏輯的執(zhí)行就沒有保證原子性着憨。
另外還有一個問題是Lock方法里面是自旋調用tryLock進行重試墩衙,這就會導致像JUC中的AtomicLong一樣,在高并發(fā)下多個線程競爭同一個資源時候造成大量線程占用cpu進行重試操作甲抖。這時候其實可以隨機生成一個等待時間漆改,等時間到后在進行重試,以減少潛在的同時對一個資源進行競爭的并發(fā)量准谚。
最后
想了解JDK NIO和更多Netty基礎的可以單擊我
想了解更多關于粘包半包問題單擊我
更多關于分布式系統(tǒng)中服務降級策略的知識可以單擊 單擊我
想系統(tǒng)學dubbo的單擊我
想學并發(fā)的童鞋可以 單擊我