Zápisy napříč oblastmi: kde se změna vlastně potvrdí?

Dva aplikační servery ve dvou oblastech, jeden klient zapisující přes VPN a otázka, kterou nikdo nezapsal: která komponenta rozhoduje, že se zápis stal? Směrování dostane požadavek k procesu. Hranice transakce rozhoduje, kdy se změna stane trvalou a viditelnou. To jsou různé úlohy vykonávané různými systémy a mezera mezi nimi je místo, kde žije většina chyb zápisů do více oblastí.

Začněte obchodním pravidlem, ne mapou

Začněte větou o obchodním pravidle, nikoli o geografii: která čtení a zápisy musí uspět společně a které souběžné změny musí být během toho nemožné. Pro rezervaci zásob to znamená, že kontrola zásob a rezervace buď obě vstoupí v platnost, nebo ani jedna, a žádná druhá objednávka nesmí mezitím spotřebovat stejnou jednotku.

Právě tento prostřední řádek týmy přeskakují. Atomicita bez dostatečné izolace umožní dvěma transakcím, aby se každá správně potvrdila a přesto vytvořily stav, který obchod považuje za nemožný, a žádné množství logiky opakování to potom nespraví.

Jedna autoritativní hranice poráží dva regionální servery

Regionální aplikační servery mohou zůstat tam, kde jsou, pokud operaci předají službě, která ji provede v rámci jedné podporované hranice transakce. Aplikační vrstva se stává směrovačem záměru; datová vrstva vlastní pravdu.

Držte tuto hranici krátkou a blízko dat, kterých se dotýká. Transakce držená otevřená, zatímco člověk odpovídá na výzvu nebo zatímco volání přechází dvě oblasti, tráví čas držením zámků a zvyšuje šanci, že něco jiného za ní vyprší. Toto selhání vypadá jako problém databáze a ve skutečnosti je to problém návrhu, který se tak oblékl. Přesun rozhodnutí do datové vrstvy ho obvykle úplně odstraní.

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;

Čtěte tento náčrt jako hranici, ne jako doporučení výkonu. Pointa je, že kontrola a vložení sdílejí jedno potvrzení, takže souběžná objednávka buď vidí zásobu spotřebovanou, nebo ji nevidí vůbec.

Co replikovaná databáze dává a co ne

Replikovaná databáze může poskytnout širší hranici, když to její vlastní transakční model podporuje. Spanner dokumentuje atomické transakce čtení a zápisu v rámci jedné databáze napříč tabulkami, s definovanou izolací a chováním opakování. To je záruka, kterou čtete, testujete a na kterou se záměrně spoléháte.

Je to také záruka, která pochází z produktu, ne z trasy. VPN mezi oblastmi mění, jak pakety cestují a jak se poruchy projevují. Nerozšiřuje hranici transakce ani o jeden řádek, ať tunel vypadá jakkoli zdravě. Záměna obojího vytváří architektury, kde každá komponenta projde vlastní kontrolou a data si stále odporují.

Dvě databáze se nestanou jedním systémem

Dvě nezávisle spravované databáze nezískají společného správce transakcí tím, že se na obě klienti dostanou. Pokud obchod skutečně potřebuje atomický závazek přes obě, musí být koordinační mechanismus, účastníci a proces obnovy zvoleny a kvalifikovány, nikoli předpokládány.

Přemýšlejte o okamžiku, kdy účastník nebo spojení zmizí poté, co byla práce připravena. Podporované distribuované potvrzení může zanechat nejistý stav, který potřebuje postup obnovy a lidské rozhodnutí, a nepřichází s příslibem, že každá oblast zůstane zapisovatelná během každého rozdělení.

Pokud je místo toho přijatelná asynchronní koordinace, řekněte to výslovně a zapište mezistavy obchodu a pravidla vyrovnání. Řetězec lokálně potvrzených kroků s kompenzací je legitimní návrh; prostě to není jedna atomická transakce pod jiným jménem.

Navrhněte opakování dřív než první výpadek

Klient může ztratit odpověď poté, co se operace potvrdila, takže volající nemůže časový limit považovat za selhání. Zachovejte trvalou identitu požadavku a před opakováním změny použijte výsledek služby nebo mechanismus idempotence, jinak se opakování stane druhým zápisem.

Automatická zpětná volání transakcí se také mohou provést více než jednou po opakovatelném přerušení, což z nich dělá špatný domov pro nevratné vnější účinky. Držte je mimo zpětné volání, pokud pracovní postup pro ně nedefinuje výslovný bezpečný protokol. Stejná opatrnost platí pro cokoli, co stojí peníze nebo posílá zprávu. Dvojí stržení je mnohem těžší rozhovor než dvojí řádek protokolu.

Přijetí by mělo přehrát čtyři scénáře: dva klienty závodící o stejný řádek, přerušení, o kterém služba tvrdí, že ho lze opakovat, potvrzení, jehož odpověď nikdy nedorazí, a ztrátu oblasti nebo spojení mezi nimi. Zapište potvrzený obchodní výsledek a nevyřešené stavy vedle návrhu směrování, aby si nikdo nespletl síť s komponentou, která záruku poskytuje.