Node.js Backend Development Bootcamp · レッスン

分散ロックとRedlockアルゴリズム

インスタンス間の排他的アクセスを安全に調整し、分散ロックの限界を理解します。

「分散ロックとRedlockアルゴリズム」はCoddyKit上の無料Node.js Backend Development Bootcampレッスンです。これはレッスン2/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはNode.js Backend Development Bootcamp学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Node.js Backend Development Bootcampコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Why Distributed Locks?

When your Node.js API runs as a single process, a simple in-memory mutex is enough to serialize access to a critical section. But production backends run many instances behind a load balancer, often across multiple machines.

Two pods may both try to charge the same invoice.
Two workers may both pick up the same job from a queue.
Two requests may both regenerate the same expensive cache entry (a cache stampede).

An in-memory lock lives inside one process only — the other instances know nothing about it. To coordinate exclusive access across instances you need a lock that lives in shared external storage, and Redis is a popular home for it.

A First (Naive) Redis Lock

The core primitive is the atomic SET key value NX PX ttl command. NX means "only set if the key does not exist", and PX sets an expiry in milliseconds so the lock auto-releases if the holder crashes.

If SET returns OK, you acquired the lock.
If it returns null, someone else holds it.

The value must be a unique random token per acquisition — you will need it later to release safely.

const { createClient } = require('redis');
const crypto = require('crypto');

async function acquire(redis, key, ttlMs) {
  const token = crypto.randomUUID();
  // NX = set only if absent, PX = expiry in ms
  const ok = await redis.set(key, token, { NX: true, PX: ttlMs });
  return ok === 'OK' ? token : null;
}

// Usage sketch (needs a running Redis):
// const redis = createClient(); await redis.connect();
// const token = await acquire(redis, 'lock:invoice:42', 10000);
// if (token) { /* do exclusive work */ }

Releasing Safely: Check-and-Delete

Releasing is the dangerous part. A naive DEL key can delete someone else's lock: if your work overran the TTL, the lock expired, another instance acquired it, and then your late DEL wipes their lock.

The fix: only delete if the stored value still equals your token. Check-then-delete must be atomic, so we run it as a Lua script — Redis executes scripts without interleaving other commands.

const RELEASE_LUA = `
if redis.call('get', KEYS[1]) == ARGV[1] then
  return redis.call('del', KEYS[1])
else
  return 0
end`;

async function release(redis, key, token) {
  // Returns 1 if we owned and removed it, 0 otherwise
  return redis.eval(RELEASE_LUA, { keys: [key], arguments: [token] });
}

TTL: The Hardest Tuning Decision

The TTL is a bet on how long your critical section takes.

Too short and the lock expires mid-work, allowing a second worker in — your mutual exclusion is broken.
Too long and if a holder crashes, everyone waits the full TTL before anyone can proceed.

Rules of thumb: set the TTL to a few times your p99 critical-section duration, keep the protected work short, and for long tasks use a watchdog that periodically extends the lock instead of a single huge TTL.

Extending a Lock (Watchdog Pattern)

For work whose duration is uncertain, acquire a modest TTL and renew it on a timer while you still hold the lock. Like release, extension must be guarded by your token so you never extend a lock that has already moved on.

The watchdog runs at roughly one third of the TTL, giving you margin against clock jitter and GC pauses.

const EXTEND_LUA = `
if redis.call('get', KEYS[1]) == ARGV[1] then
  return redis.call('pexpire', KEYS[1], ARGV[2])
else
  return 0
end`;

function startWatchdog(redis, key, token, ttlMs) {
  const timer = setInterval(async () => {
    const ok = await redis.eval(EXTEND_LUA, {
      keys: [key], arguments: [token, String(ttlMs)],
    });
    if (ok !== 1) clearInterval(timer); // lost the lock; stop renewing
  }, Math.floor(ttlMs / 3));
  return () => clearInterval(timer);
}

Single-Node Redis Is a SPOF

Everything so far assumes one Redis node. That node is a single point of failure, so teams add a replica with failover. But Redis replication is asynchronous, and that quietly breaks mutual exclusion:

Client A acquires the lock on the master.
The master crashes before replicating the write to the replica.
The replica is promoted; it has no record of the lock.
Client B acquires "the same" lock on the new master.

Now two clients hold the lock simultaneously. The Redlock algorithm was designed to address this failover window.

The Redlock Algorithm

Redlock uses N independent Redis masters (typically 5), with no replication between them. To acquire a lock a client:

Records the start time, then tries to SET NX PX the same key+token on all N nodes, using a short per-node timeout.
Counts successes. The lock is considered acquired only if it got a quorum (N/2 + 1, i.e. 3 of 5) and the total elapsed time is less than the TTL.
The effective validity = TTL minus elapsed time minus a clock-drift allowance.

If it fails to reach quorum (or runs out of time), it unlocks all nodes and retries after a small random delay.

Using the redlock Library

You rarely implement Redlock by hand. The redlock npm package takes an array of independent Redis clients and exposes using(), which acquires, auto-extends, and releases the lock around your callback.

retryCount / retryDelay control how hard it tries before giving up.
using() hands you a signal — check signal.aborted to detect that the lock was lost mid-work.

const Client = require('ioredis');
const Redlock = require('redlock').default;

const nodes = [
  new Client({ host: 'redis-a' }),
  new Client({ host: 'redis-b' }),
  new Client({ host: 'redis-c' }),
];

const redlock = new Redlock(nodes, {
  retryCount: 10,
  retryDelay: 200,   // ms between attempts
  driftFactor: 0.01, // clock-drift allowance
});

async function chargeInvoice(id) {
  await redlock.using([`lock:invoice:${id}`], 5000, async (signal) => {
    await doCharge(id);
    if (signal.aborted) throw signal.error; // lost the lock
  });
}

Fencing Tokens: The Real Safety Net

Martin Kleppmann's well-known critique: no lock based on timeouts can guarantee safety if a holder is paused (GC, VM stall) past the TTL. The lock expires, another client proceeds, and the paused client wakes up still believing it holds the lock.

The robust defense is a fencing token: a monotonically increasing number issued with each lock grant. The protected resource itself rejects any write carrying a token lower than the highest it has already seen — so a stale, paused writer is fenced out at the destination.

// Resource-side guard: reject writes with a stale fencing token.
function makeFencedStore() {
  let highestSeen = 0;
  const data = {};
  return {
    write(key, value, token) {
      if (token <= highestSeen) {
        throw new Error(`fenced: token ${token} <= ${highestSeen}`);
      }
      highestSeen = token;
      data[key] = value;
      return token;
    },
  };
}

const store = makeFencedStore();
store.write('balance', 100, 33);     // ok, token 33
try {
  store.write('balance', 999, 32);   // stale writer, fenced out
} catch (e) {
  console.log(e.message);            // fenced: token 32 <= 33
}
console.log('stored:', store.write('balance', 200, 34)); // 34

Locks vs. Idempotency

A lock reduces the chance of concurrent execution, but timeouts and failovers mean you can never make it a hard guarantee. Treat the lock as an optimization, not the last line of defense.

Make the protected operation idempotent — running it twice produces the same result.
Use database unique constraints or conditional updates (compare-and-set) so a duplicate write fails loudly.
Use fencing tokens where the resource supports them.

Best practice: lock to avoid wasted work and contention, but design the system so a rare double-execution is still correct.

Do You Even Need Redlock?

Redlock adds operational cost: five independent Redis deployments, careful clock management, and retry tuning. The redis maintainers themselves note that for efficiency use cases (avoid doing the same work twice), a single-node lock is fine — an occasional double-run just wastes a little work.

Efficiency lock (cache rebuild, dedup): single Redis SET NX PX is enough.
Correctness lock (money, inventory): don't rely on any timeout lock alone — add idempotency and fencing, regardless of Redlock.

Reach for Redlock only when single-node HA failover is genuinely unacceptable and you cannot fence at the resource.

Quick Check

Test your understanding of distributed locking safety.

Recap

You learned how to coordinate exclusive access across Node.js instances — and where the limits are.

Acquire with atomic SET key token NX PX ttl; the token must be unique per acquisition.
Release and extend only via a token-checked Lua script so you never touch someone else's lock; renew long tasks with a watchdog.
TTL is a tradeoff: too short breaks exclusion, too long delays recovery after a crash.
Redlock uses a quorum across N independent masters to survive single-node failover, but it is still timeout-based.
No timeout lock is safe against long pauses — add fencing tokens and idempotency for correctness-critical work.
Use a single-node lock for efficiency; reserve Redlock for genuine HA needs.

よくある質問

「分散ロックとRedlockアルゴリズム」レッスンは無料ですか？

はい。「分散ロックとRedlockアルゴリズム」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Node.js Backend Development Bootcampコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Node.js Backend Development Bootcampコースには全4レッスンが含まれています。

「分散ロックとRedlockアルゴリズム」で何を学びますか？

インスタンス間の排他的アクセスを安全に調整し、分散ロックの限界を理解します。ブラウザで直接実行するハンズオンコードでNode.js Backend Development Bootcampを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Node.js Backend Development Bootcampを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのNode.js Backend Development Bootcampは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン2/4です。

「分散ロックとRedlockアルゴリズム」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このNode.js Backend Development Bootcampレッスンでコードを書いて実行できますか？

はい。すべてのNode.js Backend Development Bootcampレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← Node.js Backend Development Bootcampに戻る