Pisanje u više regija: gdje se commit zapravo dogodi?

Dva aplikacijska servera u dvije regije, jedan klijent koji piše kroz VPN i pitanje koje nitko nije zapisao: koja komponenta odlučuje da se pisanje dogodilo? Routing dovodi zahtjev do procesa. Granica transakcije odlučuje kada promjena postaje trajna i vidljiva. To su različiti poslovi koje obavljaju različiti sustavi, a jaz između njih je mjesto gdje živi većina pogrešaka pisanja u više regija.

Krenite od poslovnog pravila, ne od karte

Započnite rečenicom o poslovnom pravilu, a ne o geografiji: koja čitanja i pisanja moraju uspjeti zajedno i koje istovremene promjene moraju biti nemoguće dok se to odvija. Za rezervaciju zaliha to znači da provjera zaliha i rezervacija ili obje stupaju na snagu ili nijedna, i nijedna druga narudžba ne smije potrošiti istu jedinicu u međuvremenu.

Upravo taj srednji red timovi preskaču. Atomarnost bez dovoljne izolacije dopušta dvjema transakcijama da se svaka ispravno potvrde i ipak proizvedu stanje koje posao smatra nemogućim, a nikakva količina logike ponovnog pokušaja to poslije ne popravlja.

Jedna mjerodavna granica pobjeđuje dva regionalna servera

Regionalni aplikacijski serveri mogu ostati gdje jesu, sve dok operaciju predaju servisu koji je izvodi unutar jedne podržane granice transakcije. Aplikacijski sloj postaje usmjerivač namjere; podatkovni sloj posjeduje istinu.

Držite tu granicu kratkom i blizu podataka koje dotiče. Transakcija držana otvorenom dok čovjek odgovara na upit ili dok poziv prelazi dvije regije provodi vrijeme držeći brave i povećavajući šansu da će nešto drugo isteći za njom. Taj kvar izgleda kao problem baze podataka, a zapravo je problem dizajna odjeven u takav. Premještanje odluke u podatkovni sloj obično ga uklanja u potpunosti.

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;

Čitajte tu skicu kao granicu, ne kao preporuku za izvedbu. Poanta je da provjera i umetanje dijele jedno potvrđivanje, pa istovremena narudžba ili vidi zalihe potrošene ili ih uopće ne vidi.

Što replikacija baze podataka daje, a što ne daje

Replicirana baza podataka može pružiti širu granicu kada to podržava njezin vlastiti model transakcija. Spanner dokumentira atomske transakcije čitanja i pisanja unutar jedne baze podataka preko tablica, s definiranom izolacijom i ponašanjem ponovnog pokušaja. To je jamstvo koje čitate, testirate i na koje se namjerno oslanjate.

To je također jamstvo koje dolazi od proizvoda, a ne od rute. VPN između regija mijenja kako paketi putuju i kako se kvarovi predstavljaju. On ne proširuje granicu transakcije ni za jedan redak, koliko god tunel izgledao zdrav. Miješanje toga dvoga stvara arhitekture u kojima svaka komponenta prolazi vlastitu provjeru, a podaci se i dalje ne slažu.

Dvije baze podataka ne postaju jedan sustav

Dvije neovisno upravljane baze podataka ne dobivaju zajedničkog upravitelja transakcija time što klijenti mogu dohvatiti obje. Ako posao doista treba atomsku predanost preko tog para, mehanizam koordinacije, sudionici i proces oporavka moraju se odabrati i kvalificirati, a ne pretpostaviti.

Razmislite o trenutku kada sudionik ili veza nestane nakon što je posao pripremljen. Podržana distribuirana potvrda može ostaviti neizvjesno stanje kojem trebaju postupak oporavka i ljudska odluka, i dolazi bez obećanja da će svaka regija ostati dostupna za pisanje kroz svaku podjelu.

Ako je umjesto toga prihvatljiva asinkrona koordinacija, recite to izričito i zapišite međustanja posla plus pravila usklađivanja. Lanac lokalno potvrđenih koraka s kompenzacijom legitiman je dizajn; jednostavno nije jedna atomska transakcija pod drugim imenom.

Projektirajte ponovni pokušaj prije prvog prekida

Klijent može izgubiti odgovor nakon što je operacija potvrđena, pa pozivatelj ne može vrijeme isteka smatrati kvarom. Sačuvajte trajni identitet zahtjeva i upotrijebite ishod servisa ili mehanizam idempotencije prije ponovnog pokušaja izmjene, inače ponovni pokušaj postaje drugo pisanje.

Automatski povratni pozivi transakcija također se mogu izvršiti više od jednom nakon prekida koji se može ponoviti, što ih čini lošim domom za nepovratne vanjske učinke. Držite ih izvan povratnog poziva osim ako tijek rada za njih definira izričiti sigurni protokol. Isto se odnosi na sve što košta novac ili šalje poruku. Dvostruko terećenje mnogo je teži razgovor od dvostrukog retka zapisa.

Prihvaćanje treba ponovno odigrati četiri scenarija: dva klijenta koja se natječu za isti redak, prekid za koji servis kaže da se može ponoviti, potvrdu čiji odgovor nikada ne stigne i gubitak regije ili veze među njima. Zapišite potvrđeni poslovni rezultat i neriješena stanja uz dizajn routinga, da nitko ne zamijeni mrežu s komponentom koja pruža jamstvo.