Redis實現分佈式文件夾鎖

緣起

最近作一個項目，相似某度雲盤，另外附加定製功能，本人負責雲盤相關功能實現，這個項目跟雲盤不一樣的是，以項目爲分配權限的單位，同一個項目及子目錄全部有權限的用戶能夠同時操做全部文件，這樣就很容易出現併發操做，並且表結構設計的時候，定下來文件和文件夾都有個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=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=ARGV[1]
if redis.call('get', requestKey) == requestValue
then
    redis.call('hdel', lockedKeys,requestKey)
    return redis.call('del',requestKey)
else
    return 0
end複製代碼

優勢

1. 靈活，鎖定的範圍能夠隨requestKey變化而變化
2. 性能不錯，經測試除了第一次lua腳本未緩存耗時較長，第二次以後則在10ms左右可獲得請求結果

缺點

1. 可靠性依賴redis
2. 不是可重入鎖
3. 維護成本較高，需熟知redis的5種數據結構及lua腳本

總結

經過單元自測和測試環境測試基本能夠確保多數狀況下的多用戶併發操做文件只有一人能進行有效操做，保證了數據的安全性。通過此次實踐，對分佈式鎖有了更深刻的瞭解。

更多信息能夠關注個人我的博客：逸竹小站或逸竹小站