Rakstīšana vairākos reģionos: kur īsti notiek apstiprinājums?
Maršrutēšana aizved pieprasījumu uz reģionu; tikai transakcijas robeža padara rakstīšanu atomisku. Nosauciet invarianto, izvēlieties īpašnieku un pēc tam veidojiet atkārtojumu ap to.
Divi lietojumprogrammu serveri divos reģionos, viens klients, kas raksta caur VPN, un jautājums, ko neviens nepierakstīja: kura komponente izlemj, ka rakstīšana ir notikusi? Maršrutēšana aizved pieprasījumu līdz procesam. Transakcijas robeža izlemj, kad izmaiņas kļūst noturīgas un redzamas. Tie ir dažādi darbi, ko veic dažādas sistēmas, un plaisa starp tiem ir vieta, kur dzīvo lielākā daļa daudzreģionu rakstīšanas kļūdu.
Sāciet ar biznesa noteikumu, nevis ar karti
Sāciet ar teikumu par biznesa noteikumu, nevis par ģeogrāfiju: kuras lasīšanas un rakstīšanas operācijas jāpaveic kopā un kuras vienlaicīgas izmaiņas tajā laikā jābūt neiespējamām. Krājumu rezervācijai tas nozīmē, ka krājumu pārbaude un rezervācija vai nu abas stājas spēkā, vai neviena, un neviens otrs pasūtījums nedrīkst starplaikā izlietot to pašu vienību.
| 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 |
Gan tieši šo vidējo rindu komandas izlaiž. Atomiskums bez pietiekamas izolācijas ļauj divām transakcijām katrai pareizi apstiprināties un tomēr radīt stāvokli, ko bizness uzskata par neiespējamu, un vēlāk to nesalabo nekāda atkārtošanas loģika.
Viena autoritatīva robeža uzvar divus reģionālos serverus
Reģionālie lietojumprogrammu serveri var palikt savā vietā, ja tie iesniedz darbību pakalpojumam, kas to veic vienas atbalstītas transakcijas robežas ietvaros. Lietojumprogrammu slānis kļūst par nodoma maršrutētāju; datu slānis pārvalda patiesību.
Turiet šo robežu īsu un tuvu datiem, kurus tā skar. Transakcija, kas tiek turēta atvērta, kamēr cilvēks atbild uz uzvedni vai kamēr zvans šķērso divus reģionus, pavada savu laiku, turot slēdzenes un palielinot iespēju, ka kaut kas cits aiz tās nokavēs termiņu. Šī kļūme izskatās pēc datubāzes problēmas un patiesībā ir tā pārģērbta projektēšanas problēma. Lēmuma pārvietošana uz datu slāni to parasti novērš pilnībā.
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;Lasiet šo skici kā robežu, nevis kā veiktspējas ieteikumu. Būtība ir tā, ka pārbaude un ievietošana dala vienu apstiprinājumu, tāpēc vienlaicīgs pasūtījums vai nu redz krājumus izlietotus, vai neredz tos vispār.
Ko repliķēta datubāze dod un ko nedod
Repliķēta datubāze var nodrošināt plašāku robežu, ja to atbalsta tās pašas transakciju modelis. Spanner dokumentē atomiskas lasīšanas-rakstīšanas transakcijas vienas datubāzes ietvaros pāri tabulām, ar definētu izolāciju un atkārtošanas uzvedību. Tā ir garantija, ko jūs lasāt, pārbaudāt un apzināti uz to paļaujaties.
Tā ir arī garantija, kas nāk no produkta, nevis no maršruta. VPN starp reģioniem maina to, kā ceļo paketes un kā izpaužas kļūmes. Tas nepagarina transakcijas robežu pat par vienu rindu, lai cik vesels tuneļa izskatītos. Šo divu sajaukšana rada arhitektūras, kurās katra komponente iztur savu pārbaudi un dati tomēr nesaskan.
Divas datubāzes nekļūst par vienu sistēmu
Divas neatkarīgi pārvaldītas datubāzes neiegūst kopīgu transakciju pārvaldnieku tāpēc vien, ka klienti var sasniegt abas. Ja biznesam patiešām vajadzīga atomiska saistība pāri šim pārim, koordinācijas mehānisms, dalībnieki un atjaunošanas process ir jāizvēlas un jākvalificē, nevis jāpieņem kā pašsaprotami.
Padomājiet par brīdi, kad dalībnieks vai saite pazūd pēc tam, kad darbs ir sagatavots. Atbalstīts sadalītais apstiprinājums var atstāt nedrošu stāvokli, kam nepieciešama atjaunošanas procedūra un cilvēka lēmums, un tas nenāk ar solījumu, ka katrs reģions paliks rakstāms katras sadalīšanas laikā.
Ja tā vietā ir pieņemama asinhrona koordinācija, sakiet to skaidri un pierakstiet starpposma biznesa stāvokļus un saskaņošanas noteikumus. Lokāli apstiprinātu soļu ķēde ar kompensāciju ir likumīgs dizains; tas vienkārši nav viena atomiska transakcija citā nosaukumā.
Izveidojiet atkārtojumu pirms pirmā pārtraukuma
Klients var pazaudēt atbildi pēc tam, kad darbība ir apstiprināta, tāpēc izsaucējs nevar uzskatīt noildzi par kļūmi. Saglabājiet noturīgu pieprasījuma identitāti un pirms izmaiņu atkārtošanas izmantojiet pakalpojuma rezultātu vai idempotences mehānismu, citādi atkārtojums kļūst par otru rakstīšanu.
Automātiskie transakciju atzvanīšanas izsaukumi arī var izpildīties vairāk nekā vienreiz pēc atkārtojama pārtraukuma, kas padara tos par sliktu mājvietu neatgriezeniskiem ārējiem efektiem. Turiet tos ārpus atzvanīšanas, ja vien darbplūsma tiem nenosaka skaidru drošu protokolu. Tas pats piesardzība attiecas uz visu, kas maksā naudu vai sūta ziņojumu. Divkāršs maksājums ir daudz grūtāka saruna nekā divkārša žurnāla rinda.
Pieņemšanai jāatkārto četri scenāriji: divi klienti sacenšas par vienu un to pašu rindu, pārtraukums, ko pakalpojums nosauc par atkārtojamu, apstiprinājums, kura atbilde nekad neienāk, un reģiona vai saites starp tiem zudums. Pierakstiet apstiprināto biznesa rezultātu un neatrisinātos stāvokļus blakus maršrutēšanas dizainam, lai neviens nesajauktu tīklu ar komponenti, kas sniedz garantiju.