Redis ile dağıtık kilitler nasıl çalışır?

Question

IT Interview Practice · Accepted Answer

Bir **dağıtık kilit**, birden fazla işlem/sunucu arasında paylaşılan bir kaynağa erişimi koordine eder, böylece aynı anda yalnızca biri kilidi tutar. Redis, atomik set-if-not-exists ile TTL kullanılarak bu amaç için yaygın şekilde kullanılır — ancak bunu doğru şekilde yapmak dikkat gerektirir (ve sınırlamalarını anlamak önemlidir).

## Temel bir Redis kilidi (SET NX ile 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);
  }
}
```

Kilit, **`SET key value NX EX`** kullanır: anahtarı yalnızca yoksa atomik olarak ayarlar (böylece yalnızca bir istemci başarılı olur) ve **TTL** ile birlikte (böylece tutucu çöküşünde kilit otomatik olarak serbest bırakılır, kilitlenmeyi önler).

## İki kritik doğruluk detayı

```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
```

## Sınırlamalar ve 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.
```

## Neden önemli

Redis ile dağıtık kilitler anlamak, **dağıtık sistemler arasında paylaşılan kaynakları koordine etmek** için değerlidir, bu nedenle faydalı bir bilgidir — ve doğruluk tuzaklarını anlamak özellikle önemlidir.

Dağıtık kilitler gerçek bir ihtiyacı ele alır: çok sunuculu sistemlerde yalnızca bir işlem/sunucunun kritik bir eylemi gerçekleştirmesini sağlamak (yinelenen işlemeyi, paylaşılan kaynaklar üzerinde yarış durumlarını veya çakışan işlemleri önlemek) ve Redis bu amaç için yaygın bir araçtır.

**Temel mekanizmi** anlamak — `SET key value NX EX` (atomik set-if-not-exists bir TTL ile) böylece yalnızca bir istemci kilidi alır ve çökme sırasında otomatik olarak serbest bırakılır — temel tekniktir.

Ancak, **iki doğruluk detayını** anlamak çok önemlidir: **her zaman TTL kullanmak** (böylece çökmüş tutucu kilidi otomatik olarak sona erer, kalıcı kilitlenmeyi önler) ve **benzersiz bir token ile eşleştirilmiş serbest bırakma kullanmak** (TTL süresi dolduğunda yanlışlıkla başka bir istemcinin kilidini serbest bırakmamamız için — Lua betiği aracılığıyla atomik kontrol-sonra-sil ile).

Bu detaylar, naif uygulamaların ince ve tehlikeli hatalara sahip olduğu yerdir.

Eşit derecede önemli, **sınırlamaları** anlamaktır: tek bir Redis kilidi mükemmel şekilde güvenli değildir (TTL süresi dolması veya failover iki istemcinin tutmasına izin verebilir), bu da daha güçlü garantiler için **Redlock** algoritmasına (birden fazla Redis düğümü arasında alma) yol açar — ve kritik doğruluk için çitlama tokenları veya fikir birliği sistemleri (ZooKeeper/etcd) gerekli olabileceğini bilmek.

Bu ticaret-off ve sınırlamaların farkındalığı, olgun bir anlayışı yansıtır.

Dağıtık sistemlerde paylaşılan kaynak erişimini koordine etmek gerçek bir ihtiyaç olduğundan ve Redis dağıtık kilitleri yaygın ancak dikkatli doğru uygulamayı gerektirdiğinden (TTL, benzersiz token, atomik serbest bırakma) ve sınırlamalarının farkındalığı (Redlock, failover riskleri), Redis ile dağıtık kilitler — mekanizm, doğruluk detayları ve sınırlamalar — anlamak, dağıtık koordinasyon için değerli ve pratik olarak ilgili bilgidir; bu konu, tuzakları ve ticaret-off'ları anlamak, temel teknik kadar önemlidir.

Temel bir Redis kilidi (SET NX ile TTL)

İki kritik doğruluk detayı

Sınırlamalar ve Redlock

Neden önemli

İlgili sorular