Shkrime në shumë rajone: ku konfirmohet në të vërtetë ndryshimi?

Dy servera aplikacioni në dy rajone, një klient që shkruan përmes një VPN dhe një pyetje që askush nuk e shkroi: cili komponent vendos që shkrimi ndodhi? Rrugëtimi e çon kërkesën në një proces. Një kufi transaksioni vendos kur ndryshimi bëhet i qëndrueshëm dhe i dukshëm. Këto janë punë të ndryshme të kryera nga sisteme të ndryshme, dhe hendeku mes tyre është vendi ku jetojnë shumica e defekteve të shkrimit në shumë rajone.

Filloni nga rregulli i biznesit, jo nga harta

Filloni me një fjali për rregullin e biznesit dhe jo për gjeografinë: cilat lexime dhe shkrime duhet të kenë sukses së bashku dhe cilat ndryshime të njëkohshme duhet të jenë të pamundura gjatë kësaj. Për një rezervim inventari kjo do të thotë që kontrolli i stokut dhe rezervimi ose të dy hyjnë në fuqi ose asnjëri, dhe asnjë porosi e dytë nuk mund të konsumojë të njëjtën njësi në mes.

Pikërisht atë rreshtin e mesëm ekipet e kapërcejnë. Atomiteti pa izolim të mjaftueshëm i lejon dy transaksioneve të konfirmohen saktë secila dhe megjithatë të prodhojnë një gjendje që biznesi e konsideron të pamundur, dhe asnjë sasi logjike ripërpjekjeje nuk e rregullon atë më pas.

Një kufi autoritativ mposht dy servera rajonalë

Serverat rajonalë të aplikacionit mund të mbeten aty ku janë, për sa kohë që e dorëzojnë operacionin te një shërbim që e kryen brenda një kufiri të vetëm transaksioni të mbështetur. Shtresa e aplikacionit bëhet ruter i qëllimit; shtresa e të dhënave zotëron të vërtetën.

Mbajeni atë kufi të shkurtër dhe pranë të dhënave që prek. Një transaksion i mbajtur hapur ndërsa një njeri përgjigjet një kërkese, ose ndërsa një thirrje kalon dy rajone, e kalon kohën duke mbajtur bravë dhe duke rritur mundësinë që diçka tjetër të skadojë pas tij. Ai defekt duket si problem i bazës së të dhënave dhe në të vërtetë është problem projektimi i veshur si i tillë. Zhvendosja e vendimit në shtresën e të dhënave zakonisht e eliminon plotësisht.

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;

Lexojeni atë skicë si kufi, jo si rekomandim performance. Çështja është që kontrolli dhe futja ndajnë një konfirmim, prandaj një porosi e njëkohshme ose e sheh stokun të konsumuar ose nuk e sheh fare.

Çfarë jep dhe çfarë nuk jep një bazë të dhënash e replikuar

Një bazë të dhënash e replikuar mund të ofrojë një kufi më të gjerë kur modeli i vetë transaksioneve e mbështet. Spanner dokumenton transaksione atomike lexim-shkrim brenda një baze të dhënash përgjatë tabelave, me izolim dhe sjellje ripërpjekjeje të përcaktuar. Ky është një garanci që lexohet, testohet dhe mbi të cilën mbështetesh me vetëdije.

Është gjithashtu një garanci që vjen nga produkti, jo nga rruga. Një VPN mes rajoneve ndryshon si udhëtojnë paketat dhe si paraqiten defektet. Nuk e zgjat një kufi transaksioni as me një rresht, sado i shëndetshëm të duket tuneli. Ngatërrimi i të dyjave prodhon arkitektura ku çdo komponent e kalon kontrollin e vet dhe të dhënat ende nuk përputhen.

Dy baza të dhënash nuk bëhen një sistem

Dy baza të dhënash të administruara në mënyrë të pavarur nuk fitojnë një menaxher transaksionesh të përbashkët sepse klientët mund t'i arrijnë të dyja. Nëse biznesi ka vërtet nevojë për një angazhim atomik përgjatë çiftit, mekanizmi i koordinimit, pjesëmarrësit dhe procesi i rikuperimit duhet të zgjidhen dhe kualifikohen, jo të supozohen.

Mendoni për momentin kur një pjesëmarrës ose një lidhje zhduket pasi puna është përgatitur. Një konfirmim i shpërndarë i mbështetur mund të lërë një gjendje të pasigurt që kërkon procedurë rikuperimi dhe vendim njerëzor, dhe nuk vjen me premtimin se çdo rajon mbetet i shkruajtshëm përgjatë çdo ndarjeje.

Nëse përndryshe është i pranueshëm një koordinim asinkron, thojeni shprehimisht dhe shkruani gjendjet e ndërmjetme të biznesit bashkë me rregullat e rakordimit. Një zinxhir hapash të konfirmuar lokalisht me kompensim është një projektim i ligjshëm; thjesht nuk është një transaksion i vetëm atomik me një emër tjetër.

Projektoni ripërpjekjen para ndërprerjes së parë

Një klient mund të humbasë përgjigjen pasi operacioni është konfirmuar, prandaj thirrësi nuk mund ta trajtojë një afat kohor si dështim. Ruani një identitet kërkese të qëndrueshëm dhe përdorni rezultatin e shërbimit ose një mekanizëm idempotence përpara se të riprovoni një ndryshim, përndryshe ripërpjekja bëhet një shkrim i dytë.

Kthimet automatike të transaksioneve gjithashtu mund të ekzekutohen më shumë se një herë pas një anulimi të ripërsëritshëm, gjë që i bën ata një shtëpi të dobët për efekte të jashtme të pakthyeshme. Mbajini ato jashtë kthimit automatik, përveç nëse rrjedha e punës përcakton një protokoll të sigurt të qartë për to. I njëjti kujdes vlen për çdo gjë që kushton para ose dërgon një mesazh. Një tarifim i dyfishtë është një bisedë shumë më e vështirë sesa një rresht log i dyfishtë.

Pranimi duhet të riprodhojë katër skenarë: dy klientë që garojnë për të njëjtin rresht, një anulim që shërbimi thotë se është i ripërsëritshëm, një konfirmim përgjigjja e të cilit nuk arrin kurrë, dhe humbja e një rajoni ose e lidhjes mes tyre. Regjistroni rezultatin e biznesit të konfirmuar dhe gjendjet e pazgjidhura pranë projektimit të rrugëtimit, që askush të mos e ngatërrojë rrjetin me komponentin që ofron garancinë.