在分布式系統(tǒng)中，Redis 分布式鎖雖能高效解決跨服務(wù)并發(fā)沖突，但實際落地時稍不注意就會踩坑——小到數(shù)據(jù)不一致，大到服務(wù)雪崩，這些問題多源于對 Redis 特性、分布式場景復(fù)雜性的考慮不周。之前開發(fā)電商庫存和訂單系統(tǒng)時，就因忽視了鎖過期、腦裂等問題，先后出現(xiàn)過超賣、鎖失效等故障。今天結(jié)合生產(chǎn)實戰(zhàn)經(jīng)驗，梳理 Redis 實現(xiàn)分布式鎖時最易遇到的 8 大問題，逐一拆解成因、表現(xiàn)及根治方案，幫大家避開這些“隱形炸彈”。

先明確前提：分布式鎖的核心是“互斥性”，但在分布式環(huán)境下，網(wǎng)絡(luò)延遲、服務(wù)宕機、Redis 集群同步延遲等因素，都會破壞鎖的穩(wěn)定性。所有問題的本質(zhì)，要么是“原子性缺失”，要么是“高可用考慮不足”，要么是“業(yè)務(wù)與鎖機制不匹配”。

一、核心問題及解決方案（按踩坑頻率排序）

問題 1：誤刪他人持有鎖——最基礎(chǔ)也最易犯的漏洞

成因：釋放鎖時未做身份校驗，直接執(zhí)行 DEL 命令刪除鍵。典型場景：服務(wù) A 持有鎖后，業(yè)務(wù)邏輯耗時超過鎖過期時間，鎖被自動釋放；服務(wù) B 趁機加鎖成功，此時服務(wù) A 執(zhí)行完業(yè)務(wù)，直接 DEL 鎖就會誤刪服務(wù) B 持有的鎖，導(dǎo)致互斥性失效。

表現(xiàn)：多個服務(wù)實例同時持有同一把鎖，操作同一資源，出現(xiàn)數(shù)據(jù)不一致（如超賣、重復(fù)訂單）。

解決方案：加鎖時存入全局唯一的隨機值（如 UUID+線程 ID）作為 value，釋放鎖前先驗證 value 是否與自身持有一致，一致才釋放。關(guān)鍵是用 Lua 腳本保證“驗證+刪除”的原子性，避免驗證后鎖過期被他人持有。

-- 安全釋放鎖的 Lua 腳本
if redis.call('get', KEYS[1]) == ARGV[1] then
    return redis.call('del', KEYS[1])
else
    return 0
end

注意：嚴(yán)禁拆分“驗證”和“刪除”為兩步操作，否則仍存在并發(fā)漏洞。

問題 2：鎖過期提前釋放——業(yè)務(wù)未做完鎖已失效

成因：鎖的過期時間設(shè)置過短，而業(yè)務(wù)邏輯執(zhí)行耗時過長，導(dǎo)致鎖在業(yè)務(wù)完成前就自動過期釋放，其他服務(wù)可趁機加鎖，引發(fā)并發(fā)沖突。比如鎖設(shè)為 30 秒過期，但數(shù)據(jù)庫復(fù)雜查詢、第三方接口調(diào)用耗時 40 秒，就會出現(xiàn)鎖提前失效。

表現(xiàn)：業(yè)務(wù)執(zhí)行中鎖被釋放，多個服務(wù)同時操作資源，出現(xiàn)數(shù)據(jù)錯誤，且問題具有隨機性（取決于業(yè)務(wù)耗時是否超過過期時間）。

解決方案：引入“鎖續(xù)約（Watch Dog）”機制。服務(wù)成功加鎖后，啟動后臺守護線程，每隔鎖過期時間的 1/3 （如 10 秒）檢查鎖是否仍被自身持有，若持有則延長鎖的過期時間（重置為 30 秒），直到業(yè)務(wù)完成主動釋放鎖。

實際開發(fā)中無需手動實現(xiàn)，Redisson 框架內(nèi)置 Watch Dog 機制，加鎖后自動續(xù)約，徹底解決鎖提前釋放問題。

問題 3：Redis 單點故障——鎖服務(wù)整體不可用

成因：Redis 采用單點部署，當(dāng) Redis 服務(wù)宕機（如進程崩潰、服務(wù)器斷電），所有分布式鎖的加鎖、釋放操作都會失敗，導(dǎo)致分布式系統(tǒng)的并發(fā)控制機制崩潰，無法正常處理資源競爭。

表現(xiàn)：所有依賴分布式鎖的業(yè)務(wù)接口報錯，無法執(zhí)行（如庫存扣減、訂單創(chuàng)建接口），甚至引發(fā)服務(wù)雪崩。

解決方案：采用 Redis 高可用集群部署，兩種主流方案按需選擇：

• 主從復(fù)制 + 哨兵模式：部署 1 主多從 Redis 集群，哨兵實時監(jiān)控主節(jié)點狀態(tài)，主節(jié)點宕機時自動將從節(jié)點切換為主節(jié)點，保證 Redis 服務(wù)連續(xù)性。缺點是存在“腦裂”風(fēng)險（主從數(shù)據(jù)同步延遲導(dǎo)致鎖丟失），適合對一致性要求一般的場景。
• Redlock 算法：向至少 3 個獨立的 Redis 主節(jié)點發(fā)起加鎖請求，僅當(dāng)超過半數(shù)節(jié)點加鎖成功，且總耗時不超過超時時間，才算加鎖成功。即使部分節(jié)點宕機，只要多數(shù)節(jié)點正常，鎖服務(wù)就可用，徹底避免單點故障和腦裂問題，適合高一致性場景。Redisson 已內(nèi)置 Redlock 實現(xiàn)，開箱即用，以下是完整實戰(zhàn)配置與代碼：

1. 多組獨立 Redis 節(jié)點配置（YML）

Redlock 要求節(jié)點物理獨立（避免同一機房故障牽連多組節(jié)點），每組節(jié)點可單獨部署主從+哨兵提升可用性，3 組節(jié)點完整配置如下：

spring:
  redis:
    # Redlock 專用多組獨立節(jié)點配置
    redlock:
      # 第一組節(jié)點（可部署主從+哨兵）
      node1:
        host: 192.168.1.101
        port: 6379
        password: 123456
        database: 0
        timeout: 5000  # 連接超時時間（毫秒）
      # 第二組節(jié)點（獨立服務(wù)器，與第一組無關(guān)聯(lián)）
      node2:
        host: 192.168.1.102
        port: 6379
        password: 123456
        database: 0
        timeout: 5000
      # 第三組節(jié)點（獨立服務(wù)器，建議跨機房）
      node3:
        host: 192.168.1.103
        port: 6379
        password: 123456
        database: 0
        timeout: 5000

2. Redisson 客戶端配置（多節(jié)點實例化）

通過配置類讀取 YML 信息，創(chuàng)建對應(yīng) RedissonClient 實例，保證每組節(jié)點獨立連接：

@Configuration
public class RedissonRedlockConfig {
    // 第一組 Redlock 節(jié)點客戶端
    @Bean(name = "redlockClient1")
    public RedissonClient redlockClient1(
            @Value("${spring.redis.redlock.node1.host}") String host,
            @Value("${spring.redis.redlock.node1.port}") int port,
            @Value("${spring.redis.redlock.node1.password}") String password,
            @Value("${spring.redis.redlock.node1.database}") int database,
            @Value("${spring.redis.redlock.node1.timeout}") int timeout) {
        Config config = new Config();
        // 單節(jié)點模式（若為集群，可改用 useSentinelServers 配置哨兵）
        config.useSingleServer()
                .setAddress("redis://" + host + ":" + port)
                .setPassword(password)
                .setDatabase(database)
                .setTimeout(timeout);
        return Redisson.create(config);
    }
    // 第二組 Redlock 節(jié)點客戶端
    @Bean(name = "redlockClient2")
    public RedissonClient redlockClient2(
            @Value("${spring.redis.redlock.node2.host}") String host,
            @Value("${spring.redis.redlock.node2.port}") int port,
            @Value("${spring.redis.redlock.node2.password}") String password,
            @Value("${spring.redis.redlock.node2.database}") int database,
            @Value("${spring.redis.redlock.node2.timeout}") int timeout) {
        Config config = new Config();
        config.useSingleServer()
                .setAddress("redis://" + host + ":" + port)
                .setPassword(password)
                .setDatabase(database)
                .setTimeout(timeout);
        return Redisson.create(config);
    }
    // 第三組 Redlock 節(jié)點客戶端
    @Bean(name = "redlockClient3")
    public RedissonClient redlockClient3(
            @Value("${spring.redis.redlock.node3.host}") String host,
            @Value("${spring.redis.redlock.node3.port}") int port,
            @Value("${spring.redis.redlock.node3.password}") String password,
            @Value("${spring.redis.redlock.node3.database}") int database,
            @Value("${spring.redis.redlock.node3.timeout}") int timeout) {
        Config config = new Config();
        config.useSingleServer()
                .setAddress("redis://" + host + ":" + port)
                .setPassword(password)
                .setDatabase(database)
                .setTimeout(timeout);
        return Redisson.create(config);
    }
}

3. Redlock 加鎖/釋放鎖業(yè)務(wù)代碼

通過 RedissonRedLock 組合多節(jié)點鎖，自動觸發(fā)投票邏輯，兼容普通鎖用法，內(nèi)置 Watch Dog 續(xù)約：

@Service
public class StockService {
    @Autowired
    @Qualifier("redlockClient1")
    private RedissonClient redlockClient1;
    @Autowired
    @Qualifier("redlockClient2")
    private RedissonClient redlockClient2;
    @Autowired
    @Qualifier("redlockClient3")
    private RedissonClient redlockClient3;
    @Autowired
    private StockMapper stockMapper;
    public void deductStock(Long productId) {
        // 1. 生成統(tǒng)一鎖Key，獲取多節(jié)點鎖對象
        String lockKey = "lock:stock:" + productId;
        RLock lock1 = redlockClient1.getLock(lockKey);
        RLock lock2 = redlockClient2.getLock(lockKey);
        RLock lock3 = redlockClient3.getLock(lockKey);
        // 2. 組合為Redlock鎖，觸發(fā)多節(jié)點投票
        RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3);
        try {
            // 3. 加鎖：1秒內(nèi)等待節(jié)點響應(yīng)，鎖過期時間30秒（內(nèi)置續(xù)約）
            boolean locked = redLock.tryLock(1000, 30000, TimeUnit.MILLISECONDS);
            if (locked) {
                // 4. 核心業(yè)務(wù)：庫存扣減（僅保留鎖內(nèi)必要操作）
                Stock stock = stockMapper.selectById(productId);
                if (stock != null && stock.getCount() > 0) {
                    stock.setCount(stock.getCount() - 1);
                    stockMapper.updateById(stock);
                }
            } else {
                // 加鎖失敗兜底
                throw new RuntimeException("系統(tǒng)繁忙，請稍后再試");
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            throw new RuntimeException("操作被中斷，請重試");
        } finally {
            // 5. 安全釋放鎖：僅當(dāng)前線程持有鎖時執(zhí)行
            if (redLock.isHeldByCurrentThread()) {
                redLock.unlock();
            }
        }
    }
}

關(guān)鍵說明：① 多組節(jié)點需物理隔離，跨機房部署可提升容錯；② 3 組節(jié)點最多允許 1 組故障，超過半數(shù)節(jié)點加鎖成功即生效；③ 釋放鎖時自動同步清理所有節(jié)點鎖數(shù)據(jù)，無需手動協(xié)調(diào)。

問題 4：鎖無法重入——嵌套業(yè)務(wù)死鎖

成因：基礎(chǔ)實現(xiàn)的鎖不支持重入，即同一服務(wù)的同一線程在持有鎖的情況下，再次請求加同一把鎖會失敗。典型場景：服務(wù) A 加鎖后，執(zhí)行的方法中又調(diào)用了另一個需要加同一把鎖的方法，第二次加鎖失敗，導(dǎo)致線程阻塞，引發(fā)死鎖。

表現(xiàn)：業(yè)務(wù)線程阻塞，接口超時無響應(yīng)，排查后發(fā)現(xiàn)是同一線程重復(fù)加鎖被拒。

解決方案：實現(xiàn)可重入鎖機制。鎖的 value 存儲“唯一標(biāo)識 + 重入次數(shù)”，第一次加鎖時存入標(biāo)識和次數(shù) 1；同一線程再次加鎖時，驗證標(biāo)識一致，將次數(shù)加 1；釋放鎖時，次數(shù)減 1，直到次數(shù)為 0 才刪除鍵徹底釋放鎖。

手動實現(xiàn)邏輯復(fù)雜，推薦使用 Redisson 的 RLock 接口，天然支持可重入，用法與本地 synchronized 鎖一致，無需額外開發(fā)。

問題 5：主從切換鎖丟失（腦裂）——集群環(huán)境下的隱形坑

成因：Redis 主從集群中，主節(jié)點存儲鎖數(shù)據(jù)后，尚未同步到從節(jié)點就宕機；哨兵將從節(jié)點切換為主節(jié)點，新主節(jié)點無該鎖數(shù)據(jù)，其他服務(wù)可重新加鎖，導(dǎo)致原鎖失效，出現(xiàn)多個服務(wù)持有鎖的情況。這是主從 + 哨兵模式的固有風(fēng)險。

表現(xiàn)：主從切換后，原持有鎖的服務(wù)仍在執(zhí)行業(yè)務(wù)，新服務(wù)卻能加鎖成功，引發(fā)數(shù)據(jù)沖突，且問題難以復(fù)現(xiàn)（僅發(fā)生在主從切換瞬間）。

解決方案：

• 低一致性場景：開啟 Redis 主從同步的“持久化 + 等待同步確認(rèn)”，主節(jié)點寫入鎖數(shù)據(jù)后，等待至少 1 個從節(jié)點同步完成再返回加鎖成功，降低鎖丟失概率（仍無法完全避免）。
• 高一致性場景：放棄主從 + 哨兵模式，改用 Redlock 算法，通過多主節(jié)點投票機制，從根源上解決腦裂導(dǎo)致的鎖丟失問題。

問題 6：加鎖失敗無重試策略——業(yè)務(wù)偶發(fā)失敗

成因：加鎖時僅嘗試一次，若因網(wǎng)絡(luò)波動、Redis 臨時繁忙導(dǎo)致加鎖失敗，直接拋出異常，導(dǎo)致業(yè)務(wù)執(zhí)行失敗。分布式環(huán)境中，網(wǎng)絡(luò)抖動、Redis 瞬時壓力大是常見情況，無重試策略會放大這類問題的影響。

表現(xiàn)：部分用戶操作失?。ㄈ缣峤挥唵翁崾?ldquo;系統(tǒng)繁忙”），重試后可成功，問題具有隨機性。

解決方案：實現(xiàn)帶限制的重試機制，加鎖失敗后，間隔一定時間（如 100ms）重試，同時設(shè)置最大重試次數(shù)（如 3 次）和總超時時間（如 1 秒），避免無限重試導(dǎo)致 Redis 壓力過大，也能提升加鎖成功率。

// 帶重試的加鎖邏輯（Spring Data Redis 示例）
public boolean lockWithRetry(String key, String value, long expireMs, int maxRetry, long retryIntervalMs) {
    for (int i = 0; i < maxRetry; i++) {
        Boolean result = redisTemplate.opsForValue().setIfAbsent(key, value, expireMs, TimeUnit.MILLISECONDS);
        if (Boolean.TRUE.equals(result)) {
            return true;
        }
        try {
            Thread.sleep(retryIntervalMs);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return false;
        }
    }
    return false;
}

問題 7：長時間持有鎖——系統(tǒng)并發(fā)量驟降

成因：在鎖的范圍內(nèi)執(zhí)行耗時操作（如復(fù)雜數(shù)據(jù)庫查詢、第三方接口調(diào)用、大量數(shù)據(jù)處理），導(dǎo)致鎖持有時間過長，其他服務(wù)請求該鎖時被長時間阻塞，系統(tǒng)吞吐量大幅下降。

表現(xiàn)：依賴該鎖的接口響應(yīng)時間變長，并發(fā)量上不去，監(jiān)控顯示大量線程阻塞在加鎖環(huán)節(jié)。

解決方案：

• 精簡鎖內(nèi)業(yè)務(wù)：僅將“資源競爭核心邏輯”（如庫存扣減、訂單狀態(tài)修改）放入鎖內(nèi)，非核心邏輯（如日志記錄、消息推送）移至鎖外執(zhí)行。
• 異步化處理：若鎖內(nèi)必須執(zhí)行耗時操作，將其異步化（如用線程池、消息隊列），縮短鎖持有時間。
• 設(shè)置鎖持有超時預(yù)警：通過監(jiān)控工具統(tǒng)計鎖持有時間，超過閾值（如 20 秒）時告警，及時排查耗時業(yè)務(wù)。

問題 8：鎖 key 設(shè)計不當(dāng)——鎖粒度問題引發(fā)并發(fā)瓶頸

成因：鎖 key 粒度太粗（如用“lock:stock”作為所有商品的庫存鎖），導(dǎo)致所有商品的庫存操作都互斥，即使操作不同商品，也需排隊等待鎖釋放，徹底喪失分布式系統(tǒng)的并發(fā)優(yōu)勢。

表現(xiàn)：系統(tǒng)并發(fā)量極低，不同商品的庫存扣減請求串行執(zhí)行，接口吞吐量遠(yuǎn)低于預(yù)期。

解決方案：精細(xì)化設(shè)計鎖 key，按具體資源標(biāo)識拆分鎖。比如庫存鎖，用“lock:stock:1001”（1001 為商品 ID）作為鎖 key，僅對同一商品的庫存操作互斥，不同商品可并行處理，大幅提升并發(fā)量。

延伸：高并發(fā)場景下，可進一步用“分段鎖”拆分資源（如將商品 ID 哈希到 10 個分段，鎖 key 為“lock:stock:segment:1”），同一分段互斥，不同分段并行，進一步提升并發(fā)能力。

問題 9：網(wǎng)絡(luò)分區(qū)導(dǎo)致鎖狀態(tài)不一致——極端場景下的隱患

成因：分布式環(huán)境中出現(xiàn)網(wǎng)絡(luò)分區(qū)，持有鎖的服務(wù)與 Redis 集群隔離，無法主動釋放鎖，也無法接收鎖續(xù)約信號；鎖過期后，其他服務(wù)加鎖成功；網(wǎng)絡(luò)恢復(fù)后，原持有鎖的服務(wù)誤以為鎖仍有效，繼續(xù)操作資源，導(dǎo)致數(shù)據(jù)沖突。

表現(xiàn)：極端網(wǎng)絡(luò)異常后，出現(xiàn)數(shù)據(jù)不一致，且問題難以排查（與網(wǎng)絡(luò)分區(qū)時間、鎖過期時間強相關(guān)）。

解決方案：

• 引入業(yè)務(wù)校驗機制：操作資源前，再次校驗資源狀態(tài)（如扣減庫存前，檢查庫存是否與預(yù)期一致），避免基于過期鎖的無效操作。
• 縮短鎖過期時間：結(jié)合 Watch Dog 機制，將基礎(chǔ)過期時間設(shè)短（如 10 秒），減少網(wǎng)絡(luò)分區(qū)導(dǎo)致的鎖狀態(tài)不一致窗口。
• 使用 Redlock 算法：多主節(jié)點投票機制，可降低網(wǎng)絡(luò)分區(qū)對鎖狀態(tài)的影響，提升一致性。

二、生產(chǎn)避坑總結(jié)

Redis 分布式鎖的問題，大多不是 Redis 本身的缺陷，而是對分布式場景的復(fù)雜性考慮不足。結(jié)合實戰(zhàn)經(jīng)驗，總結(jié) 3 個核心避坑原則：

• 優(yōu)先使用成熟框架：放棄手動實現(xiàn)分布式鎖，Redisson 已封裝解決上述所有問題，開箱即用，穩(wěn)定性遠(yuǎn)高于自定義實現(xiàn)。
• 匹配業(yè)務(wù)場景選型：高一致性、高可用場景用 Redlock 算法；一般場景用主從 + 哨兵模式；根據(jù)并發(fā)量設(shè)計鎖粒度（精細(xì)化/分段鎖）。
• 完善監(jiān)控與兜底：監(jiān)控鎖持有時間、加鎖成功率、Redis 集群狀態(tài)，設(shè)置告警閾值；加鎖失敗、鎖過期等場景，需有業(yè)務(wù)兜底策略（重試、返回友好提示、隊列緩存）。

總之，Redis 分布式鎖的核心是“兼顧互斥性與高可用”，避開上述問題后，才能真正成為分布式系統(tǒng)解決并發(fā)沖突的利器，而非系統(tǒng)的新瓶頸。

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

最新評論