Redis分散ロックはどのように機能しますか?

Question

Accepted Answer

**分散ロック**は、複数のプロセス/サーバ間で共有リソースへのアクセスを調整し、一度に1つだけがロックを保持するようにします。Redisはこれに対して、原子的なセット・イフ・ノット・エクジストと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`**を使用します:キーが存在しない場合のみ原子的にキーを設定し(1つのクライアントのみが成功するように)、**TTL**を設定します(ロック保持者がクラッシュした場合、ロックが自動的に解放されるため、デッドロックを回避します)。

## 2つの重要な正確性の詳細

```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を使用した分散ロックを理解することは、分散システム全体で**共有リソースへのアクセスを調整**するために価値があります。そのため有用な知識です。また、正確性の落とし穴を理解することは特に重要です。

分散ロックは実際のニーズに対応しています:分散マルチサーバシステムで、1つのプロセス/サーバだけが重要なアクションを実行することを確保し(重複処理、共有リソース上の競争状態、または矛盾する操作を防止する)、Redisはこれの一般的なツールです。

**基本的なメカニズム**を理解することが基盤となる技術です。`SET key value NX EX`(原子的なセット・イフ・ノット・エクジストとTTL)により、1つのクライアントだけがロックを取得し、クラッシュ時に自動的に解放されます。

重要なことに、**2つの正確性の詳細**を理解することは必須です:**常にTTLを使用する**(クラッシュしたロック保持者のロックが自動的に期限切れになるため、永続的なデッドロックを回避します)と**ユニークトークンとマッチングされたリリースを使用する**(TTLが期限切れになった場合に別のクライアントのロックを誤って解放しないようにするため、Luaスクリプトによる原子的なチェック・ザン・デリートを使用します)。

これらの詳細は、単純な実装に微妙な危険なバグがある場所です。

同様に重要なのは**制限事項**を理解することです:単一のRedisロックは完全に安全ではありません(TTL有効期限の中程での失効やフェイルオーバーにより、2つのクライアントがロックを保持できます)。これはより強力な保証のための**Redlock**アルゴリズム(複数のRedisノード全体での取得)につながります。また、重要な正確性のために、フェンシングトークンまたはコンセンサスシステム(ZooKeeper/etcd)が必要な場合があることを知っておくことが重要です。

このトレードオフと制限事項の認識は、成熟した理解を反映しています。

分散システムの共有リソースアクセスの調整は実際のニーズであり、RedisのセキュリティロックがTTL、ユニークトークン、原子的なリリースについて注意深く正しく実装する必要があり、Redlock、フェイルオーバーリスクについての認識が必要であるため、Redisを使用した分散ロックを理解すること(メカニズム、正確性の詳細、制限事項)は、分散調整のための価値がある実用的で関連性のある知識です。これは落とし穴とトレードオフを理解することが基本的な技術と同じくらい重要なトピックです。