Specificația XA
XA este specificația interfeței (adică funcția de interfață) dintre middleware-ul tranzacțiilor și baza de date definită de X/Open DTP, care este folosită de middleware-ul tranzacțiilor pentru a notifica baza de date despre început, sfârșit, commit, rollback etc. ale tranzacțiilor. Funcțiile interfeței XA sunt furnizate de furnizorii de baze de date.
Acordul de depunere de ordinul doi și acordul de supunere de ordinul trei au derivat din această idee. Se poate spune că commit-urile în două etape sunt de fapt cheia implementării tranzacțiilor distribuite XA (mai exact: commit-urile în două etape asigură în principal atomicitatea tranzacțiilor distribuite: adică toate nodurile fie fac totul, fie nimic)
2PC
Angajamentul în două faze se referă la un algoritm conceput pentru a menține consistența commit-urilor de tranzacții pentru toate nodurile, bazat pe arhitectura sistemului distribuit în domeniul rețelelor de calculatoare și bazelor de date. Adesea, un commit în două etape este denumit și protocol. Într-un sistem distribuit, fiecare nod poate cunoaște succesul sau eșecul propriei sale operațiuni, dar nu poate cunoaște succesul sau eșecul operațiunilor altor noduri. Când o tranzacție acoperă mai multe noduri, pentru a menține caracteristicile ACID ale tranzacției, trebuie introdusă o componentă care acționează ca un coordonator care să controleze rezultatele tuturor nodurilor (numite participanți) și, în cele din urmă, să instruiască aceste noduri să trimită efectiv rezultatele (cum ar fi scrierea datelor actualizate pe disc etc.). Prin urmare, ideea algoritmică a trimiterii în două etape poate fi rezumată astfel: participanții vor notifica coordonatorul despre succesul sau eșecul operațiunii, iar apoi coordonatorul va decide dacă să trimită operația sau să o anuleze pe baza informațiilor de feedback ale tuturor participanților.
Așa-numitele două etape sunt: prima etapă: etapa de pregătire (etapa de vot) și a doua etapă: etapa de depunere (etapa de execuție).
Etapa de pregătire
Coordonatorul tranzacțiilor (managerul de tranzacții) trimite un mesaj Prepare fiecărui participant (manager de resurse), iar fiecare participant fie returnează direct o defecțiune (cum ar fi o verificare eșuată a permisiunii), fie execută tranzacția local, scrie jurnalele locale de refacere și desfacere, dar nu face commit și ajunge la starea "totul este pregătit, doar vântul de est este datorat".
Etapa de pregătire poate fi împărțită în următoarele trei etape:
1) Nodul coordonator întreabă toate nodurile participante dacă pot efectua un vot și începe să aștepte un răspuns de la fiecare nod participant.
2) Nodul participant efectuează toate operațiunile tranzacțiilor până la inițierea interogării și scrie informațiile Undo și Redo în jurnal. (Notă: Dacă are succes, fiecare participant a efectuat deja operația tranzacției)
3) Fiecare nod participant răspunde interogării inițiate de nodul coordonator. Dacă operația tranzacției nodului participant este efectiv executată cu succes, returnează un mesaj "Agree"; Dacă operația de tranzacție a nodului participant eșuează efectiv, returnează un mesaj "abortat".
Etapa de trimitere
Dacă coordonatorul primește un mesaj de eșec sau un timeout de la un participant, va trimite un mesaj de rollback direct fiecărui participant. În caz contrar, trimite un mesaj Commit; Participanții efectuează operațiuni de commit sau rollback conform instrucțiunilor coordonatorului pentru a elibera toate resursele de blocare folosite în procesul tranzacției. (Notă: Resursele de blocare trebuie eliberate în etapa finală)
Apoi, procesul fazei de depunere este discutat separat în două cazuri.
Când mesajul corespunzător primit de nodul coordonator de la toate nodurile participante este Agree:
Etapa de trimitere
Dacă coordonatorul primește un mesaj de eșec sau un timeout de la un participant, va trimite un mesaj de rollback direct fiecărui participant. În caz contrar, trimite un mesaj Commit; Participanții efectuează operațiuni de commit sau rollback conform instrucțiunilor coordonatorului pentru a elibera toate resursele de blocare folosite în procesul tranzacției. (Notă: Resursele de blocare trebuie eliberate în etapa finală)
Apoi, procesul fazei de depunere este discutat separat în două cazuri.
Când mesajul corespunzător primit de nodul coordonator de la toate nodurile participante este Agree:
1) Nodul coordonator emite o cerere de "commit" către toate nodurile participante.
2) Nodul participant finalizează oficial operațiunea și eliberează resursele ocupate pe tot parcursul perioadei tranzacției.
3) Nodul participant trimite un mesaj "Finalizat" către nodul coordonator.
4) Nodul coordonator finalizează tranzacția după ce primește feedback-ul mesajului "Finalizat" de la toate nodurile participante.
1) Nodul coordonator emite o cerere de "rollback" către toate nodurile participante.
2) Nodul participant folosește informațiile Undo scrise anterior pentru a efectua o rollback și a elibera resursele ocupate pe tot parcursul perioadei tranzacției.
3) Nodul participant trimite un mesaj "rollback complet" către nodul coordonator.
4) Nodul coordonator anulează tranzacția după ce primește feedback-ul "Rollback Complete" de la toate nodurile participante.
Commit-urile din faza 2 par să ofere operațiuni atomice, dar, din păcate, comm-urile din faza 2 au totuși câteva dezavantaje:
1. Problemă de blocare sincronă. În timpul execuției, toate nodurile participante blochează tranzacțiile. Când un participant ocupă o resursă publică, celelalte noduri terțe trebuie blocate să acceseze acea resursă publică.
2. Punct unic de cedare. Din cauza importanței coordonatorului, odată ce acesta eșuează. Participanții vor continua să blocheze blocajul. Mai ales în a doua etapă, dacă coordonatorul eșuează, toți participanții sunt încă într-o stare de blocare a resurselor tranzacțiilor și nu pot continua să finalizeze operațiunile tranzacției. (Dacă coordonatorul închide, poți realege un coordonator, dar nu se poate rezolva problema că participantul este blocat din cauza căderii)
3. Inconsistența datelor. În a doua etapă a celei de-a doua etape a commit-ului, când coordonatorul trimite o cerere de commit către participant, apare o excepție locală de rețea sau coordonatorul eșuează în timpul procesului de commit request, ceea ce face ca doar unii participanți să accepte cererea de commit. După primirea cererii de commit, acești participanți vor efectua operația de commit. Totuși, alte mașini care nu primesc o cerere de commit nu pot executa commit-ul tranzacției. Ca urmare, consistența departamentului de date are loc în întregul sistem distribuit.
4. Probleme care nu pot fi rezolvate în a doua etapă: Coordonatorul cade după ce trimite un mesaj de commit, iar singurul participant care primește acest mesaj este și el jos. Așadar, chiar dacă facilitatorul alege un nou facilitator prin acordul electoral, stadiul tranzacției este incert și nimeni nu știe dacă tranzacția a fost depusă.
3PC
Commit-ul în trei faze, cunoscut și sub denumirea de protocolul de commit în trei faze, este o versiune îmbunătățită a commit-ului în două faze (2PC).
Spre deosebire de commit-urile în două etape, există două schimbări față de commit-urile în trei etape.
1. Introducerea unui mecanism de timeout. În același timp, este introdus un mecanism de timeout atât la facilitator, cât și la participanți.
2. Introduceți o etapă pregătitoare în prima și a doua etapă. Acest lucru asigură că starea tuturor nodurilor participante este consistentă până la etapa finală de commit.
Cu alte cuvinte, pe lângă introducerea unui mecanism de timeout, 3PC împarte din nou etapa de pregătire a lui 2PC în două, astfel încât să existe trei etape: CanCommit, PreCommitit și DoCommit în cele trei etape ale commit-ului.
Etapa CanCommit
Etapa CanCommit din 3PC este de fapt foarte asemănătoare cu etapa de pregătire din 2PC. Coordonatorul trimite o cerere de commit participantului, care răspunde cu Da dacă poate face commit sau cu un răspuns No.
1. Interogare de tranzacție Facilitatorul trimite o cerere CanCommit către participant. Întreabă dacă poți efectua o operație de commit a tranzacției. Apoi începe să aștepți un răspuns de la participanți.
2. Feedback de răspuns După primirea cererii CanCommit, participantul va returna un răspuns Da și va intra în starea de pregătire dacă consideră că tranzacția poate fi executată fără probleme. În rest, feedback Nu
Faza PreCommit
Facilitatorul decide dacă să memoreze sau nu operațiunea PreCommit a tranzacției pe baza răspunsului participantului. În funcție de răspuns, există două posibilități.
Dacă feedback-ul pe care facilitatorul îl primește de la toți participanții este un răspuns Da, atunci pre-executarea tranzacției este efectuată.
1. Trimite o Cerere PreCommit Facilitatorul trimite o cerere PreCommit participantului și trece la etapa Pregătire.
2. Pre-Commiterea tranzacției După ce participantul primește cererea PreCommit, efectuează operația tranzacției și înregistrează informațiile de anulare și refacere în jurnalul tranzacțiilor.
3. Feedback de răspuns Dacă participantul execută cu succes operația tranzacției, un răspuns ACK este returnat în timp ce începe să aștepte instrucțiunea finală.
1. Trimite o cerere de întrerupere Facilitatorul trimite o cerere de abort tuturor participanților.
2. Întreruperea tranzacției După ce participantul primește cererea ABORT de la coordonator (sau după timeout, cererea coordonatorului nu a fost recepționată), întreruperea tranzacției este executată.
Această etapă a angajamentului real al tranzacțiilor poate fi împărțită și în următoarele două situații.
Efectuează un commit
1. Trimite o cerere de commit Coordinating primește răspunsul ACK trimis de participant, apoi acesta va trece din starea de pre-commit în starea de commit. și să trimită o cerere doCommit tuturor participanților.
2. Trimiterea tranzacției După primirea cererii doCommit, participantul execută commit-ul formal al tranzacției. și eliberează toate resursele tranzacțiilor după finalizarea commit-ului tranzacției.
3. Răspunde la feedback După ce tranzacția este trimisă, trimite un răspuns Ack coordonatorului.
4. Finalizarea tranzacției După ce coordonatorul primește răspunsul ACK de la toți participanții, tranzacția este finalizată.
Dacă coordonatorul nu primește un răspuns ACK de la participant (poate să nu fie un răspuns ACK de la receptor sau răspunsul să fi expirat), atunci tranzacția de întrerupere este executată.
1. Trimite o cerere de întrerupere Facilitatorul trimite o cerere de abort tuturor participanților
2. Rollback al tranzacțiilor După primirea cererii ABORT, participantul folosește informațiile de anulare înregistrate în Faza 2 pentru a efectua operația de rollback și eliberează toate resursele tranzacțiilor după finalizarea rollback-ului.
3. Rezultatele feedback-ului După ce participantul finalizează anularea tranzacției, trimite un mesaj ACK coordonatorului
4. Întreruperea tranzacției După ce coordonatorul primește mesajul ACK de la participant, tranzacția este întreruptă.
Diferența dintre 2PC și 3PC
Comparativ cu 2PC, 3PC rezolvă în principal problema punctului unic de eșec și reduce blocarea, deoarece odată ce participantul nu primește un mesaj de la coordonator la timp, execută commit-ul implicit. În loc să țină resursele tranzacțiilor tot timpul și să fiu blocat. Dar acest mecanism cauzează și probleme de consistență a datelor, deoarece răspunsul de abort trimis de coordonator nu este primit la timp de participant din motive de rețea, apoi acesta execută operația de commit după ce a așteptat timeout-ul. Aceasta creează inconsistențe de date cu alți participanți care primesc comanda de abort și efectuează o rollback.
|
Postat pe 17.03.2021 10:15:10
|
|
|
