Un lock distribuito coordina l'accesso a una risorsa condivisa tra più processi/server in modo che solo uno tenga il lock alla volta. Redis è comunemente usato per questo tramite un'operazione atomica set-if-not-exists con un TTL — tuttavia implementarlo correttamente richiede attenzione (e comprensione delle limitazioni).
token = ();
acquired = redis.(, token, , , );
(acquired) {
{
} {
(, token);
}
}
Il lock usa SET key value NX EX: imposta atomicamente la chiave solo se assente (quindi solo un client ha successo) con un TTL (cosicché il lock si rilascia automaticamente se il titolare si arresta, evitando deadlock).
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).
-- 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
⚠️ 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.
Comprendere i lock distribuiti con Redis è prezioso per coordinare l'accesso a risorse condivise tra sistemi distribuiti, quindi è una conoscenza utile — e comprendere le insidie di correttezza è particolarmente importante.
I lock distribuiti affrontano una necessità reale: garantire che solo un processo/server esegua un'azione critica alla volta (prevenendo elaborazione duplicata, race condition su risorse condivise, o operazioni in conflitto) nei sistemi multi-server, e Redis è uno strumento comune per questo.
Comprendere il meccanismo di base — SET key value NX EX (set-if-not-exists atomico con un TTL) cosicché solo un client acquisisce il lock e si rilascia automaticamente in caso di arresto — è la tecnica fondamentale.
Criticamente, comprendere i due dettagli di correttezza è essenziale: usare sempre un TTL (cosicché il lock di un titolare arrestato scada automaticamente, evitando deadlock permanente) e usare un token univoco con rilascio corrispondente (cosicché non rilasci accidentalmente il lock di un altro client se il tuo TTL è scaduto — con verifica-then-delete atomica tramite uno script Lua).
Questi dettagli sono dove le implementazioni ingenue hanno bug sottili e pericolosi.
Egualmente importante è comprendere le limitazioni: un lock su Redis singolo non è perfettamente sicuro (la scadenza del TTL durante il lavoro o il failover possono permettere a due client di tenerlo), portando all'algoritmo Redlock (acquisizione su più nodi Redis) per garanzie più forti — e sapere che per una correttezza critica, token di fencing o sistemi di consenso (ZooKeeper/etcd) potrebbero essere necessari.
Questa consapevolezza dei trade-off e delle limitazioni riflette una comprensione matura.
Poiché coordinare l'accesso a risorse condivise nei sistemi distribuiti è una necessità reale, e poiché i lock distribuiti Redis sono comuni ma richiedono un'implementazione corretta e attenta (TTL, token univoco, rilascio atomico) e consapevolezza delle loro limitazioni (Redlock, rischi di failover), comprendere i lock distribuiti con Redis — il meccanismo, i dettagli di correttezza e le limitazioni — è una conoscenza preziosa e praticamente rilevante per la coordinazione distribuita, un argomento in cui comprendere le insidie e i trade-off è importante quanto la tecnica di base.