Un verrou distribué coordonne l'accès à une ressource partagée entre plusieurs processus/serveurs pour que seul un détienne le verrou à la fois. Redis est couramment utilisé pour cela via une opération atomique de création-si-absent avec un TTL — bien que le faire correctement nécessite de la prudence (et de comprendre les limitations).
token = ();
acquired = redis.(, token, , , );
(acquired) {
{
} {
(, token);
}
}
Le verrou utilise SET key value NX EX : définir atomiquement la clé seulement si absent (pour que seul un client réussisse) avec un TTL (pour que le verrou se libère automatiquement si le détenteur plante, évitant un blocage).
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.
Comprendre les verrous distribués avec Redis est précieux pour coordonner l'accès aux ressources partagées dans les systèmes distribués, c'est donc une connaissance utile — et comprendre les pièges de correction est particulièrement important.
Les verrous distribués répondent à un vrai besoin : s'assurer que seul un processus/serveur exécute une action critique à la fois (prévenir le traitement en double, les conditions de course sur les ressources partagées, ou les opérations conflictuelles) dans les systèmes multi-serveurs, et Redis est un outil courant pour cela.
Comprendre le mécanisme basique — SET key value NX EX (création atomique-si-absent avec un TTL) pour que seul un client acquière le verrou et qu'il se libère automatiquement en cas de plante — est la technique fondamentale.
De manière critique, comprendre les deux détails de correction est essentiel : toujours utiliser un TTL (pour que le verrou d'un détenteur plantant expire automatiquement, évitant un blocage permanent) et utiliser un jeton unique avec une libération appariée (pour que vous ne libériez pas accidentellement le verrou d'un autre client si votre TTL a expiré — avec suppression atomique vérifiée via un script Lua).
Ces détails sont où les implémentations naïves ont des bogues subtils et dangereux.
Également important est de comprendre les limitations : un verrou Redis unique n'est pas parfaitement sûr (expiration du TTL au milieu du travail ou basculement peut laisser deux clients le détenir), ce qui conduit à l'algorithme Redlock (acquisition sur plusieurs nœuds Redis) pour des garanties plus fortes — et savoir que pour une correction critique, des jetons de clôture ou des systèmes de consensus (ZooKeeper/etcd) peuvent être nécessaires.
Cette conscience des compromis et limitations reflète une compréhension mature.
Comme coordonner l'accès aux ressources partagées dans les systèmes distribués est un vrai besoin, et comme les verrous distribués Redis sont courants mais nécessitent une implémentation correcte attentive (TTL, jeton unique, libération atomique) et la conscience de leurs limitations (Redlock, risques de basculement), comprendre les verrous distribués avec Redis — le mécanisme, les détails de correction, et les limitations — est une connaissance valide et pratiquement pertinente pour la coordination distribuée, un sujet où comprendre les pièges et les compromis est aussi important que la technique basique.