快捷導(dǎo)航

基于Redis的分布式鎖及原子性問題(短視頻開發(fā))

更新時間：2025年06月21日 09:00:29 作者：云豹科技-蘇凌霄

短視頻開發(fā)中,Redis分布式鎖通過SETNX實現(xiàn)加鎖與解鎖,需設(shè)置超時時間避免死鎖,為防止誤刪,釋放鎖時需判斷線程身份,并用Lua腳本保證原子性,確保安全操作,本文給大家介紹基于Redis的分布式鎖及原子性問題,感興趣的朋友一起看看吧

短視頻開發(fā)，基于Redis的分布式鎖及原子性問題

用 Redis 實現(xiàn)分布式鎖

主要應(yīng)用到的是 SETNX key value命令（如果不存在，則設(shè)置）

主要要實現(xiàn)兩個功能：

1、獲取鎖（設(shè)置一個 key）
2、釋放鎖（刪除 key）
基本思想是執(zhí)行了 SETNX命令的線程獲得鎖，在完成操作后，需要刪除 key，釋放鎖。

加鎖：

@Override
public boolean tryLock(long timeoutSec) {
    // 獲取線程標(biāo)示
    String threadId = ID_PREFIX + Thread.currentThread().getId();
    // 獲取鎖
    Boolean success = stringRedisTemplate.opsForValue()
            .setIfAbsent(KEY_PREFIX + name, threadId, timeoutSec, TimeUnit.SECONDS);
    return Boolean.TRUE.equals(success);
}

釋放鎖：

@Override
public void unlock() {
    // 獲取線程標(biāo)示
    String threadId = ID_PREFIX + Thread.currentThread().getId();
    // 獲取鎖中的標(biāo)示
    String id = stringRedisTemplate.opsForValue().get(KEY_PREFIX + name);
    // 釋放鎖
    stringRedisTemplate.delete(KEY_PREFIX + name);
}

可是這里會存在一個隱患——假設(shè)該線程發(fā)生阻塞（或者其他問題），一直不釋放鎖（刪除 key）這可怎么辦？

為了解決這個問題，我們需要為 key 設(shè)計一個超時時間，讓它超時失效；但是這個超時時間的長短卻不好確定：

1、設(shè)置過短，會導(dǎo)致其他線程提前獲得鎖，引發(fā)線程安全問題。
2、設(shè)置過長，線程需要額外等待。

鎖的誤刪

超時時間是一個非常不好把握的東西，因為業(yè)務(wù)線程的阻塞時間是不可預(yù)估的，在極端情況下，它總能阻塞到 lock 超時失效，正如上圖中的線程1，鎖超時釋放了，導(dǎo)致線程2也進(jìn)來了，這時候 lock 是線程2的鎖了（key 相同，value不同，value一般是線程唯一標(biāo)識）；假設(shè)這時候，線程1突然不阻塞了，它要釋放鎖，如果按照剛剛的代碼邏輯的話，它會釋放掉線程2的鎖；線程2的鎖被釋放掉之后，又會導(dǎo)致其他線程進(jìn)來（線程3），如此往復(fù)。。。

為了解決這個問題，需要在釋放鎖時多加一個判斷，每個線程只釋放自己的鎖，不能釋放別人的鎖！

釋放鎖

@Override
public void unlock() {
    // 獲取線程標(biāo)示
    String threadId = ID_PREFIX + Thread.currentThread().getId();
    // 獲取鎖中的標(biāo)示
    String id = stringRedisTemplate.opsForValue().get(KEY_PREFIX + name);
    // 判斷標(biāo)示是否一致
    if(threadId.equals(id)) {
        // 釋放鎖
        stringRedisTemplate.delete(KEY_PREFIX + name);
    }
}

原子性問題

剛剛我們談?wù)摰尼尫沛i的邏輯：

1、判斷當(dāng)前鎖是當(dāng)前線程的鎖
2、當(dāng)前線程釋放鎖
可以看到釋放鎖是分兩步完成的，如果你是對并發(fā)比較有感覺的話，應(yīng)該一下子就知道這里會存在問題了。

分步執(zhí)行，并發(fā)問題！

假設(shè) 線程1 已經(jīng)判斷當(dāng)前鎖是它的鎖了，正準(zhǔn)備釋放鎖，可偏偏這時候它阻塞了（可能是 FULL GC 引起的），鎖超時失效，線程2來加鎖，這時候鎖是線程2的了；可是如果線程1這時候醒過來，因為它已經(jīng)執(zhí)行了步驟1了的，所以這時候它會直接直接步驟2，釋放鎖（可是此時的鎖不是線程1的了）

其實這就是一個原子性的問題，剛剛釋放鎖的兩步應(yīng)該是原子的，不可分的！

要使得其滿足原子性，則需要在 Redis 中使用 Lua 腳本了。

引入 Lua 腳本保持原子性
lua 腳本：

-- 比較線程標(biāo)示與鎖中的標(biāo)示是否一致
if(redis.call('get', KEYS[1]) ==  ARGV[1]) then
    -- 釋放鎖 del key
    return redis.call('del', KEYS[1])
end
return 0

Java 中調(diào)用執(zhí)行：

public class SimpleRedisLock implements ILock {
?
    private String name;
    private StringRedisTemplate stringRedisTemplate;
?
    public SimpleRedisLock(String name, StringRedisTemplate stringRedisTemplate) {
        this.name = name;
        this.stringRedisTemplate = stringRedisTemplate;
    }
?
    private static final String KEY_PREFIX = "lock:";
    private static final String ID_PREFIX = UUID.randomUUID().toString(true) + "-";
    private static final DefaultRedisScript<Long> UNLOCK_SCRIPT;
    static {
        UNLOCK_SCRIPT = new DefaultRedisScript<>();
        UNLOCK_SCRIPT.setLocation(new ClassPathResource("unlock.lua"));
        UNLOCK_SCRIPT.setResultType(Long.class);
    }
?
    @Override
    public boolean tryLock(long timeoutSec) {
        // 獲取線程標(biāo)示
        String threadId = ID_PREFIX + Thread.currentThread().getId();
        // 獲取鎖
        Boolean success = stringRedisTemplate.opsForValue()
                .setIfAbsent(KEY_PREFIX + name, threadId, timeoutSec, TimeUnit.SECONDS);
        return Boolean.TRUE.equals(success);
    }
?
    @Override
    public void unlock() {
        // 調(diào)用lua腳本
        stringRedisTemplate.execute(
                UNLOCK_SCRIPT,
                Collections.singletonList(KEY_PREFIX + name),
                ID_PREFIX + Thread.currentThread().getId());
    }
}

到了目前為止，我們設(shè)計的 Redis 分布式鎖已經(jīng)是生產(chǎn)可用的，相對完善的分布式鎖了。

以上就是短視頻開發(fā)，基于Redis的分布式鎖及原子性問題，更多內(nèi)容歡迎關(guān)注之后的文章

到此這篇關(guān)于短視頻開發(fā)，基于Redis的分布式鎖及原子性問題的文章就介紹到這了,更多相關(guān)Redis的分布式鎖內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: