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腳本

總結

通過單元自測和測試環境測試基本可以確保多數情況下的多用戶並發操作文件只有一人能進行有效操作，保證了數據的安全性。經過這次實踐，對分布式鎖有了更深入的了解。

更多信息可以關注我的個人博客：逸竹小站

也歡迎關注我的公眾號：yizhuxiaozhan，二維碼：