Como funcionam os locks distribuídos com Redis?

Question

Accepted Answer

Um **lock distribuído** coordena o acesso a um recurso compartilhado entre múltiplos processos/servidores para que apenas um o detenha por vez. Redis é comumente usado para isso via set-if-not-exists atômico com TTL — mas implementar corretamente exige cuidado (e compreensão das limitações).

## Um lock Redis básico (SET NX com 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);
  }
}
```

O lock usa **`SET key value NX EX`**: atomicamente define a chave apenas se ausente (para que apenas um cliente suceda) com um **TTL** (para que o lock seja auto-liberado se o detentor sofrer crash, evitando deadlock).

## Dois detalhes críticos de correção

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

## Limitações e 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.
```

## Por que isso importa

Compreender locks distribuídos com Redis é valioso para **coordenar o acesso a recursos compartilhados** em sistemas distribuídos, portanto é conhecimento útil — e compreender as armadilhas de correção é especialmente importante.

Locks distribuídos abordam uma necessidade real: garantir que apenas um processo/servidor execute uma ação crítica por vez (prevenindo processamento duplicado, condições de corrida em recursos compartilhados ou operações conflitantes) em sistemas multi-servidor, e Redis é uma ferramenta comum para isso.

Compreender o **mecanismo básico** — `SET key value NX EX` (set-if-not-exists atômico com TTL) para que apenas um cliente adquira o lock e ele se auto-libere em caso de crash — é a técnica fundamental.

Criticamente, compreender os **dois detalhes de correção** é essencial: **sempre usar um TTL** (para que o lock de um detentor que sofreu crash expire automaticamente, evitando deadlock permanente) e **usar um token único com liberação correspondente** (para não liberar acidentalmente o lock de outro cliente se seu TTL expirou — com check-then-delete atômico via script Lua).

Esses detalhes são onde implementações ingênuas possuem bugs sutis e perigosos.

Igualmente importante é compreender as **limitações**: um lock de Redis único não é perfeitamente seguro (expiração de TTL no meio do trabalho ou failover podem permitir que dois clientes o detenham), levando ao algoritmo **Redlock** (adquirindo em múltiplos nós Redis) para garantias mais fortes — e saber que para correção crítica, tokens de fencing ou sistemas de consenso (ZooKeeper/etcd) podem ser necessários.

Esta consciência dos trade-offs e limitações reflete compreensão madura.

Como coordenar acesso a recursos compartilhados em sistemas distribuídos é uma necessidade real, e como locks distribuídos com Redis são comuns mas exigem implementação correta e cuidadosa (TTL, token único, liberação atômica) e consciência de suas limitações (Redlock, riscos de failover), compreender locks distribuídos com Redis — o mecanismo, os detalhes de correção e as limitações — é conhecimento valioso e praticamente relevante para coordenação distribuída, um tópico onde compreender as armadilhas e trade-offs é tão importante quanto a técnica básica.