---
tags: [Redis, 分布式锁, 分布式系统, 一致性]
create time: 2026-05-26 23:41
---

# 分布式锁

## 概述

分布式锁是分布式系统中协调多节点访问共享资源的核心机制。Redis 凭借单线程模型和高性能成为实现分布式锁的首选方案，但「用 SET NX 就够了」的想法往往埋下隐患。本文从最基础的实现出发，逐步剖析安全解锁、锁续期、Redlock 算法等关键问题，帮助你构建生产级的分布式锁。

## 一、为什么需要分布式锁？

在单机环境下，一个 `sync.Mutex` 或 `synchronized` 就能保护临界区。但在分布式场景下，多个服务实例部署在不同机器上，进程内的锁无法跨节点生效。

> [!QUESTION] 想象一个场景
> 电商系统有 3 个订单服务实例，用户下单时都需要扣减库存。如果两个实例同时读到库存为 1，各扣减 1，最终库存变成 -1——超卖了。这就是典型的**并发竞态问题**。

分布式锁的核心语义很简单：**在同一时刻，只有一个客户端能持有锁**。但实现起来需要满足以下条件：

| 条件 | 说明 |
|------|------|
| **互斥性** | 任意时刻只有一个客户端持有锁 |
| **无死锁** | 持有锁的客户端崩溃后，锁能自动释放 |
| **容错性** | 只要大部分节点存活，加锁/解锁就能正常工作 |
| **解铃还须系铃人** | 谁加的锁谁解，不能误删别人的锁 |

## 二、基本实现：SET NX EX

最简单也最常用的方案——利用 Redis 的 `SET` 命令附带 `NX` 和 `EX` 选项：

```bash
SET lock:order:1001 $client_token NX EX 30
#    ↑ key         ↑ 唯一标识    ↑ 不存在才设置 ↑ 30秒过期
```

```go
// 加锁
ok, err := rdb.SetNX(ctx, "lock:order:1001", clientToken, 30*time.Second).Result()
if !ok {
    // 未获取到锁，处理重试或失败逻辑
    return errors.New("lock is held by another client")
}

// 执行业务逻辑
doBusiness()

// 解锁（必须用 Lua 保证原子性！）
rdb.Eval(ctx, unlockScript, []string{"lock:order:1001"}, clientToken)
```

> [!WARNING] 为什么必须带 EX（过期时间）？
> 如果不设过期时间，持有锁的客户端崩溃后，这把锁将**永远不会释放**——其他客户端全部死等，形成死锁。`EX` 是分布式锁的安全网。

> [!QUESTION] 为什么 client_token 必须是全局唯一的？
> 假设你用固定字符串 `"my-lock"` 作为 value，那么任何客户端解锁时都无法判断这把锁是不是自己加的。UUID 或 Snowflake ID 能保证每个客户端的标识独一无二。

## 三、安全解锁：Lua 原子性释放

解锁看似简单——`DEL key` 就行？**不行**。考虑这个时序：

```mermaid
sequenceDiagram
    participant A as "Client A"
    participant R as "Redis"
    participant B as "Client B"
    A->>R: GET lock → 自己的 token
    Note over A: 业务执行太久...
    Note over R: lock 过期自动释放
    B->>R: SET lock NX → 成功!
    A->>R: DEL lock 💥
    Note over B: 我的锁被 A 删了!
```

**解决方案**：解锁时必须先检查 value 是否是自己的 token，且「检查 + 删除」必须原子化——这正是 Lua 脚本的强项：

```lua
-- unlock.lua
-- KEYS[1] = lock key
-- ARGV[1] = client token
if redis.call("get", KEYS[1]) == ARGV[1] then
    return redis.call("del", KEYS[1])
else
    return 0  -- 不是我的锁，拒绝删除
end
```

```go
var unlockScript = redis.NewScript(`
    if redis.call("get", KEYS[1]) == ARGV[1] then
        return redis.call("del", KEYS[1])
    end
    return 0
`)

// 解锁时传入当初加锁用的同一个 token
result, _ := unlockScript.Run(ctx, rdb, []string{"lock:order:1001"}, clientToken).Int()
if result == 0 {
    log.Warn("锁已过期或不属于当前客户端")
}
```

> [!TIP] 完整的加锁/解锁流程
> 1. 生成唯一 token（UUID）
> 2. `SET key token NX EX 30` 加锁
> 3. 执行业务逻辑
> 4. Lua 脚本原子性检查 + 释放锁
> 5. 无论成功失败，都要走到第 4 步（建议 `defer`）

## 四、锁续期：Watchdog 机制

> [!QUESTION] 业务执行时间超过了锁的 TTL 怎么办？
> 如果锁设了 30 秒过期，但业务跑了 40 秒，第 30 秒时锁自动释放，其他客户端就能拿到锁——互斥性被打破。

Redisson（Java 生态中 Redis 客户端）的解决方案是 **Watchdog**：后台线程定期检查锁是否还被持有，如果是就续期。用 Go 模拟这个思路：

```go
// Watchdog 自动续期（简化版）
func startWatchdog(ctx context.Context, rdb *redis.Client, key, token string, ttl time.Duration) context.CancelFunc {
    ctx, cancel := context.WithCancel(ctx)
    go func() {
        ticker := time.NewTicker(ttl / 3)  // 每 TTL/3 检查一次
        defer ticker.Stop()
        for {
            select {
            case <-ctx.Done():
                return  // 锁已释放，停止续期
            case <-ticker.C:
                // 原子续期：只有还持有锁才续
                renewed := renewScript.Run(ctx, rdb, []string{key}, token, int(ttl.Seconds()))
                if renewed.Int() == 0 {
                    return  // 锁已不属于我，停止续期
                }
            }
        }
    }()
    return cancel  // 调用 cancel() 即停止 watchdog
}
```

```lua
-- renew.lua（原子续期）
if redis.call("get", KEYS[1]) == ARGV[1] then
    return redis.call("expire", KEYS[1], ARGV[2])
end
return 0
```

```mermaid
flowchart LR
    A["加锁 TTL=30s"] --> B["业务执行中"]
    B -->|"T/3 = 10s"| C{"还持有锁?"}
    C -->|"是"| D["续期 30s"]
    D --> B
    C -->|"否"| E["停止续期"]
    B --> F["业务完成"]
    F --> G["释放锁 + 停止 watchdog"]
```

> [!WARNING] Watchdog 不是银弹
> - 如果续期时 Redis 节点刚好故障，续期请求会失败——锁仍会过期
> - 真正需要超长锁持有时间时，考虑拆分业务逻辑，缩短临界区
> - Watchdog 的 interval 建议设为 TTL 的 1/3，留出容错空间

## 五、Redlock 算法

### 单节点的隐患

上述方案都基于单个 Redis 实例。如果这个实例主从切换时，锁数据还没同步到从节点，锁就「凭空消失」了。

> [!QUESTION] 主从切换时锁丢失的例子
> 1. Client A 在 master 上加锁成功
> 2. Master 还没来得及把锁同步到 slave 就宕机了
> 3. Slave 升级为新 master
> 4. Client B 在新 master 上加同一把锁——成功了！
> 结果：A 和 B 同时持有锁，互斥性被打破。

### Redlock 的思路

Antirez（Redis 作者）提出的 Redlock 算法：**向 N 个独立的 Redis 节点（非集群，互不通信）同时加锁**，当且仅当大多数节点（N/2 + 1）加锁成功且总耗时未超过锁的 TTL，才算获取成功。

```mermaid
flowchart TD
    C["Client"] -->|"SET NX EX"| N1["Redis Node 1"]
    C -->|"SET NX EX"| N2["Redis Node 2"]
    C -->|"SET NX EX"| N3["Redis Node 3"]
    C -->|"SET NX EX"| N4["Redis Node 4"]
    C -->|"SET NX EX"| N5["Redis Node 5"]
    N1 -->|"OK ✅"| C
    N2 -->|"OK ✅"| C
    N3 -->|"FAIL ❌"| C
    N4 -->|"OK ✅"| C
    N5 -->|"OK ✅"| C
    Note over C: "4/5 成功 > 5/2+1=3，加锁成功!"
```

```go
// Redlock 伪代码（生产环境建议使用 redsync 等成熟库）
func redlock(ctx context.Context, clients []*redis.Client, key, token string, ttl time.Duration) bool {
    successCount := 0
    startTime := time.Now()

    // 并发向所有节点发起加锁
    var wg sync.WaitGroup
    var mu sync.Mutex
    for _, c := range clients {
        wg.Add(1)
        go func(c *redis.Client) {
            defer wg.Done()
            ok, _ := c.SetNX(ctx, key, token, ttl).Result()
            if ok {
                mu.Lock()
                successCount++
                mu.Unlock()
            }
        }(c)
    }
    wg.Wait()

    elapsed := time.Since(startTime)
    quorum := len(clients)/2 + 1

    // 加锁有效时间 = TTL - 加锁耗时 - 时钟漂移
    // 注意：elapsed 包含了网络往返时间，clock drift 需要根据实际环境估算（通常几毫秒）
    validity := ttl - elapsed
    return successCount >= quorum && validity > 0
}
```

### Redlock 的争议

Martin Kleppmann 在 [How to do distributed locking](https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html) 中指出了 Redlock 的几个问题：

| 问题 | 说明 |
|------|------|
| **时钟跳跃** | NTP 同步导致节点时钟突变，锁的实际过期时间不可控 |
| **GC 停顿** | 客户端获取锁后进入 GC，锁在客户端视角未过期但实际已过期 |
| **复杂度高** | 需要部署 5 个独立 Redis 实例，运维成本远高于单节点 |

### Fencing Token：Kleppmann 的解法

Kleppmann 在批评 Redlock 的同时，提出了一个更安全的思路——**Fencing Token（防护令牌）**。核心思想：锁服务每次授予锁时，递增一个单调递增的 token，客户端携带这个 token 去访问资源，资源端拒绝持有过期 token 的写入。

```mermaid
sequenceDiagram
    participant L as "Lock Service"
    participant A as "Client A"
    participant B as "Client B"
    participant S as "Storage"
    A->>L: 获取锁 → token=33
    Note over A: GC 停顿...
    Note over L: A 的锁过期
    B->>L: 获取锁 → token=34
    B->>S: 写入(token=34) ✅ 成功
    Note over A: GC 恢复，以为还持有锁
    A->>S: 写入(token=33) ❌ 被拒绝
    Note over S: "33 < 34，拒绝过期请求!"
```

> [!NOTE] 为什么 Fencing Token 比 Redlock 更安全？
> Redlock 依赖**时间假设**（所有节点时钟一致），Fencing Token 把安全性转移到了**资源端校验**——不依赖时钟，只要资源端（如数据库）能比较 token 大小即可。实际场景中，可以在数据库的 `WHERE` 条件中加入 token 版本号，天然实现幂等校验。

> [!TIP] 实际生产中的选择
> - **对互斥性要求一般**（如防重复提交）：单节点 `SET NX EX` + Lua 解锁足矣
> - **对互斥性要求较高**：Redlock 或 etcd/ZooKeeper 的分布式锁（基于 Raft/ZAB 协议，不依赖时钟）
> - **金融级强一致**：直接用数据库行锁或分布式共识系统

## 六、可重入锁

如果同一个线程/协程需要多次获取同一把锁（比如递归调用），普通锁会自己把自己锁死——这就是需要**可重入锁**的场景。

核心思路：value 不再是简单的 token，而是一个包含 **持有者标识 + 重入次数** 的结构。

```lua
-- reentrant_lock.lua
local key = KEYS[1]
local token = ARGV[1]
local ttl = ARGV[2]

local holder = redis.call("hget", key, "holder")
if holder == token then
    -- 已持有，增加重入计数
    redis.call("hincrby", key, "count", 1)
    redis.call("expire", key, ttl)
    return 1
end

if holder == false then
    -- 无人持有，获取锁
    redis.call("hset", key, "holder", token, "count", 1)
    redis.call("expire", key, ttl)
    return 1
end

return 0  -- 被其他人持有
```

```go
var reentrantLockScript = redis.NewScript(`
    local holder = redis.call("hget", KEYS[1], "holder")
    if holder == ARGV[1] then
        redis.call("hincrby", KEYS[1], "count", 1)
        redis.call("expire", KEYS[1], ARGV[2])
        return 1
    end
    if holder == false then
        redis.call("hset", KEYS[1], "holder", ARGV[1], "count", 1)
        redis.call("expire", KEYS[1], ARGV[2])
        return 1
    end
    return 0
`)
```

```go
var reentrantUnlockScript = redis.NewScript(`
    local holder = redis.call("hget", KEYS[1], "holder")
    if holder ~= ARGV[1] then
        return 0  -- 不是自己的锁
    end
    local count = redis.call("hincrby", KEYS[1], "count", -1)
    if count <= 0 then
        redis.call("del", KEYS[1])  -- 重入归零，释放锁
    end
    return 1
`)
```

> [!NOTE] Hash 结构的选择
> 使用 Hash（`HSET`）而非 String，是因为 Hash 可以在一个 key 中同时存储 `holder` 和 `count`，解锁时原子性递减计数，归零才删除 key。

## 七、常见陷阱与最佳实践

### 陷阱清单

| 陷阱 | 后果 | 解决方案 |
|------|------|---------|
| 不设 TTL | 崩溃后死锁 | `SET NX EX`，TTL 设为业务预估时间的 2-3 倍 |
| 直接 DEL 解锁 | 可能误删别人的锁 | Lua 脚本原子性检查 + 删除 |
| 锁粒度太粗 | 并发度低，吞吐下降 | 按资源维度加锁（如 `lock:order:{id}`） |
| 锁粒度太细 | 管理复杂，容易遗漏 | 抽象锁工具层，统一管理 |
| 未考虑网络分区 | 锁失效但客户端认为持有 | Watchdog + 业务层幂等 |
| 未做重试 | 瞬时竞争直接失败 | 指数退避 + jitter 重试 |

### Redis Cluster 下的注意事项

Redis Cluster 采用哈希槽分片，Lua 脚本要求操作的 key 在同一个 slot 上。单把分布式锁只涉及一个 key，通常没有问题，但有两个场景需要注意：

> [!WARNING] 多 key 加锁的坑
> 如果业务需要同时锁定多个资源（如 `lock:order:1` 和 `lock:order:2`），这两个 key 可能分布在不同 slot，Lua 脚本会报 `CROSSSLOT` 错误。解决方案：
> 1. 使用 Hash Tag 强制同 slot：`lock:{order}:1`、`lock:{order}:2`（花括号内的部分决定 slot）
> 2. 逐个加锁，配合死锁预防（如按 key 字典序依次获取）

> [!NOTE] Cluster 故障转移与锁丢失
> Cluster 模式下的主从切换和哨兵模式类似——异步复制导致锁可能在故障转移后丢失。Cluster 不会自动重试 Lua 脚本，客户端需要自己处理 `MOVED`/`ASK` 重定向。

### 重试策略：指数退避

```go
func acquireLockWithRetry(ctx context.Context, rdb *redis.Client, key, token string, ttl time.Duration, maxRetries int) (bool, error) {
    for i := 0; i < maxRetries; i++ {
        ok, err := rdb.SetNX(ctx, key, token, ttl).Result()
        if ok {
            return true, nil
        }
        if err != nil {
            return false, err
        }
        // 指数退避 + 随机抖动
        backoff := time.Duration(1<<uint(i)*100) * time.Millisecond
        jitter := time.Duration(rand.Int63n(int64(backoff / 2)))
        time.Sleep(backoff + jitter)
    }
    return false, errors.New("max retries exceeded")
}
```

> [!TIP] 分布式锁的黄金法则
> 1. **锁要短命**——临界区尽量小，TTL 尽量短
> 2. **解锁要安全**——Lua 原子性检查 + 删除
> 3. **业务要幂等**——即使锁失效，幂等性也能兜底
> 4. **不要过度设计**——单节点方案能解决的，不要上 Redlock

## 关联笔记

- [[hhs/Redis/09-高级特性]] — Lua 脚本基础、事务机制
- [[hhs/Redis/06-主从与哨兵]] — 主从同步延迟导致的锁丢失问题
- [[hhs/Redis/07-集群方案]] — Cluster 模式下 Lua 脚本的 slot 限制
- [[hhs/Redis/README]] — Redis 知识索引总览