Zápisy naprieč oblasťami: kde sa zmena vlastne potvrdí?
Smerovanie privedie požiadavku do oblasti; atomickým zápis robí až hranica transakcie. Pomenujte invariant, vyberte vlastníka a potom okolo neho navrhnite opakovanie.
Dva aplikačné servery v dvoch oblastiach, jeden klient zapisujúci cez VPN a otázka, ktorú nikto nezapísal: ktorá komponenta rozhoduje, že sa zápis stal? Smerovanie privedie požiadavku k procesu. Hranica transakcie rozhoduje, kedy sa zmena stane trvalou a viditeľnou. Sú to rôzne úlohy vykonávané rôznymi systémami a medzera medzi nimi je miesto, kde žije väčšina chýb zápisov do viacerých oblastí.
Začnite obchodným pravidlom, nie mapou
Začnite vetou o obchodnom pravidle, nie o geografii: ktoré čítania a zápisy musia uspieť spoločne a ktoré súbežné zmeny musia byť počas toho nemožné. Pre rezerváciu zásob to znamená, že kontrola zásob a rezervácia buď obe nadobudnú účinnosť, alebo ani jedna, a žiadna druhá objednávka nesmie medzitým spotrebovať rovnakú jednotku.
| Requirement | What satisfies it | What does not |
|---|---|---|
| All-or-nothing application | A transaction inside one owning system | A VPN path between regions |
| No double spend | Isolation strong enough to exclude the conflict | Atomicity alone |
| Survive a region loss | Replication the database itself documents | Two independent databases behind one client |
Práve ten stredný riadok tímy preskakujú. Atomicita bez dostatočnej izolácie umožní dvom transakciám, aby sa každá správne potvrdila a napriek tomu vytvorili stav, ktorý obchod považuje za nemožný, a žiadne množstvo logiky opakovania to potom nenapraví.
Jedna autoritatívna hranica porazí dva regionálne servery
Regionálne aplikačné servery môžu zostať tam, kde sú, ak operáciu predložia službe, ktorá ju vykoná v rámci jednej podporovanej hranice transakcie. Aplikačná vrstva sa stáva smerovačom zámeru; dátová vrstva vlastní pravdu.
Držte túto hranicu krátku a blízko dát, ktorých sa dotýka. Transakcia držaná otvorená, kým človek odpovedá na výzvu alebo kým volanie prechádza dvoma oblasťami, trávi čas držaním zámkov a zvyšuje šancu, že niečo iné za ňou vyprší. Toto zlyhanie vyzerá ako problém databázy a v skutočnosti je to problém návrhu, ktorý sa tak obliekol. Presun rozhodnutia do dátovej vrstvy ho zvyčajne úplne odstráni.
BEGIN;
UPDATE inventory SET reserved = reserved + 1
WHERE sku = 'A-100' AND available >= 1;
INSERT INTO reservation (sku, order_id) VALUES ('A-100', 'ord-9f');
COMMIT;Čítajte tento náčrt ako hranicu, nie ako odporúčanie výkonu. Pointa je, že kontrola a vloženie zdieľajú jedno potvrdenie, takže súbežná objednávka buď vidí zásobu spotrebovanú, alebo ju nevidí vôbec.
Čo replikovaná databáza dáva a čo nie
Replikovaná databáza môže poskytnúť širšiu hranicu, keď to podporuje jej vlastný transakčný model. Spanner dokumentuje atomické transakcie čítania a zápisu v rámci jednej databázy naprieč tabuľkami, s definovanou izoláciou a správaním opakovania. To je záruka, ktorú čítate, testujete a na ktorú sa zámerne spoliehate.
Je to aj záruka, ktorá pochádza z produktu, nie z trasy. VPN medzi oblasťami mení, ako cestujú pakety a ako sa prejavujú poruchy. Nerozširuje hranicu transakcie ani o jeden riadok, nech tunel vyzerá akokoľvek zdravo. Zámena oboch vytvára architektúry, kde každá komponenta prejde vlastnou kontrolou a dáta si stále odporujú.
Dve databázy sa nestanú jedným systémom
Dve nezávisle spravované databázy nezískajú spoločného správcu transakcií tým, že sa na obe klienti dostanú. Ak obchod skutočne potrebuje atomický záväzok naprieč touto dvojicou, koordinačný mechanizmus, účastníci a proces obnovy musia byť zvolené a kvalifikované, nie predpokladané.
Zamyslite sa nad okamihom, keď účastník alebo spojenie zmizne po tom, čo bola práca pripravená. Podporované distribuované potvrdenie môže zanechať neistý stav, ktorý potrebuje postup obnovy a ľudské rozhodnutie, a neprichádza s prísľubom, že každá oblasť zostane zapisovateľná počas každého rozdelenia.
Ak je namiesto toho prijateľná asynchrónna koordinácia, povedzte to výslovne a zapíšte medzistavy obchodu a pravidlá vyrovnania. Reťaz lokálne potvrdených krokov s kompenzáciou je legitímny návrh; jednoducho to nie je jedna atomická transakcia pod iným menom.
Navrhnite opakovanie pred prvým výpadkom
Klient môže stratiť odpoveď po tom, čo sa operácia potvrdila, takže volajúci nemôže časový limit považovať za zlyhanie. Zachovajte trvalú identitu požiadavky a pred opakovaním zmeny použite výsledok služby alebo mechanizmus idempotencie, inak sa opakovanie stane druhým zápisom.
Automatické spätné volania transakcií sa tiež môžu vykonať viac ako raz po opakovateľnom prerušení, čo z nich robí zlý domov pre nevratné vonkajšie účinky. Držte ich mimo spätného volania, ak pracovný postup pre ne nedefinuje výslovný bezpečný protokol. Rovnaká opatrnosť platí pre všetko, čo stojí peniaze alebo posiela správu. Dvojité strhnutie je omnoho ťažší rozhovor ako dvojitý riadok protokolu.
Prijatie by malo prehrať štyri scenáre: dvaja klienti pretekajúci o ten istý riadok, prerušenie, o ktorom služba tvrdí, že sa dá opakovať, potvrdenie, ktorého odpoveď nikdy nedorazí, a strata oblasti alebo spojenia medzi nimi. Zapíšte potvrdený obchodný výsledok a nevyriešené stavy vedľa návrhu smerovania, aby si nikto nepomýlil sieť s komponentou, ktorá záruku poskytuje.