Distribuirana bravica koordinira pristup dijeljenom resursu između više procesa/servera tako da samo jedan drži bravu u danom trenutku. Redis se obično koristi za ovo preko atomske set-if-not-exists operacije sa TTL-om — ali pravo izvođenje zahtijeva paznju (i razumijevanje ograničenja).
token = ();
acquired = redis.(, token, , , );
(acquired) {
{
} {
(, token);
}
}
Bravica koristi SET key value NX EX: atomski postavlja ključ samo ako nije prisutan (tako da samo jedan klijent uspije) sa TTL-om (tako da se bravica automatski oslobađa ako vlasnik padne, izbjegavajući 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.
Razumijevanje distribuiranih bravica sa Redisom je vrijedno za koordinaciju pristupa dijeljenim resursima preko distribuiranih sustava, tako da je korisno znanje — a razumijevanje zamki ispravnosti je posebno važno.
Distribuirane bravice rješavaju stvarnu potrebu: osiguravaju da samo jedan proces/server obavlja kritičnu akciju u danom trenutku (sprječavajući dupliranje obrade, race condition-e na dijeljenim resursima, ili konfliktne operacije) u multi-server sustavima, a Redis je česta alat za ovo.
Razumijevanje osnovnog mehanizma — SET key value NX EX (atomska set-if-not-exists sa TTL-om) tako da samo jedan klijent stekne bravu i ona se automatski oslobodi pri padu — je temeljna tehnika.
Kritično je razumijevanje dva detalja ispravnosti: uvijek korištenje TTL-a (tako da padnuta brava vlasnika automatski istekne, izbjegavajući permanentan deadlock) i korištenje jedinstvenog tokena sa podudarnom oslobađanjem (tako da slučajno ne oslobodite bravu drugog klijenta ako vam je TTL istekao — sa atomskom proverom-pa-brisanjem preko Lua skripte).
Ovi detalji su gdje imaju naivne implementacije suptilne, opasne greške.
Jednako važno je razumijevanje ograničenja: jednoga Redis-bravica nije savršeno sigurna (TTL isteka tijekom rada ili failover može omogućiti da dva klijenta drže je), što vodi do Redlock algoritma (stjecanje preko više Redis čvorova) za jače garancije — i znanje da za kritičnu ispravnost, fencing tokeni ili consensus sustavi (ZooKeeper/etcd) mogu biti potrebni.
Ova svjesnost o trade-off-ima i ograničenjima odražava zrelo razumijevanje.
Budući da je koordinacija pristupa dijeljenim resursima u distribuiranim sustavima stvarna potreba, i budući da su Redis distribuirane bravice česte ali zahtijevaju pažljivo ispravno izvođenje (TTL, jedinstveni token, atomsko oslobađanje) i svjesnost njihovih ograničenja (Redlock, failover rizici), razumijevanje distribuiranih bravica sa Redisom — mehanizam, detalje ispravnosti i ograničenja — je vrijedno, praktično relevantno znanje za distribuiranu koordinaciju, temu gdje je razumijevanje zamki i trade-off-ima jednako važno kao i osnovna tehnika.