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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 多組獨(dú)立 Redis 節(jié)點(diǎn)配置（YML）

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

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

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

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

@Configuration
public class RedissonRedlockConfig {
    // 第一組 Redlock 節(jié)點(diǎn)客戶端
    @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é)點(diǎn)模式（若為集群，可改用 useSentinelServers 配置哨兵）
        config.useSingleServer()
                .setAddress("redis://" + host + ":" + port)
                .setPassword(password)
                .setDatabase(database)
                .setTimeout(timeout);
        return Redisson.create(config);
    }
    // 第二組 Redlock 節(jié)點(diǎn)客戶端
    @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é)點(diǎn)客戶端
    @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é)點(diǎn)鎖，自動(dòng)觸發(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é)點(diǎn)鎖對(duì)象
        String lockKey = "lock:stock:" + productId;
        RLock lock1 = redlockClient1.getLock(lockKey);
        RLock lock2 = redlockClient2.getLock(lockKey);
        RLock lock3 = redlockClient3.getLock(lockKey);
        // 2. 組合為Redlock鎖，觸發(fā)多節(jié)點(diǎn)投票
        RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3);
        try {
            // 3. 加鎖：1秒內(nèi)等待節(jié)點(diǎn)響應(yīng)，鎖過期時(shí)間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)繁忙，請(qǐng)稍后再試");
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            throw new RuntimeException("操作被中斷，請(qǐng)重試");
        } finally {
            // 5. 安全釋放鎖：僅當(dāng)前線程持有鎖時(shí)執(zhí)行
            if (redLock.isHeldByCurrentThread()) {
                redLock.unlock();
            }
        }
    }
}

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

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

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

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

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

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

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

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

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

解決方案：

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

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

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

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

解決方案：實(shí)現(xiàn)帶限制的重試機(jī)制，加鎖失敗后，間隔一定時(shí)間（如 100ms）重試，同時(shí)設(shè)置最大重試次數(shù)（如 3 次）和總超時(shí)時(shí)間（如 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：長(zhǎng)時(shí)間持有鎖——系統(tǒng)并發(fā)量驟降

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

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

解決方案：

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

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

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

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

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

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

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

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

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

解決方案：

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

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

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

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

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

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

最新評(píng)論