Distributed Locks

Resumen

En un solo proceso, un mutex alcanza para coordinar acceso a un recurso compartido. En un sistema distribuido —múltiples procesos en distintas máquinas— necesitás un lock distribuido. El desafío es garantizar la exclusión mutua incluso si el proceso que tiene el lock falla sin liberarlo.

Las implementaciones típicas usan un servicio externo con consistencia fuerte —Redis con Redlock, etcd, Zookeeper— y leases con TTL: si el lock no se renueva antes de expirar, se libera automáticamente. Esto evita que un deadlock en un proceso bloquee el recurso para siempre.

Alcance y supuestos

Cubre locks distribuidos, implementaciones y el problema del fencing. Asume familiaridad con sistemas distribuidos.

Modelo mental

La llave del baño en una oficina compartida por varios pisos. Si alguien se la lleva y se olvida de devolverla, nadie más puede usar el baño. Con un lock distribuido, la llave tiene un timer: si no se devuelve en 5 minutos, la puerta se destraba automáticamente.

Uso práctico

• ✅ Procesamiento de jobs sin duplicados, leader election, acceso exclusivo a recursos.
• ❌ Recursos que pueden manejarse con particionamiento o colas.

Ejemplo trabajado: Redlock con Redis

lock = redlock.RedLock("resource:42", retry=3, ttl=10000)
if lock.acquire():
    process_resource()
    lock.release()

Evidencia

• Redlock (Redis), etcd y Zookeeper ofrecen locks distribuidos. Martin Kleppmann escribió un análisis crítico de Redlock.