引言

在分布式系統(tǒng)中，實(shí)現(xiàn)高效的并發(fā)控制是一個永恒的話題。Redis作為一個高性能的鍵值存儲系統(tǒng)，因其出色的性能和豐富的功能被廣泛應(yīng)用于各種場景。其中，SETNX（SET if Not eXists）命令常被用作分布式鎖的實(shí)現(xiàn)基礎(chǔ)，但它的使用并非總是那么簡單。最近，我在項(xiàng)目中遇到了一個棘手的并發(fā)問題，最終花費(fèi)了三天時間才徹底解決。本文將詳細(xì)分析這個問題，探討其背后的原理，并分享最終的解決方案。

背景：分布式鎖的需求

在我們的系統(tǒng)中，有一個關(guān)鍵的業(yè)務(wù)邏輯需要保證在分布式環(huán)境下的原子性操作。例如，用戶在進(jìn)行余額扣減時，必須確保同一時間只有一個請求能夠成功執(zhí)行，否則可能會導(dǎo)致余額不一致的問題。為了實(shí)現(xiàn)這一點(diǎn)，我們決定使用Redis的SETNX命令來實(shí)現(xiàn)分布式鎖。

SETNX的基本原理是：當(dāng)且僅當(dāng)鍵不存在時，將鍵的值設(shè)置為指定的值，并返回1（表示成功）；如果鍵已經(jīng)存在，則返回0（表示失?。?。這種特性非常適合用來實(shí)現(xiàn)分布式鎖。

初版實(shí)現(xiàn)與問題

最初，我們的實(shí)現(xiàn)非常簡單：

local lock_key = "balance_lock:" .. user_id
local lock_value = "locked"
local lock_expire = 10 -- 鎖的過期時間，單位：秒
local acquired = redis.call("SETNX", lock_key, lock_value)
if acquired == 1 then
    redis.call("EXPIRE", lock_key, lock_expire)
    return true
else
    return false
end

這段代碼的邏輯看起來很合理：嘗試獲取鎖，如果成功，則設(shè)置鎖的過期時間；如果失敗，則直接返回。然而，在實(shí)際運(yùn)行中，我們遇到了兩個嚴(yán)重的問題：

1. 鎖無法釋放：在某些情況下，鎖沒有被正確釋放，導(dǎo)致后續(xù)請求無法獲取鎖。
2. 并發(fā)競爭：在高并發(fā)場景下，多個請求可能會同時獲取鎖，導(dǎo)致業(yè)務(wù)邏輯被重復(fù)執(zhí)行。

問題分析

1. 鎖無法釋放

鎖無法釋放的原因通常有兩種：

• 業(yè)務(wù)邏輯執(zhí)行時間超過鎖的過期時間，導(dǎo)致鎖自動釋放，但業(yè)務(wù)邏輯仍在執(zhí)行。
• 業(yè)務(wù)邏輯拋出異常，未能執(zhí)行鎖釋放的邏輯。

在我們的案例中，問題主要是第一種情況。由于鎖的過期時間設(shè)置較短（10秒），而某些業(yè)務(wù)邏輯的執(zhí)行時間可能超過10秒，導(dǎo)致鎖被提前釋放。此時，另一個請求可能會獲取到鎖，從而導(dǎo)致并發(fā)問題。

2. 并發(fā)競爭

在高并發(fā)場景下，SETNX和EXPIRE是兩個獨(dú)立的操作，不是原子性的。如果在SETNX成功之后、EXPIRE執(zhí)行之前，Redis實(shí)例崩潰或網(wǎng)絡(luò)中斷，那么鎖將無法設(shè)置過期時間，從而導(dǎo)致鎖永遠(yuǎn)無法釋放。雖然這種情況發(fā)生的概率較低，但在高并發(fā)的生產(chǎn)環(huán)境中仍有可能出現(xiàn)。

此外，即使鎖的過期時間設(shè)置正確，由于鎖的釋放是依賴過期時間的，可能會導(dǎo)致多個請求同時認(rèn)為自己獲取了鎖。例如：

• 請求A獲取鎖，設(shè)置過期時間為10秒。
• 請求A執(zhí)行耗時15秒的業(yè)務(wù)邏輯，鎖在第10秒時自動釋放。
• 請求B在第11秒時獲取鎖，開始執(zhí)行業(yè)務(wù)邏輯。
• 此時，請求A和請求B同時執(zhí)行業(yè)務(wù)邏輯，導(dǎo)致并發(fā)問題。

解決方案的探索

方案1：使用Lua腳本保證原子性

為了解決SETNX和EXPIRE的非原子性問題，我們可以使用Lua腳本將這兩個操作合并為一個原子操作：

local lock_key = "balance_lock:" .. user_id
local lock_value = "locked"
local lock_expire = 10 -- 鎖的過期時間，單位：秒
local acquired = redis.call("SET", lock_key, lock_value, "NX", "EX", lock_expire)
if acquired then
    return true
else
    return false
end

Redis的SET命令支持NX（等同于SETNX）和EX（設(shè)置過期時間）選項(xiàng)，可以原子性地完成這兩個操作。這解決了鎖無法設(shè)置過期時間的問題，但仍然無法解決業(yè)務(wù)邏輯執(zhí)行時間超過鎖過期時間的問題。

方案2：動態(tài)延長鎖的過期時間

為了解決業(yè)務(wù)邏輯執(zhí)行時間過長的問題，我們可以引入一個“看門狗”機(jī)制，定期檢查鎖是否仍然持有，并在需要時延長鎖的過期時間。以下是偽代碼實(shí)現(xiàn)：

- - 獲取鎖
local function acquire_lock(user_id)
    local lock_key = "balance_lock:" .. user_id
    local lock_value = generate_unique_id() -- 生成唯一ID
    local lock_expire = 10 -- 初始過期時間

    local acquired = redis.call("SET", lock_key, lock_value, "NX", "EX", lock_expire)
    if acquired then
- - 啟動看門狗線程，定期延長鎖的過期時間
        start_watchdog(lock_key, lock_value, lock_expire)
        return true
    else
        return false
    end
end

- - 釋放鎖
local function release_lock(user_id)
    local lock_key = "balance_lock:" .. user_id
    local lock_value = get_thread_local_value() -- 獲取當(dāng)前線程的鎖值

- - 只有鎖的值匹配時才釋放
    if redis.call("GET", lock_key) == lock_value then
        redis.call("DEL", lock_key)
        stop_watchdog()
        return true
    else
        return false
    end
end

這種方案的優(yōu)點(diǎn)是可以動態(tài)調(diào)整鎖的過期時間，避免鎖被提前釋放。缺點(diǎn)是實(shí)現(xiàn)復(fù)雜，需要維護(hù)額外的看門狗線程。

方案3：使用Redlock算法

對于對一致性要求更高的場景，可以使用Redis官方推薦的Redlock算法。Redlock的核心思想是：在多個獨(dú)立的Redis實(shí)例上獲取鎖，只有當(dāng)大多數(shù)實(shí)例都成功獲取鎖時，才認(rèn)為鎖獲取成功。

以下是Redlock的基本步驟：

1. 獲取當(dāng)前時間（T1）。
2. 依次嘗試在N個Redis實(shí)例上獲取鎖，使用相同的鍵和隨機(jī)值，并設(shè)置相同的過期時間。
3. 計(jì)算獲取鎖的總耗時（T2 - T1），如果耗時超過鎖的過期時間，或者未能在大多數(shù)實(shí)例上獲取鎖，則釋放所有鎖。
4. 如果鎖獲取成功，則執(zhí)行業(yè)務(wù)邏輯，并在完成后釋放鎖。

Redlock的優(yōu)點(diǎn)是在部分Redis實(shí)例故障時仍能保證鎖的安全性，缺點(diǎn)是實(shí)現(xiàn)復(fù)雜，性能較低。

最終解決方案

結(jié)合我們的業(yè)務(wù)場景和性能要求，我們最終選擇了方案1（原子性SET命令）和方案2（看門狗機(jī)制）的結(jié)合：

1. 使用SET命令的NX和EX選項(xiàng)原子性地獲取鎖并設(shè)置過期時間。
2. 為長時間執(zhí)行的業(yè)務(wù)邏輯啟動看門狗線程，定期延長鎖的過期時間。
3. 在釋放鎖時，檢查鎖的值是否匹配，避免誤刪其他請求的鎖。

以下是優(yōu)化后的實(shí)現(xiàn)：

- - 獲取鎖
local function acquire_lock(user_id)
    local lock_key = "balance_lock:" .. user_id
    local lock_value = generate_unique_id() -- 生成唯一ID
    local lock_expire = 10 -- 初始過期時間
    local acquired = redis.call("SET", lock_key, lock_value, "NX", "EX", lock_expire)
    if acquired then
- - 存儲鎖的值，用于后續(xù)釋放
        set_thread_local_value(lock_value)
- - 啟動看門狗線程
        start_watchdog(lock_key, lock_value, lock_expire)
        return true
    else
        return false
    end
end
- - 釋放鎖
local function release_lock(user_id)
    local lock_key = "balance_lock:" .. user_id
    local lock_value = get_thread_local_value()
- - 使用Lua腳本保證原子性
    local script = [[
        if redis.call("GET", KEYS[1]) == ARGV[1] then
            return redis.call("DEL", KEYS[1])
        else
            return 0
        end
    ]]
    local released = redis.call("EVAL", script, 1, lock_key, lock_value)
    if released == 1 then
        stop_watchdog()
        return true
    else
        return false
    end
end

總結(jié)

通過這次問題排查和解決，我深刻認(rèn)識到分布式鎖的實(shí)現(xiàn)并非表面上那么簡單。SETNX雖然是一個強(qiáng)大的工具，但在高并發(fā)場景下需要額外注意以下幾點(diǎn)：

1. 原子性操作：確保鎖的獲取和設(shè)置過期時間是原子性的，避免中間狀態(tài)。
2. 鎖的釋放：只有鎖的持有者才能釋放鎖，避免誤刪其他請求的鎖。
3. 鎖的續(xù)約：對于長時間執(zhí)行的業(yè)務(wù)邏輯，需要動態(tài)延長鎖的過期時間。
4. 容錯性：在極端情況下（如Redis實(shí)例崩潰），需要有備選方案保證系統(tǒng)可用性。

最終，我們的解決方案結(jié)合了Redis的原子性操作和看門狗機(jī)制，既保證了性能，又提高了可靠性。這次經(jīng)歷讓我對分布式系統(tǒng)的并發(fā)控制有了更深的理解，也讓我明白了在技術(shù)選型時不能只看表面，而需要深入思考其適用場景和潛在問題。

到此這篇關(guān)于Redis的SETNX并發(fā)問題的解決的文章就介紹到這了,更多相關(guān)Redis SETNX并發(fā)內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論