Slovník pojmů

Distribuovaný zámek: koordinace práce mezi procesy a servery

Zámek omezuje souběh kritické práce. Není to databázový zámek ani absolutní záruka správnosti business operace.

Stručná definice

Jeden držitel pro jasně vymezenou práci.

Hodí se například tehdy, když dvě instance aplikace mohou spustit stejnou plánovanou úlohu nebo když více workerů synchronizuje tentýž sklad. Cílem je mutual exclusion: v rámci zvolené garance má pracovat jen jeden držitel zámku.

Zámek pracuje v omezeném časovém okně. Musí proto počítat s pádem procesu, prodlevou sítě, pozastavením běhu i vypršením platnosti. Výsledek práce má mít vlastní ochranu proti duplicitě, i když před ní zámek existuje.

Použití

Kdy koordinace dává smysl

Zámek má být co nejužší a vázaný na konkrétní sdílený zdroj.

jedna plánovaná úloha napříč více servery
synchronizace konkrétního skladu nebo marketplace účtu
import dávky produktů, který nesmí souběžně měnit stejná data
omezení nákladného přepočtu reportu
koordinace workerů, pokud ji sama fronta neposkytuje

Praktický příklad

Synchronizace skladu warehouse-42

Dvě instance workeru dostanou stejný plánovací signál. Worker A se pokusí získat lock:stock-sync:warehouse-42 příkazem SET s náhodným tokenem, NX a PX 30000. Worker B neuspěje a úlohu ukončí nebo zařadí řízený retry.

A načte data dodavatele a zapíše změny. Zápis skladu musí zůstat bezpečný i při druhé události: constraint, stavový přechod nebo idempotency key chrání výsledný stav. Kdyby A po expiraci pokračoval, nesmí zámek B smazat ani přepsat novější data.

Sekvence dvou procesů

Worker A a Worker B soutěží o stejný sklad

TTL zvyšuje dostupnost po pádu, zároveň však vytváří riziko pozdě probuzeného držitele.

A získá zámek Redis atomicky vytvoří klíč s tokenem A a TTL například třicet sekund.
B neuspěje Klíč existuje, SET … NX vrátí neúspěch; B nesmí cizí zámek mazat.
A pracuje Kritická část má být krátká. Při prodlužování lease A ověřuje, že je stále vlastníkem.
TTL vyprší A může být pozastavený. B pak získá nový zámek s odlišným tokenem.
Stale owner Pozdní A nesmí odemknout B ani přepsat novější stav; kritické cíle mohou používat fencing token.

Důležité vlastnosti

Token, TTL a atomické podmínky

Mechanismus musí odlišit vlastníka zámku od dalšího pokusu o stejnou práci.

SET NX PX

V Redis lze základní získání zámku provést atomicky příkazem SET key token NX PX ttl: klíč vznikne jen pokud neexistuje a dostane expiraci.

Owner token

Náhodná jedinečná hodnota patří jednomu pokusu. Prosté DEL je chybné: pozdní proces by mohl smazat zámek, který po expiraci získal někdo jiný.

Lease a prodloužení

TTL chrání před trvalým blokem po pádu. Prodloužení musí porovnat token a proběhnout atomicky; nekonečné prodlužování zhoršuje dostupnost.

Fencing token

Rostoucí číslo musí pocházet z monotónního autoritativního zdroje. Cílová služba ho při zápisu porovnává a odmítne starší příkaz; teprve tím chrání před stale ownerem lépe než samotný token.

Co zámek neřeší

Zámek, idempotence a autoritativní data

Souběh a duplicitní businessový účinek jsou rozdílné problémy.

Idempotence: Určuje, že opakovaný příkaz nevytvoří druhý výsledek. Je nutná po timeoutu a duplicitním doručení.
Unikátní constraint: Databázově chrání business identitu i tehdy, když zámek selže nebo skončí.
Failover: Replika a failover neznamenají automaticky silnou konzistenci; síťové oddělení může vytvořit nejistotu vlastnictví.
Exactly once: Zámek ani jedno ID zprávy neslibují end-to-end přesně jedno zpracování. Příjemce potřebuje idempotentní návrh.

Výhody a omezení

Užitečná koordinace, nikoli univerzální pojistka

Přínosy

omezuje konfliktní a nákladnou souběžnou práci
TTL nakonec uvolní zdroj po pádu držitele
umožní provozovat jednu úlohu na více instancích
vymezí kritickou část a její skutečně sdílený zdroj

Časté chyby

DEL bez ověření owner tokenu
držení zámku přes dlouhý import, čekání na HTTP nebo uživatelskou interakci
globální zámek pro celý e-shop místo konkrétního zdroje
použití zámku místo constraintu a idempotence

Hranice použití

Přiměřený mechanismus podle požadované garance.

Pro krátkou úlohu může stačit databázový constraint nebo plánovač s jediným během. Redis lock je přiměřený pro úzkou kritickou sekci, například jeden sklad nebo jeden marketplace účet.

U citlivé koordinace nestačí pohodlné API zámku. Je nutné posoudit stale ownery, failover, fencing tokeny i to, zda cílové úložiště umí odmítnout zastaralý zápis.

Na co myslet

Zámek má být měřitelný a krátký

Než ho zavedete, ověřte, jak systém zachází s neúspěšným získáním i pádem držitele.

jednoznačný klíč zámku podle konkrétního zdroje
náhodný owner token a podmíněné uvolnění
TTL odpovídající reálné kritické části
měření kolizí, expirací a délky držení
idempotentní zápis výsledku a databázová ochrana

Časté otázky

Co distribuovaný zámek garantuje

Je Redis lock totéž co SETNX?

Ne. SETNX je starší příkaz pro podmíněné vytvoření klíče. Nový návrh používá SET s NX a expirací, owner tokenem a bezpečným uvolněním.

Proč nestačí zámek po dokončení smazat DEL?

Původní proces mohl být pozastavený. Jeho TTL vypršelo a zámek získal jiný proces; pozdní DEL by odstranil cizí zámek.

Zaručí zámek přesně jedno zpracování zprávy?

Ne. Zpráva se může doručit znovu a klient opakovat požadavek. Výsledný stav potřebuje idempotenci a obvykle databázovou ochranu.

Musím použít Redlock?

Ne nutně. Jedna Redis instance s TTL může být přiměřená pro méně kritickou koordinaci. U vyšší konzistence je nutné posoudit failover, síťové oddělení a fencing tokeny.

Jak princip používám v praxi

Koordinaci úloh navrhuji spolu s ochranou výsledného stavu.

Ve veřejném projektu scheduling jsou vidět principy plánování úloh napříč servery, testování a odolnosti vůči souběhu.

Zobrazit přístup k architektuře aplikací Nezávazně probrat projekt

Otevřít projekt scheduling