Protocol de comitere în două faze - Two-phase commit protocol
În procesarea tranzacțiilor , bazele de date și rețeaua computerizată , protocolul de comitere în două faze ( 2PC ) este un tip de protocol de angajament atomic (ACP). Este un algoritm distribuit care coordonează toate procesele care participă la o tranzacție atomică distribuită cu privire la comiterea sau anularea (retrocedarea) tranzacției (este un tip specializat de protocol consens ). Protocolul își atinge obiectivul chiar și în multe cazuri de eșec temporar al sistemului (implicând fie eșecuri de proces, nod de rețea, comunicații etc.) și este astfel utilizat pe scară largă. Cu toate acestea, nu este rezistent la toate configurațiile posibile de eșec și, în cazuri rare, este necesară intervenția manuală pentru a remedia un rezultat. Pentru a permite recuperarea după eșec (automată în majoritatea cazurilor), participanții la protocol folosesc înregistrarea stărilor protocolului. Înregistrările de jurnal, care sunt de obicei lente de generat, dar supraviețuiesc eșecurilor, sunt utilizate de procedurile de recuperare ale protocolului . Există multe variante de protocol care diferă în primul rând în strategiile de înregistrare și în mecanismele de recuperare. Deși intenționate de obicei să fie utilizate rar, procedurile de recuperare compun o porțiune substanțială a protocolului, din cauza multor scenarii posibile de eșec care trebuie luate în considerare și susținute de protocol.
Într-o „execuție normală” a oricărei tranzacții distribuite (de exemplu, atunci când nu apare nicio eșec, care este de obicei cea mai frecventă situație), protocolul constă din două faze:
- Faza de solicitare a angajamentului (sau faza de vot), în care un proces coordonator încearcă să pregătească toate procesele participante ale tranzacției (participanți numiți, cohorte sau lucrători) pentru a lua măsurile necesare fie pentru comiterea, fie pentru avortarea tranzacției și pentru votare, fie „Da”: comitere (dacă executarea porțiunii locale a participantului la tranzacție s-a încheiat corect) sau „Nu”: întrerupere (dacă a fost detectată o problemă cu porțiunea locală) și
- Faza de comitere, în care, pe baza votului participanților, coordonatorul decide dacă să comită (numai dacă toți au votat „Da”) sau să anuleze tranzacția (în caz contrar) și notifică rezultatul tuturor participanților. Participanții urmează apoi acțiunile necesare (comitere sau anulare) cu resursele lor tranzacționale locale (numite și resurse recuperabile; de exemplu, date din baza de date) și porțiunile respective din celelalte rezultate ale tranzacției (dacă este cazul).
Protocolul de comitere în două faze (2PC) nu trebuie confundat cu protocolul de blocare în două faze (2PL), un protocol de control al concurenței .
Ipoteze
Protocolul funcționează în modul următor: un nod este un coordonator desemnat, care este site-ul principal, iar restul nodurilor din rețea sunt desemnate participanți. Protocolul presupune că există un spațiu de stocare stabil la fiecare nod cu un jurnal de scriere înainte , că niciun nod nu se blochează definitiv, că datele din jurnalul de scriere înainte nu sunt niciodată pierdute sau corupte în caz de blocare și că oricare două noduri pot comunica cu fiecare. Ultima ipoteză nu este prea restrictivă, deoarece comunicația în rețea poate fi redirecționată de obicei. Primele două ipoteze sunt mult mai puternice; dacă un nod este distrus în totalitate, atunci datele pot fi pierdute.
Protocolul este inițiat de coordonator după ce a fost atins ultimul pas al tranzacției. Participanții răspund apoi cu un mesaj de acord sau cu un mesaj de anulare, în funcție de faptul dacă tranzacția a fost procesată cu succes la participant.
Algoritm de bază
Faza de solicitare (sau vot) de angajare
- Coordonatorul trimite o interogare pentru a trimite mesaj către toți participanții și așteaptă până când a primit un răspuns de la toți participanții.
- Participanții execută tranzacția până la punctul în care li se va cere să se angajeze. Fiecare scrie o intrare în jurnalul de anulare și o intrare în jurnalul de refacere .
- Fiecare participant răspunde cu un mesaj de acord (participantul votează Da pentru a comite), dacă acțiunile participantului au reușit, sau un mesaj de avort (participantul votează Nu, să nu comită), dacă participantul se confruntă cu un eșec care va face imposibilă comiterea.
Faza de angajare (sau finalizare)
Succes
Dacă coordonatorul a primit un mesaj de acord de la toți participanții în timpul fazei de solicitare a angajamentului:
- Coordonatorul trimite un mesaj de confirmare tuturor participanților.
- Fiecare participant finalizează operațiunea și eliberează toate blocările și resursele deținute în timpul tranzacției.
- Fiecare participant trimite o confirmare către coordonator.
- Coordonatorul finalizează tranzacția atunci când au fost primite toate confirmările.
Eșec
Dacă vreun participant votează Nu în timpul fazei de solicitare a angajamentului (sau expiră expirarea coordonatorului):
- Coordonatorul trimite un mesaj de revenire tuturor participanților.
- Fiecare participant anulează tranzacția folosind jurnalul de anulare și eliberează resursele și blocările deținute în timpul tranzacției.
- Fiecare participant trimite o confirmare către coordonator.
- Coordonatorul anulează tranzacția atunci când au fost primite toate confirmările.
Fluxul de mesaje
Coordinator Participant
QUERY TO COMMIT
-------------------------------->
VOTE YES/NO prepare*/abort*
<-------------------------------
commit*/abort* COMMIT/ROLLBACK
-------------------------------->
ACKNOWLEDGMENT commit*/abort*
<--------------------------------
end
Un * lângă tipul de înregistrare înseamnă că înregistrarea este forțată la o stocare stabilă.
Dezavantaje
Cel mai mare dezavantaj al protocolului de confirmare în două faze este că este un protocol de blocare. În cazul în care coordonatorul eșuează definitiv, unii participanți nu își vor rezolva niciodată tranzacțiile: după ce un participant a trimis un mesaj de acord către coordonator, acesta se va bloca până când se primește o confirmare sau revenire.
Implementarea protocolului de comitere în două faze
Arhitectură comună
În multe cazuri protocolul 2PC este distribuit într-o rețea de calculatoare. Se distribuie cu ușurință prin implementarea mai multor componente dedicate 2PC similare, denumite în mod tipic manageri de tranzacții (TM; denumiți și agenți 2PC sau monitoare de procesare a tranzacțiilor), care efectuează execuția protocolului pentru fiecare tranzacție (de exemplu, grupul deschis ) s X / Open XA ). Bazele de date implicate într-o tranzacție distribuită, participanții, atât coordonatorul, cât și participanții, se înregistrează pentru a închide TM-urile (care de obicei locuiesc pe aceleași noduri de rețea ca participanții) pentru a termina tranzacția folosind 2PC. Fiecare tranzacție distribuită are un set ad hoc de TM-uri, TM-urile la care se înregistrează participanții la tranzacție. Există un lider, coordonatorul TM, pentru fiecare tranzacție care să coordoneze 2PC pentru acesta, de obicei TM al bazei de date a coordonatorilor. Cu toate acestea, rolul de coordonator poate fi transferat către un alt TM din motive de performanță sau fiabilitate. În loc să schimbe mesaje 2PC între ei, participanții schimbă mesajele cu TM-urile lor respective. TM-urile relevante comunică între ele pentru a executa schema de protocol 2PC de mai sus, „reprezentând” participanții respectivi, pentru încheierea tranzacției. Cu această arhitectură protocolul este complet distribuit (nu are nevoie de nicio componentă centrală de procesare sau structură de date) și se extinde cu numărul de noduri de rețea (dimensiunea rețelei) în mod eficient.
Această arhitectură comună este, de asemenea, eficientă pentru distribuirea altor protocoale de angajament atomice în afară de 2PC, deoarece toate aceste protocoale utilizează același mecanism de vot și propagare a rezultatelor către participanții la protocol.
Optimizări de protocol
Cercetarea bazei de date a fost făcută cu privire la modalitățile de a obține majoritatea beneficiilor protocolului de comitere în două faze, reducând în același timp costurile prin optimizări de protocol și economisirea operațiunilor de protocol sub anumite ipoteze de comportament ale sistemului.
Avort presupus și comisie presupusă
Avortul presupus sau comiterea presupusă sunt obișnuite astfel de optimizări. O presupunere cu privire la rezultatul tranzacțiilor, fie de comitere, fie de anulare, poate salva ambele mesaje și operațiuni de înregistrare de către participanți în timpul execuției protocolului 2PC. De exemplu, când se presupune anularea, dacă în timpul recuperării sistemului de la eșec nu se găsesc dovezi înregistrate pentru comiterea unei tranzacții prin procedura de recuperare, atunci presupune că tranzacția a fost întreruptă și acționează în consecință. Aceasta înseamnă că nu contează dacă avorturile sunt deloc înregistrate, iar o astfel de înregistrare poate fi salvată sub această ipoteză. De obicei, o penalizare pentru operațiuni suplimentare este plătită în timpul recuperării după eșec, în funcție de tipul de optimizare. Astfel, cea mai bună variantă de optimizare, dacă există, este aleasă în funcție de statisticile privind eșecul și rezultatul tranzacției.
Protocol de comitere în două faze Tree
Arborele protocolul 2PC ( de asemenea , numit imbricat 2PC sau recursive 2PC) este o variantă comună de 2PC într - o rețea de calculatoare , care utilizează mai bine infrastructura de comunicații care stau la baza. Participanții la o tranzacție distribuită sunt invocați de obicei într-o ordine care definește o structură de copac, arborele de invocare, unde participanții sunt nodurile și marginile sunt invocațiile (legături de comunicare). Același arbore este utilizat în mod obișnuit pentru a finaliza tranzacția printr-un protocol 2PC, dar și un alt arbore de comunicare poate fi utilizat pentru aceasta, în principiu. Într-un arbore 2PC, coordonatorul este considerat rădăcina („sus”) a unui arbore de comunicare (arborele inversat), în timp ce participanții sunt celelalte noduri. Coordonatorul poate fi nodul care a inițiat tranzacția (invocat recursiv (tranzitiv) ceilalți participanți), dar și un alt nod din același arbore poate lua rolul de coordonator. Mesajele 2PC de la coordonator sunt propagate „în jos” în copac, în timp ce mesajele către coordonator sunt „colectate” de către un participant de la toți participanții de sub acesta, înainte ca acesta să trimită mesajul corespunzător „sus” în copac (cu excepția unui mesaj de avort, care este propagat „sus” imediat după primire sau dacă participantul curent inițiază avortul).
Protocolul Dynamic two-phase commit (Dynamic two-phase engagement, D2PC) este o variantă a Tree 2PC fără coordonator predeterminat. Subsumează mai multe optimizări care au fost propuse mai devreme. Mesajele de acord (Da voturi) încep să se propage din toate frunzele, fiecare frunză când își îndeplinește sarcinile în numele tranzacției (devenind gata). Un nod intermediar (fără frunze) trimite gata atunci când un mesaj de acord către ultimul (singur) nod vecin de la care mesajul de acord nu a fost încă primit. Coordonatorul este determinat dinamic de mesaje de concurs de cursă peste arborele tranzacției, la locul în care se ciocnesc. Acestea se ciocnesc fie la un nod de tranzacție, pentru a fi coordonatorul, fie la o margine de copac. În acest din urmă caz, unul dintre cele două noduri de margine este ales ca coordonator (orice nod). D2PC este timpul optim (printre toate instanțele unui anumit arbore de tranzacție și orice implementare specifică a protocolului Tree 2PC; toate instanțele au același arbore; fiecare instanță are un nod diferit ca coordonator): Prin alegerea unui coordonator optim D2PC angajează atât coordonatorul și fiecare participant în timp minim posibil, permițând eliberarea cât mai curând posibilă a resurselor blocate în fiecare participant la tranzacție (nod arbore).
