Skriving på tvers av regionar: kvar vert endringa eigentleg stadfesta?

To applikasjonsservarar i to regionar, ein klient som skriv gjennom ein VPN, og eit spørsmål ingen skreiv ned: kva komponent avgjer at skrivinga skjedde? Ruting fører førespurnaden til ein prosess. Ei transaksjonsgrense avgjer når endringa vert varig og synleg. Dette er ulike arbeidsoppgåver utførte av ulike system, og gapet mellom dei er der dei fleste feila i skriving på tvers av regionar bur.

Start med forretningsregelen, ikkje med kartet

Start med ei setning om forretningsregelen i staden for om geografien: kva lesingar og skrivingar må lukkast saman, og kva samtidige endringar må vere umoglege medan dei gjer det. For ei lagerreservasjon tyder det at lagerkontrollen og reservasjonen anten begge trer i kraft eller ingen av dei, og ingen andre ordrar kan bruke den same eininga imellom.

Det er nettopp den midtre rada team hoppar over. Atomisitet utan tilstrekkeleg isolasjon lèt to transaksjonar kvar verte stadfesta rett og likevel produsere ein tilstand som forretninga reknar som umogeleg, og inga mengd nytt-forsøk-logikk reparerer det i ettertid.

Éi autoritativ grense slår to regionale servarar

Regionale applikasjonsservarar kan verte der dei er, så lenge dei sender operasjonen til ein teneste som utfører han innanfor éi støtta transaksjonsgrense. Applikasjonslaget vert ein ruter for intensjon; datalaget eig sanninga.

Hald den grensa kort og nær dataa ho rører. Ein transaksjon som vert halden open medan eit menneske svarar på ein førespurnad, eller medan eit kall kryssar to regionar, brukar tida si på å halde låsar og aukar sjansen for at noko anna går ut på tid bak han. Den feilen ser ut som eit databaseproblem og er eigentleg eit designproblem som har kledd seg ut som eit. Å flytte avgjerda ned i datalaget fjernar han vanlegvis heilt.

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;

Les den skissa som ei grense, ikkje som ei ytingsanbefaling. Poenget er at kontrollen og innsetjinga deler éi stadfesting, så ein samtidig ordre ser anten lageret brukt eller ser det ikkje i det heile.

Kva ein replikert database gir og ikkje gir

Ein replikert database kan gi ei breiare grense når hans eigen transaksjonsmodell støttar det. Spanner dokumenterer atomiske lese-skrive-transaksjonar innanfor éin database på tvers av tabellar, med definert isolasjon og nytt-forsøk-åtferd. Det er ein garanti ein les, testar og medvite kviler på.

Det er òg ein garanti som kjem frå produktet, ikkje frå ruta. Ein VPN mellom regionar endrar korleis pakkar reiser og korleis feil viser seg. Han forlenger ikkje ei transaksjonsgrense med éi einaste rad, same kor sunn tunnelen ser ut. Å blande dei to skaper arkitekturer der kvar komponent består sin eigen kontroll og dataa framleis er usamde.

To databasar vert ikkje eitt system

To uavhengig administrerte databasar får ikkje ein felles transaksjonshandsamar fordi klientar kan nå begge. Viss forretninga verkeleg treng ei atomisk forplikting over paret, må koordineringsmekanismen, deltakarane og attopprettingsprosessen alle veljast og kvalifiserast i staden for å verte tekne for gitt.

Tenk på augneblinken der ein deltakar eller ei lenkje forsvinn etter at arbeidet er førebudd. Ei støtta distribuert stadfesting kan etterlate ein uavklara tilstand som treng ein attopprettingsprosedyre og ei menneskeleg avgjerd, og ho kjem utan eit løfte om at kvar region held fram med å vere skrivbar gjennom kvar partisjon.

Om asynkron koordinering i staden er akseptabelt, sei det eksplisitt og skriv ned dei mellomliggjande forretningstilstandane og avstemmingsreglane. Ei kjede av lokalt stadfesta steg med kompensasjon er eit legitimt design; det er berre ikkje éin atomisk transaksjon under eit anna namn.

Design nytt forsøket før den første avbrota

Ein klient kan miste svaret etter at operasjonen er stadfesta, så den som kallar kan ikkje handsame tidsavbrot som feil. Ta vare på ein varig førespurnadsidentitet og bruk resultatet av tenesta eller ein idempotensmekanisme før ei endring vert prøvd på nytt, elles vert nytt forsøk ei andre skriving.

Automatiske transaksjons-callbacks kan òg køyre meir enn éin gong etter ei avbrot som kan prøvast på nytt, noko som gjer dei til eit dårleg heim for irreversible eksterne effektar. Hald dei utanfor callbacken med mindre arbeidsflyten definerer ein eksplisitt trygg protokoll for dei. Same varsemd gjeld for alt som kostar pengar eller sender ei melding. Ei dobbel belastning er ein mykje vanskelegare samtale enn ei dobbel logglinje.

Godtaking bør spele av fire scenario: to klientar som kjempar om same rad, ei avbrot tenesta seier kan prøvast på nytt, ei stadfesting der svaret aldri kjem, og tapet av ein region eller lenkja mellom dei. Registrer det stadfesta forretningsresultatet og dei uavklara tilstandane ved sida av rutingsdesignet, så ingen forvekslar nettverket med komponenten som gir garantien.