Paskirstytosios transakcijos: išsami dviejų fazių patvirtinimo (2PC) analizė

Šiuolaikiniame vis labiau susietame pasaulyje programoms dažnai reikia sąveikauti su duomenimis, saugomais keliose nepriklausomose sistemose. Taip atsiranda paskirstytųjų transakcijų koncepcija, kai viena loginė operacija reikalauja atlikti pakeitimus keliose duomenų bazėse ar paslaugose. Duomenų nuoseklumo užtikrinimas tokiose situacijose yra svarbiausias, o vienas iš labiausiai žinomų protokolų tam pasiekti yra dviejų fazių patvirtinimas (2PC).

Kas yra paskirstyta transakcija?

Paskirstyta transakcija yra operacijų seka, atliekama keliose, geografiškai išsklaidytose sistemose, traktuojama kaip vienas atominis vienetas. Tai reiškia, kad arba visos transakcijos operacijos turi būti sėkmingos (patvirtintos), arba nė viena neturi būti įvykdyta (atšaukta). Šis „viskas arba nieko“ principas užtikrina duomenų vientisumą visoje paskirstytoje sistemoje.

Įsivaizduokite scenarijų, kai klientas Tokijuje užsisako skrydį iš Tokijo į Londoną vienoje oro linijų sistemoje ir tuo pačiu metu rezervuoja viešbučio kambarį Londone kitoje viešbučių rezervavimo sistemoje. Šios dvi operacijos (skrydžio užsakymas ir viešbučio rezervacija) idealiai turėtų būti traktuojamos kaip viena transakcija. Jei skrydžio užsakymas pavyksta, o viešbučio rezervacija nepavyksta, sistema turėtų idealiai atšaukti skrydžio užsakymą, kad klientas neliktų Londone be nakvynės. Toks koordinuotas elgesys yra paskirstytosios transakcijos esmė.

Pristatome dviejų fazių patvirtinimo (2PC) protokolą

Dviejų fazių patvirtinimo (2PC) protokolas yra paskirstytasis algoritmas, užtikrinantis atomiškumą tarp kelių išteklių valdytojų (pvz., duomenų bazių). Jį sudaro centrinis koordinatorius ir keli dalyviai, kurių kiekvienas yra atsakingas už konkretų išteklių valdymą. Protokolas veikia dviem skirtingomis fazėmis:

1 fazė: Pasiruošimo fazė

Šioje fazėje koordinatorius inicijuoja transakciją ir prašo kiekvieno dalyvio pasiruošti arba patvirtinti, arba atšaukti transakciją. Vykdomi šie veiksmai:

1. Koordinatorius siunčia pasiruošimo užklausą: Koordinatorius siunčia „pasiruošimo“ pranešimą visiems dalyviams. Šis pranešimas signalizuoja, kad koordinatorius yra pasirengęs patvirtinti transakciją, ir prašo kiekvieno dalyvio pasiruošti tai padaryti.
2. Dalyviai ruošiasi ir atsako: Kiekvienas dalyvis gauna pasiruošimo užklausą ir atlieka šiuos veiksmus:
   • Jis imasi būtinų veiksmų, kad užtikrintų, jog gali arba patvirtinti, arba atšaukti transakciją (pvz., rašydamas „redo/undo“ žurnalus).
   • Jis siunčia „balsą“ atgal koordinatoriui, nurodydamas arba „pasiruošęs patvirtinti“ („taip“ balsas), arba „negali patvirtinti“ („ne“ balsas). „Ne“ balsas gali būti dėl išteklių apribojimų, duomenų patvirtinimo klaidų ar kitų trikdžių.

Labai svarbu, kad dalyviai, balsavę „taip“, garantuotų, jog galės patvirtinti arba atšaukti pakeitimus. Tai paprastai apima pakeitimų išsaugojimą patvariojoje laikmenoje (pvz., diske).

2 fazė: Patvirtinimo arba atšaukimo fazė

Šią fazę inicijuoja koordinatorius, remdamasis pasiruošimo fazėje gautais dalyvių balsais. Galimi du rezultatai:

1 rezultatas: Patvirtinimas

Jei koordinatorius gauna „taip“ balsus iš visų dalyvių, jis tęsia transakcijos patvirtinimą.

1. Koordinatorius siunčia patvirtinimo užklausą: Koordinatorius siunčia „patvirtinimo“ pranešimą visiems dalyviams.
2. Dalyviai patvirtina: Kiekvienas dalyvis gauna patvirtinimo užklausą ir visam laikui pritaiko su transakcija susijusius pakeitimus savo ištekliams.
3. Dalyviai patvirtina gavimą: Kiekvienas dalyvis siunčia patvirtinimo pranešimą atgal koordinatoriui, kad patvirtintų, jog patvirtinimo operacija buvo sėkminga.
4. Koordinatorius užbaigia: Gavęs patvirtinimus iš visų dalyvių, koordinatorius pažymi transakciją kaip užbaigtą.

2 rezultatas: Atšaukimas

Jei koordinatorius gauna bent vieną „ne“ balsą iš bet kurio dalyvio, arba jei baigiasi laukimo laikas, kol bus gautas atsakymas iš dalyvio, jis nusprendžia atšaukti transakciją.

1. Koordinatorius siunčia atšaukimo užklausą: Koordinatorius siunčia „atšaukimo“ pranešimą visiems dalyviams.
2. Dalyviai atšaukia: Kiekvienas dalyvis gauna atšaukimo užklausą ir atšaukia visus pakeitimus, kurie buvo atlikti ruošiantis transakcijai.
3. Dalyviai patvirtina gavimą: Kiekvienas dalyvis siunčia patvirtinimo pranešimą atgal koordinatoriui, kad patvirtintų, jog atšaukimo operacija buvo sėkminga.
4. Koordinatorius užbaigia: Gavęs patvirtinimus iš visų dalyvių, koordinatorius pažymi transakciją kaip užbaigtą.

Iliustruojantis pavyzdys: el. prekybos užsakymų apdorojimas

Įsivaizduokite el. prekybos sistemą, kurioje užsakymas apima atsargų duomenų bazės atnaujinimą ir mokėjimo apdorojimą per atskirą mokėjimo šliuzą. Tai yra dvi atskiros sistemos, kurios turi dalyvauti paskirstytoje transakcijoje.

1. Pasiruošimo fazė:
   • El. prekybos sistema (koordinatorius) siunčia pasiruošimo užklausą atsargų duomenų bazei ir mokėjimo šliuzui.
   • Atsargų duomenų bazė patikrina, ar prašomos prekės yra sandėlyje, ir jas rezervuoja. Tada ji balsuoja „taip“, jei sėkmingai, arba „ne“, jei prekių nėra sandėlyje.
   • Mokėjimo šliuzas iš anksto autorizuoja mokėjimą. Tada jis balsuoja „taip“, jei sėkmingai, arba „ne“, jei autorizacija nepavyksta (pvz., nepakanka lėšų).
2. Patvirtinimo/atšaukimo fazė:
   • Patvirtinimo scenarijus: Jei tiek atsargų duomenų bazė, tiek mokėjimo šliuzas balsuoja „taip“, koordinatorius siunčia patvirtinimo užklausą abiem. Atsargų duomenų bazė visam laikui sumažina prekių skaičių, o mokėjimo šliuzas užfiksuoja mokėjimą.
   • Atšaukimo scenarijus: Jei atsargų duomenų bazė arba mokėjimo šliuzas balsuoja „ne“, koordinatorius siunčia atšaukimo užklausą abiem. Atsargų duomenų bazė atlaisvina rezervuotas prekes, o mokėjimo šliuzas anuliuoja išankstinę autorizaciją.

Dviejų fazių patvirtinimo privalumai

• Atomiškumas: 2PC garantuoja atomiškumą, užtikrindamas, kad visos dalyvaujančios sistemos kartu arba patvirtina, arba atšaukia transakciją, išlaikydamos duomenų nuoseklumą.
• Paprastumas: 2PC protokolas yra gana paprastas suprasti ir įgyvendinti.
• Platus pritaikymas: Daugelis duomenų bazių sistemų ir transakcijų apdorojimo sistemų palaiko 2PC.

Dviejų fazių patvirtinimo trūkumai

• Blokavimas: 2PC gali sukelti blokavimą, kai dalyviai yra priversti laukti, kol koordinatorius priims sprendimą. Jei koordinatorius sugenda, dalyviai gali būti blokuojami neribotą laiką, laikydami išteklius ir neleisdami vykdyti kitų transakcijų. Tai yra didelė problema aukšto pasiekiamumo sistemose.
• Vieno gedimo taškas: Koordinatorius yra vieno gedimo taškas. Jei koordinatorius sugenda prieš siunčiant patvirtinimo arba atšaukimo užklausą, dalyviai lieka neapibrėžtoje būsenoje. Tai gali sukelti duomenų nenuoseklumą arba išteklių aklavietes.
• Našumo pridėtinės išlaidos: Dviejų fazių protokolo pobūdis sukelia dideles pridėtines išlaidas, ypač geografiškai paskirstytose sistemose, kur tinklo delsa yra didelė. Keli komunikacijos etapai tarp koordinatoriaus ir dalyvių gali žymiai paveikti transakcijų apdorojimo laiką.
• Sudėtingas gedimų valdymas: Atsigavimas po koordinatoriaus gedimų ar tinklo pertvarų gali būti sudėtingas, reikalaujantis rankinio įsikišimo arba sudėtingų atkūrimo mechanizmų.
• Mastelio keitimo apribojimai: Didėjant dalyvių skaičiui, 2PC sudėtingumas ir pridėtinės išlaidos auga eksponentiškai, ribodami jo mastelio keitimą didelio masto paskirstytose sistemose.

Dviejų fazių patvirtinimo alternatyvos

Dėl 2PC apribojimų atsirado keletas alternatyvių paskirstytųjų transakcijų valdymo metodų. Tai apima:

• Trijų fazių patvirtinimas (3PC): 2PC praplėtimas, kuris bando išspręsti blokavimo problemą įvesdamas papildomą fazę, skirtą pasiruošti patvirtinimo sprendimui. Tačiau 3PC vis dar yra pažeidžiamas blokavimui ir yra sudėtingesnis nei 2PC.
• „Saga“ šablonas: Ilgai trunkančios transakcijos šablonas, kuris suskaido paskirstytąją transakciją į vietinių transakcijų seriją. Kiekviena vietinė transakcija atnaujina vieną paslaugą. Jei viena transakcija nepavyksta, vykdomos kompensuojančios transakcijos, kad būtų atšauktas ankstesnių transakcijų poveikis. Šis šablonas tinka galutinio nuoseklumo scenarijams.
• Dviejų fazių patvirtinimas su kompensuojančiomis transakcijomis: Sujungia 2PC kritinėms operacijoms su kompensuojančiomis transakcijomis mažiau kritinėms operacijoms. Šis metodas leidžia suderinti stiprų nuoseklumą ir našumą.
• Galutinis nuoseklumas: Nuoseklumo modelis, leidžiantis laikinus nenuoseklumus tarp sistemų. Duomenys ilgainiui taps nuoseklūs, tačiau gali būti delsa. Šis metodas tinka programoms, kurios gali toleruoti tam tikrą nenuoseklumo lygį.
• BASE (Basically Available, Soft state, Eventually consistent): Principų rinkinys, kuris teikia pirmenybę pasiekiamumui ir našumui, o ne stipriam nuoseklumui. Pagal BASE principus sukurtos sistemos yra atsparesnės gedimams ir gali lengviau keisti mastelį.

Praktinis dviejų fazių patvirtinimo taikymas

Nepaisant apribojimų, 2PC vis dar naudojamas įvairiuose scenarijuose, kur stiprus nuoseklumas yra kritinis reikalavimas. Keletas pavyzdžių:

• Bankininkystės sistemos: Lėšų pervedimui tarp sąskaitų dažnai reikalinga paskirstyta transakcija, siekiant užtikrinti, kad pinigai būtų atomiškai nurašyti iš vienos sąskaitos ir įskaityti į kitą. Įsivaizduokite tarpvalstybinę mokėjimo sistemą, kurioje siunčiantis ir gaunantis bankai yra skirtingose sistemose. 2PC galėtų būti naudojamas siekiant užtikrinti, kad lėšos būtų pervestos teisingai, even if one of the banks experiences a temporary failure.
• Užsakymų apdorojimo sistemos: Kaip parodyta el. prekybos pavyzdyje, 2PC gali užtikrinti, kad užsakymo pateikimas, atsargų atnaujinimas ir mokėjimo apdorojimas būtų atliekami atomiškai.
• Išteklių valdymo sistemos: Išteklių, tokių kaip virtualios mašinos ar tinklo pralaidumas, paskirstymas keliose sistemose gali reikalauti paskirstytosios transakcijos, siekiant užtikrinti, kad ištekliai būtų paskirstyti nuosekliai.
• Duomenų bazių replikacija: Nuoseklumo palaikymas tarp replikuotų duomenų bazių gali apimti paskirstytąsias transakcijas, ypač scenarijuose, kai duomenys atnaujinami vienu metu keliose replikose.

Dviejų fazių patvirtinimo įgyvendinimas

2PC įgyvendinimas reikalauja atidaus įvairių veiksnių apsvarstymo, įskaitant:

• Transakcijų koordinatorius: Tinkamo transakcijų koordinatoriaus pasirinkimas yra labai svarbus. Daugelis duomenų bazių sistemų teikia integruotus transakcijų koordinatorius, o kitos parinktys apima atskirus transakcijų valdytojus, tokius kaip JTA (Java Transaction API), arba paskirstytuosius transakcijų koordinatorius pranešimų eilėse.
• Išteklių valdytojai: Būtina užtikrinti, kad išteklių valdytojai palaikytų 2PC. Dauguma modernių duomenų bazių sistemų ir pranešimų eilių teikia 2PC palaikymą.
• Gedimų valdymas: Tvirtų gedimų valdymo mechanizmų įgyvendinimas yra labai svarbus siekiant sumažinti koordinatoriaus ar dalyvių gedimų poveikį. Tai gali apimti transakcijų žurnalų naudojimą, laukimo laiko mechanizmų įgyvendinimą ir rankinio įsikišimo parinkčių teikimą.
• Našumo derinimas: Norint optimizuoti 2PC našumą, reikia kruopščiai suderinti įvairius parametrus, tokius kaip transakcijų laukimo laikas, tinklo nustatymai ir duomenų bazės konfigūracijos.
• Stebėjimas ir žurnalavimas: Išsamaus stebėjimo ir žurnalavimo įgyvendinimas yra būtinas norint sekti paskirstytųjų transakcijų būseną ir identifikuoti galimas problemas.

Globalūs paskirstytųjų transakcijų aspektai

Kuriant ir įgyvendinant paskirstytąsias transakcijas globalioje aplinkoje, reikia atsižvelgti į kelis papildomus veiksnius:

• Tinklo delsa: Tinklo delsa gali žymiai paveikti 2PC našumą, ypač geografiškai paskirstytose sistemose. Tinklo ryšių optimizavimas ir tokių metodų kaip duomenų spartinimas (caching) naudojimas gali padėti sušvelninti delsos poveikį.
• Laiko juostų skirtumai: Laiko juostų skirtumai gali apsunkinti transakcijų apdorojimą, ypač dirbant su laiko žymėmis ir suplanuotais įvykiais. Rekomenduojama naudoti vieningą laiko juostą (pvz., UTC).
• Duomenų lokalizavimas: Duomenų lokalizavimo reikalavimai gali priversti saugoti duomenis skirtinguose regionuose. Tai gali dar labiau apsunkinti paskirstytųjų transakcijų valdymą ir reikalauti kruopštaus planavimo, siekiant užtikrinti atitiktį duomenų privatumo taisyklėms.
• Valiutos konvertavimas: Vykdant finansines transakcijas, kuriose dalyvauja kelios valiutos, valiutos konvertavimas turi būti atliekamas atsargiai, siekiant užtikrinti tikslumą ir atitiktį taisyklėms.
• Teisinis atitikimas: Skirtingos šalys turi skirtingas taisykles, susijusias su duomenų privatumu, saugumu ir finansinėmis transakcijomis. Kuriant ir įgyvendinant paskirstytąsias transakcijas, būtina užtikrinti atitiktį šioms taisyklėms.

Išvada

Paskirstytosios transakcijos ir dviejų fazių patvirtinimo (2PC) protokolas yra esminės sąvokos kuriant tvirtas ir nuoseklias paskirstytąsias sistemas. Nors 2PC suteikia paprastą ir plačiai pritaikytą sprendimą atomiškumui užtikrinti, jo apribojimai, ypač susiję su blokavimu ir vieno gedimo tašku, reikalauja atidaus alternatyvių metodų, tokių kaip „Saga“ ir galutinis nuoseklumas, apsvarstymo. Suprasti kompromisus tarp stipraus nuoseklumo, pasiekiamumo ir našumo yra labai svarbu norint pasirinkti tinkamą metodą konkretiems jūsų programos poreikiams. Be to, veikiant globalioje aplinkoje, reikia atsižvelgti į papildomus aspektus, susijusius su tinklo delsa, laiko juostomis, duomenų lokalizavimu ir teisiniu atitikimu, kad būtų užtikrinta paskirstytųjų transakcijų sėkmė.