
緣起
最近做一個專案,類似某度云盤,另外附加定制功能,本人負責云盤相關功能實作,這個專案跟云盤不同的是,以專案為分配權限的單位,同一個專案及子目錄所有有權限的用戶可以同時操作所有檔案,這樣就很容易出現并發操作,而且表結構設計的時候,定下來檔案和檔案夾都有個path欄位,存盤的是所在父級檔案夾路徑,這樣檢索方便,重命名和移動比較麻煩,
如下,例如甲同學正在移動專案下C檔案夾,而此時乙同學也在操作專案下D下的d.txt檔案,這樣就會出現問題,所以需要分布式鎖控制,甲在操作C檔案夾的時候,C檔案夾所有子檔案和包含C檔案夾的父檔案夾都被鎖住,如圖將會被鎖定的檔案夾和子檔案有:A、C、c.txt、D、E、d.txt,其中a.txt和B未被鎖定,這個是移動的情況,如下表格列出其他情況.

| 操作物件 | 操作 | 新建 | 上傳 | 移動檔案夾 | 移動檔案 | 復制檔案夾 | 復制檔案 | 重命名檔案夾 | 重命名檔案 | 洗掉檔案夾 | 洗掉檔案 | 回收站清除 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| /A | 新建 | √ | √ | × | √ | × | √ | × | √ | × | √ | / |
| /A | 上傳 | √ | √ | × | √ | × | √ | × | √ | × | √ | / |
| /A->/B | 移動檔案夾 | A×B× | A×B× | A×B× | A×B× | A√B√ | A√B√ | A×B× | A×B√ | A×B× | A×B√ | / |
| a.txt->/B | 移動檔案 | B√ | B√ | B× | B√ | B× | a√B× | a×B× | a×B√ | B× | a×B√ | / |
| /A->/B | 復制檔案夾 | B√ | B√ | B× | B√ | B√ | B√ | B× | B√ | B× | B√ | / |
| a.txt->/B | 復制檔案 | B√ | B√ | B× | B√ | B√ | B√ | B× | B√ | B× | B√ | / |
| /A | 重命名檔案夾 | A× | A× | A× | A× | A√ | A√ | A× | A× | A× | A× | / |
| a.txt | 重命名檔案 | / | / | × | × | × | × | √ | × | × | × | / |
| /A | 洗掉檔案夾 | × | × | × | × | × | × | × | × | × | × | / |
| a.txt | 洗掉檔案 | × | × | × | × | × | × | × | × | × | × | / |
| /A,a.txt | 回收站清除 | / | / | / | / | / | / | / | / | / | / | A×a× |
符號解釋:√:可以操作,×:不可以操作,/:互相不影響
整體解釋:例如第一行,意思是:對于A這個檔案夾,當第一個人進行新建操作的時候,其他人同時進行新建、上傳、移動檔案、復制檔案、重命名檔案、洗掉檔案是允許的,移動檔案夾、復制檔案夾、重命名檔案夾、洗掉檔案夾是不允許的,回收站清除和新建操作是互不影響的,
思考和調研
分布式鎖常見的三種實作方式:資料庫、zookeeper/etcd(臨時有序節點)、redis(setnx/lua腳本),各有千秋,
資料庫實作分布式鎖
實作
原理簡單易實作,創建一張lock表,存盤鎖定的資源、上鎖物件、獲取鎖的資源、獲取鎖時間等,獲取鎖時查詢該資源是否存在記錄,存在且未過失效時間則獲取鎖失敗,不存在則插入一條資料并且獲取鎖成功;釋放鎖則更簡單,洗掉鎖資料即可,
缺點
- 釋放鎖洗掉資料時,會出現死鎖情況
優點
- 實作簡單
zookeeper/etcd實作分布式鎖
詳見zookeeper總結
redis實作分布式鎖
詳見Redis總結
分布式檔案夾鎖實作程序
基于開文處所列情況,要覆寫所有復雜情況很難,但是實作基本的檔案夾鎖是必須的,故選擇了redis+lua腳本,具體代碼如下
java獲取鎖工具類
/**
* redis工具類
*/
public class RedisLockUtils {
static final Long SUCCESS = 1L;
static final String LOCKED_HASH = "cs:lockedHashKey";
static final String GET_LOCK_LUA_RESOURCE = "/lua/getFileLock.lua";
static final String RELEASE_LOCK_LUA_RESOURCE = "/lua/releaseFileLock.lua";
static final Logger LOG = LoggerFactory.getLogger(RedisLockUtils.class);
/**
* 獲取檔案夾鎖
* @param redisTemplate
* @param lockProjectId
* @param lockKey
* @param requestValue
* @param expireTime 單位:秒
* @return
*/
public static boolean getFileLock(RedisTemplate redisTemplate, Long lockProjectId, String lockKey, String requestValue, Integer expireTime) {
LOG.info("start run lua script,{{}} start request lock",lockKey);
long start = System.currentTimeMillis();
DefaultRedisScript<String> luaScript =new DefaultRedisScript<>();
luaScript.setLocation(new ClassPathResource(GET_LOCK_LUA_RESOURCE));
luaScript.setResultType(String.class);
Object result = redisTemplate.execute(
luaScript,
Arrays.asList(lockKey, LOCKED_HASH + lockProjectId),
requestValue,
String.valueOf(expireTime),
String.valueOf(System.currentTimeMillis())
);
boolean getLockStatus = SUCCESS.equals(result);
LOG.info("{{}} cost time {} ms,request lock result:{}",lockKey,(System.currentTimeMillis()-start), getLockStatus);
return getLockStatus;
}
/**
* 釋放檔案夾鎖
* @param redisTemplate
* @param lockProjectId
* @param lockKey
* @param requestValue
* @return
*/
public static boolean releaseFileLock(RedisTemplate redisTemplate, Long lockProjectId, String lockKey, String requestValue) {
DefaultRedisScript<String> luaScript =new DefaultRedisScript<>();
luaScript.setLocation(new ClassPathResource(RELEASE_LOCK_LUA_RESOURCE));
luaScript.setResultType(String.class);
Object result = redisTemplate.execute(
luaScript,
Arrays.asList(lockKey, LOCKED_HASH + lockProjectId),
requestValue
);
boolean releaseLockStatus = SUCCESS.equals(result);
LOG.info("{{}}release lock result:{}", lockKey, releaseLockStatus);
return releaseLockStatus;
}
}
lua腳本
獲取檔案夾鎖
入參說明
requestKey為請求鎖的路徑,requestValue為請求鎖的value,應為請求鎖時生成的UUID,確保解鎖人只能為上鎖人,lockedKeys為存放所有鎖的哈希表的key,這里用常量加專案id的方式,確保一個專案的所有鎖存在一個哈希表里面,expireTime為鎖的過期時間,nowTime為當前時間,由于lua腳本里面獲取當前時間消耗性能且獲取的是redis服務器上的當前時間,可能不準確,
思路說明
首先,通過GET key判斷是否有人正在操作這個檔案夾,若有人在操作則直接回傳0(獲取鎖失敗),否則獲取存放該專案鎖的哈希表里面的所有key,遍歷所有key,通過lua腳本的string.find函式對比該key和請求的key是否存在包含或被包含關系,若存在包含關系且未失效,則回傳0(獲取鎖失敗),否則則可獲取鎖,設定key和過期時間及存入哈希表(哈希表記憶體放請求鎖的key和請求時間),最后回傳1(獲取鎖成功),
例如請求上圖中專案下的C檔案夾的鎖,請求路徑為:專案/A/C,當另一個人想操作D檔案夾,請求路徑為:專案/A/C/D,此時查詢到存盤這個專案所有鎖定key的哈希表,里面包含專案/A/C這個key,這兩個key通過lua函式string.find發現專案/A/C/D包含專案/A/C,且未到過期時間,則獲取鎖失敗,否則獲取鎖成功,
local requestKey=KEYS[1]
local lockedKeys=KEYS[2]
local requestValue=https://www.cnblogs.com/coder2017/p/ARGV[1]
local expireTime=ARGV[2]
local nowTime=ARGV[3]
if redis.call('get',requestKey)
then
return 0
end
local lockedHash = redis.call('hkeys',lockedKeys)
for i=1, #lockedHash do
if string.find(requestKey,lockedHash[i]) or string.find(lockedHash[i],requestKey)
then
local lockTime = redis.call('hget',lockedKeys,lockedHash[i])
if (nowTime-lockTime) >= expireTime * 1000
then
redis.call('hdel',lockedKeys,lockedHash[i])
else
return 0
end
end
end
redis.call('set',requestKey,requestValue)
redis.call('expire',requestKey,expireTime)
redis.call('hset',lockedKeys,requestKey,nowTime)
return 1
釋放檔案夾鎖
入參說明
requestKey為請求鎖的路徑,requestValue為請求鎖的value,應為請求鎖時生成的UUID,確保解鎖人只能為上鎖人,lockedKeys為存放所有鎖的哈希表的key,這里用常量加專案id的方式,確保一個專案的所有鎖存在一個哈希表里面,
local requestKey=KEYS[1]
local lockedKeys=KEYS[2]
local requestValue=https://www.cnblogs.com/coder2017/p/ARGV[1]
if redis.call('get', requestKey) == requestValue
then
redis.call('hdel', lockedKeys,requestKey)
return redis.call('del',requestKey)
else
return 0
end
優點
- 靈活,鎖定的范圍可以隨
requestKey變化而變化 - 性能不錯,經測驗除了第一次lua腳本未快取耗時較長,第二次之后則在10ms左右可得到請求結果
缺點
- 可靠性依賴redis
- 不是可重入鎖
- 維護成本較高,需熟知redis的5種資料結構及lua腳本
總結
通過單元自測和測驗環境測驗基本可以確保多數情況下的多用戶并發操作檔案只有一人能進行有效操作,保證了資料的安全性,經過這次實踐,對分布式鎖有了更深入的了解,
更多資訊可以關注我的個人博客:逸竹小站
也歡迎關注我的公眾號:yizhuxiaozhan,二維碼:
轉載請註明出處,本文鏈接:https://www.uj5u.com/shujuku/37966.html
標籤:NoSQL
上一篇:Redis學習二(資料操作).
下一篇:Redis總結

