分布式锁如何通过 Redis 工作？

Question

分布式锁如何通过 Redis 工作？

Accepted Answer

**分布式锁**协调多个进程/服务器对共享资源的访问，以便一次只有一个进程持有锁。Redis 通常通过原子性的 set-if-not-exists 加 TTL 来实现此功能——但正确实现需要小心谨慎（并理解其局限性）。

## 基本的 Redis 锁（SET NX with TTL）

```js
// acquire: SET the lock key only if it doesn't exist, with a TTL (auto-release safety)
const token = randomUUID();   // a unique token identifying THIS lock holder
const acquired = await redis.set("lock:resource", token, "NX", "EX", 30);
// NX = set only if not exists (atomic); EX 30 = auto-expire in 30s (avoid deadlock)

if (acquired) {
  try {
    // ... do the work that needs exclusive access ...
  } finally {
    // release ONLY if WE still hold it (check the token) — use a Lua script for atomicity
    await releaseLock("lock:resource", token);
  }
}
```

锁使用**`SET key value NX EX`**：原子性地仅在键不存在时设置该键（因此只有一个客户端成功），并带有**TTL**（所以如果持有者崩溃，锁会自动释放，避免死锁）。

## 两个关键的正确性细节

```text
1. ALWAYS set a TTL → if the lock holder crashes, the lock auto-expires
   (otherwise the resource is locked forever — a deadlock)
2. Use a UNIQUE TOKEN + release only if it matches → so you don't release
   SOMEONE ELSE'S lock (e.g. if your TTL expired and another client acquired it).
   Release must be ATOMIC (check-token-then-delete via a Lua script).
```

```lua
-- safe release: delete only if the value matches our token (atomic via Lua)
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end
```

## 局限性和 Redlock

```text
⚠️ A single-Redis lock isn't perfectly safe: if the TTL expires mid-work, or with
   failover (the lock not yet replicated), two clients could both hold it.
→ REDLOCK algorithm → acquire the lock across MULTIPLE independent Redis nodes
   (majority) for stronger guarantees (though even Redlock is debated).
→ For critical correctness, combine with fencing tokens or use a system designed for
   consensus (e.g. ZooKeeper/etcd). Know the trade-offs.
```

## 为什么这很重要

理解 Redis 分布式锁对于**协调分布式系统中共享资源的访问**很有价值，所以这是有用的知识——特别是理解正确性的陷阱至关重要。

分布式锁解决了一个真实需求：在多服务器系统中确保只有一个进程/服务器在一次执行关键操作（防止重复处理、共享资源上的竞争条件或冲突操作），而 Redis 是实现这一目标的常见工具。

理解**基本机制**——`SET key value NX EX`（原子性 set-if-not-exists 加 TTL），以便只有一个客户端获得锁，并在崩溃时自动释放——是基础技术。

至关重要的是理解**两个正确性细节**是必不可少的：**始终使用 TTL**（所以崩溃的持有者的锁会自动过期，避免永久死锁）和**使用唯一的令牌配合匹配的释放**（所以如果你的 TTL 过期，你不会意外释放另一个客户端的锁——通过 Lua 脚本的原子性检查-再-删除）。

这些细节是朴素实现中存在微妙、危险的 bug 的地方。

同样重要的是理解**局限性**：单个 Redis 锁不是完全安全的（TTL 在工作中过期或故障转移可能让两个客户端持有它），导致**Redlock**算法（在多个 Redis 节点中获得锁）获得更强的保证——以及知道对于关键的正确性，可能需要 fencing 令牌或共识系统（ZooKeeper/etcd）。

这种对权衡和局限性的认识反映了成熟的理解。

由于在分布式系统中协调共享资源访问是真实需求，并且由于 Redis 分布式锁很常见但需要仔细正确实现（TTL、唯一令牌、原子释放）和对其局限性的认知（Redlock、故障转移风险），理解 Redis 的分布式锁——机制、正确性细节和局限性——是分布式协调的有价值的、实践相关的知识，这是一个领域，其中理解陷阱和权衡与基本技术同样重要。