¿Cómo funcionan los bloqueos distribuidos con Redis?

Question

Accepted Answer

Un **bloqueo distribuido** coordina el acceso a un recurso compartido entre múltiples procesos/servidores para que solo uno tenga el bloqueo a la vez. Redis se usa comúnmente para esto mediante una operación atómica de establecer-si-no-existe con un TTL — aunque hacerlo correctamente requiere cuidado (y comprender las limitaciones).

## Un bloqueo Redis básico (SET NX con 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);
  }
}
```

El bloqueo usa **`SET key value NX EX`**: establece atómicamente la clave solo si está ausente (por lo que solo un cliente tiene éxito) con un **TTL** (por lo que el bloqueo se libera automáticamente si el titular se cae, evitando un bloqueo permanente).

## Dos detalles críticos de corrección

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

## Limitaciones y 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 qué es importante

Comprender los bloqueos distribuidos con Redis es valioso para **coordinar el acceso a recursos compartidos** entre sistemas distribuidos, por lo que es un conocimiento útil — y entender los riesgos de corrección es especialmente importante.

Los bloqueos distribuidos abordan una necesidad real: garantizar que solo un proceso/servidor realice una acción crítica a la vez (previniendo procesamiento duplicado, condiciones de carrera en recursos compartidos u operaciones conflictivas) en sistemas multi-servidor, y Redis es una herramienta común para esto.

Comprender el **mecanismo básico** — `SET key value NX EX` (establecer atómicamente si-no-existe con un TTL) para que solo un cliente adquiera el bloqueo y se libere automáticamente en un fallo — es la técnica fundamental.

Críticamente, comprender los **dos detalles de corrección** es esencial: **siempre usar un TTL** (para que el bloqueo de un titular fallido expire automáticamente, evitando un bloqueo permanente) y **usar un token único con liberación coordinada** (para que no liberes accidentalmente el bloqueo de otro cliente si tu TTL expiró — con verificación-entonces-eliminación atómica mediante un script Lua).

Estos detalles son donde las implementaciones ingenuas tienen errores sutiles y peligrosos.

Igualmente importante es comprender las **limitaciones**: un bloqueo de Redis único no es perfectamente seguro (la expiración de TTL a mitad del trabajo o conmutación por error pueden permitir que dos clientes lo tengan), lo que lleva al algoritmo **Redlock** (adquiriendo entre múltiples nodos Redis) para garantías más sólidas — y saber que para la corrección crítica, puede ser necesario usar tokens de barrera o sistemas de consenso (ZooKeeper/etcd).

Esta conciencia de los compromisos y limitaciones refleja una comprensión madura.

Ya que coordinar el acceso a recursos compartidos en sistemas distribuidos es una necesidad real, y ya que los bloqueos distribuidos de Redis son comunes pero requieren una implementación correcta cuidadosa (TTL, token único, liberación atómica) y conciencia de sus limitaciones (Redlock, riesgos de conmutación por error), comprender los bloqueos distribuidos con Redis — el mecanismo, los detalles de corrección y las limitaciones — es un conocimiento valioso y prácticamente relevante para la coordinación distribuida, un tema donde entender los riesgos y compromisos es tan importante como la técnica básica.