Specifica XA
XA è la specifica di interfaccia (cioè funzione di interfaccia) tra il middleware delle transazioni e il database definito da X/Open DTP, utilizzata dal middleware delle transazioni per notificare al database l'inizio, la fine, il commit, il rollback, ecc. delle transazioni. Le funzioni dell'interfaccia XA sono fornite dai fornitori di database.
L'accordo di sottomissione di secondo ordine e quello di sottomissione di terzo ordine derivarono da questa idea. Si può dire che i commit a due stadi siano in realtà la chiave per implementare transazioni distribuite XA (per essere precisi: i commit a due stadi garantiscono principalmente l'atomicità delle transazioni distribuite: cioè, tutti i nodi fanno tutto o niente)
2PC
Il Commit a due fasi si riferisce a un algoritmo progettato per mantenere la coerenza nei commit di transazione per tutti i nodi, basato sull'architettura di sistema distribuita nel campo delle reti informatiche e dei database. Spesso, un commit a due stadi è anche chiamato protocollo. In un sistema distribuito, ogni nodo può conoscere il successo o il fallimento della propria operazione, ma non può conoscere il successo o il fallimento delle operazioni degli altri nodi. Quando una transazione si estende su più nodi, per mantenere le caratteristiche ACID della transazione, deve essere introdotto un componente che agisce come coordinatore per controllare i risultati di tutti i nodi (chiamati partecipanti) e infine istruire questi nodi a inviare effettivamente i risultati (ad esempio scrivendo dati aggiornati su disco, ecc.). Pertanto, l'idea algoritmica della sottomissione in due fasi può essere riassunta come segue: i partecipanti notificheranno al coordinatore il successo o il fallimento dell'operazione, e poi il coordinatore deciderà se inviare o abortire l'operazione basandosi sulle informazioni di feedback di tutti i partecipanti.
Le cosiddette due fasi sono: la prima fase: la fase di preparazione (fase di votazione) e la seconda fase: la fase di presentazione (fase di esecuzione).
Fase di preparazione
Il coordinatore delle transazioni (transaction manager) invia un messaggio Prepare a ciascun partecipante (resource manager), e ogni partecipante restituisce direttamente un fallimento (come una verifica dei permessi fallita), oppure esegue la transazione localmente, scrive i log locali di rifacimento e annullamento, ma non effettua il commit, raggiungendo lo stato "tutto è pronto, solo il vento est è dovuto".
La fase di preparazione può essere ulteriormente suddivisa nei seguenti tre passaggi:
1) Il nodo coordinatore chiede a tutti i nodi partecipanti se possono effettuare un voto e inizia ad attendere una risposta da ciascun nodo partecipante.
2) Il nodo partecipante esegue tutte le operazioni di transazione fino all'avvio della query e scrive le informazioni di Annulla e di Rifare nel log. (Nota: Se ha successo, ogni partecipante ha già eseguito l'operazione di transazione)
3) Ogni nodo partecipante risponde all'indagine avviata dal nodo coordinatore. Se l'operazione di transazione del nodo partecipante viene effettivamente eseguita con successo, restituisce un messaggio "Accetta"; Se l'operazione di transazione del nodo partecipante fallisce effettivamente, restituisce un messaggio "abortito".
Fase di presentazione
Se il coordinatore riceve un messaggio di fallimento o un timeout da un partecipante, invierà un messaggio di rollback direttamente a ciascun partecipante. Altrimenti, invia un messaggio di Commit; I partecipanti eseguono operazioni di commit o rollback secondo le istruzioni del coordinatore per rilasciare tutte le risorse di lock utilizzate nel processo di transazione. (Nota: le risorse di blocco devono essere rilasciate nella fase finale)
Successivamente, il processo della fase di presentazione viene discusso separatamente in due casi.
Quando il messaggio corrispondente ricevuto dal nodo coordinatore da tutti i nodi partecipanti è Concorda:
Fase di presentazione
Se il coordinatore riceve un messaggio di fallimento o un timeout da un partecipante, invierà un messaggio di rollback direttamente a ciascun partecipante. Altrimenti, invia un messaggio di Commit; I partecipanti eseguono operazioni di commit o rollback secondo le istruzioni del coordinatore per rilasciare tutte le risorse di lock utilizzate nel processo di transazione. (Nota: le risorse di blocco devono essere rilasciate nella fase finale)
Successivamente, il processo della fase di presentazione viene discusso separatamente in due casi.
Quando il messaggio corrispondente ricevuto dal nodo coordinatore da tutti i nodi partecipanti è Concorda:
1) Il nodo coordinatore invia una richiesta di "commit" a tutti i nodi partecipanti.
2) Il nodo partecipante completa ufficialmente l'operazione e rilascia le risorse occupate durante tutto il periodo della transazione.
3) Il nodo partecipante invia un messaggio "Fatto" al nodo coordinatore.
4) Il nodo coordinatore completa la transazione dopo aver ricevuto il feedback del messaggio "Fatto" da tutti i nodi partecipanti.
1) Il nodo coordinatore invia una richiesta di "rollback" a tutti i nodi partecipanti.
2) Il nodo partecipante utilizza le informazioni di annullamento precedentemente scritte per effettuare un rollback e rilasciare le risorse occupate durante tutto il periodo della transazione.
3) Il nodo partecipante invia un messaggio "rollback complete" al nodo coordinatore.
4) Il nodo coordinatore annulla la transazione dopo aver ricevuto il feedback del messaggio "Rollback Complete" da tutti i nodi partecipanti.
I commit di fase 2 sembrano effettivamente fornire operazioni atomiche, ma purtroppo i commit di fase 2 presentano ancora alcuni svantaggi:
1. Problema di blocco sincrono. Durante l'esecuzione, tutti i nodi partecipanti bloccano le transazioni. Quando un partecipante occupa una risorsa pubblica, altri nodi di terze parti devono essere bloccati dall'accedere alla risorsa pubblica.
2. Punto unico di rottura. A causa dell'importanza del coordinatore, una volta che il coordinatore fallisce. I partecipanti continueranno a bloccare l'ostruzione. Soprattutto nella seconda fase, se il coordinatore fallisce, tutti i partecipanti sono ancora in uno stato di blocco delle risorse transazionali e non possono continuare a completare le operazioni di transazione. (Se il coordinatore riattacca, puoi rieleggere un coordinatore, ma non può risolvere il problema che il partecipante è bloccato a causa della perdita del coordinatore)
3. Incoerenza dei dati. Nella seconda fase della seconda fase del commit, quando il coordinatore invia una richiesta di commit al partecipante, si verifica un'eccezione di rete locale o il coordinatore fallisce durante il processo di richiesta di commit, il che fa sì che solo alcuni partecipanti accettino la richiesta di commit. Dopo aver ricevuto la richiesta di commit, questi partecipanti eseguiranno l'operazione di commit. Tuttavia, altre macchine che non ricevono una richiesta di commit non possono eseguire il commit della transazione. Di conseguenza, la coerenza del dipartimento dati si verifica in tutto il sistema distribuito.
4. Problemi che non possono essere risolti nella seconda fase: Il coordinatore cade dopo aver inviato un messaggio di commit, e anche l'unico partecipante che riceve questo messaggio è fuori uso. Quindi, anche se il facilitatore elegge un nuovo facilitatore tramite l'accordo elettorale, lo stato della transazione è incerto e nessuno sa se la transazione sia stata presentata.
3PC
Il commit trifase, noto anche come protocollo di commit trifase, è una versione migliorata del commit a due fasi (2PC).
A differenza dei commit a due fasi, ci sono due cambiamenti nei commit a tre stadi.
1. Introdurre un meccanismo di timeout. Allo stesso tempo, viene introdotto un meccanismo di timeout sia nel facilitatore che nei partecipanti.
2. Inserire una fase preparatoria nella prima e nella seconda fase. Questo garantisce che lo stato di tutti i nodi partecipanti sia coerente fino alla fase finale di commit.
In altre parole, oltre a introdurre un meccanismo di timeout, 3PC divide nuovamente la fase di preparazione di 2PC in due, così che ci siano tre fasi: CanCommit, Precommit e DoCommit nelle tre fasi di commit.
Fase CanCommit
La fase CanCommit di 3PC è in realtà molto simile a quella di preparazione di 2PC. Il coordinatore invia una richiesta di commit al partecipante, che risponde con un Sì se può commetterlo, oppure con un No Response.
1. Richiesta di transazione Il facilitatore invia una richiesta CanCommit al partecipante. Chiedi se puoi eseguire un'operazione di commit di transazione. Poi inizia ad aspettare una risposta dai partecipanti.
2. Feedback di risposta Dopo aver ricevuto la richiesta CanCommitte, il partecipante restituirà una risposta Sì ed entrerà in stato di prontezza se ritiene che la transazione possa essere eseguita senza intoppi. Altrimenti feedback No
Fase di PreCommit
Il facilitatore decide se memorizzare o meno l'operazione PreCommit della transazione in base alla risposta del partecipante. A seconda della risposta, ci sono due possibilità.
Se il feedback che il facilitatore riceve da tutti i partecipanti è una risposta Sì, allora viene eseguita la pre-esecuzione della transazione.
1. Invia una richiesta PreCommit Il facilitatore invia una richiesta PreCommit al partecipante e passa alla fase Preparazione.
2. Pre-Commit della Transazione Dopo che il partecipante riceve la richiesta PreCommit, esegue l'operazione di transazione e registra le informazioni di annullamento e rifaccio nel registro delle transazioni.
3. Feedback di risposta Se il partecipante esegue con successo l'operazione di transazione, viene restituita una risposta ACK mentre si inizia ad attendere l'istruzione finale.
1. Inviare una richiesta di interruzione Il facilitatore invia una richiesta di aborto a tutti i partecipanti.
2. Interrompere la transazione Dopo che il partecipante riceve la richiesta ABORT dal coordinatore (o dopo il timeout, la richiesta dal coordinatore non è stata ricevuta), l'interruzione della transazione viene eseguita.
Questa fase del commit della transazione reale può anche essere suddivisa nelle seguenti due situazioni.
Esegui un commit
1. Invia una richiesta di commit: Coordinating riceve la risposta ACK inviata dal partecipante, quindi passerà dallo stato di pre-commit a quello di commit. e inviare una richiesta doCommit a tutti i partecipanti.
2. Sottomissione della transazione Dopo aver ricevuto la richiesta doCommit, il partecipante esegue il commit formale della transazione. e rilascia tutte le risorse della transazione dopo aver completato il commit della transazione.
3. Rispondi ai feedback Dopo che la transazione è stata inviata, invia una risposta Ack al coordinatore.
4. Completare la transazione Dopo che il coordinatore riceve la risposta ACK da tutti i partecipanti, la transazione viene completata.
Se il coordinatore non riceve una risposta ACK dal partecipante (potrebbe non essere una risposta ACK dal ricevitore, oppure la risposta potrebbe essere stata scaduta), allora la transazione di interruzione viene eseguita.
1. Inviare una richiesta di interruzione Il facilitatore invia una richiesta di aborto a tutti i partecipanti
2. Rollback della transazione Dopo aver ricevuto la richiesta ABORT, il partecipante utilizza le informazioni di annullamento registrate nella Fase 2 per eseguire l'operazione di rollback della transazione e rilascia tutte le risorse della transazione dopo aver completato il rollback.
3. Risultati del feedback Dopo che il partecipante ha completato il rollback della transazione, invia un messaggio ACK al coordinatore
4. Interrompere la transazione Dopo che il coordinatore riceve il messaggio ACK dal partecipante, la transazione viene interrotta.
La differenza tra 2PC e 3PC
Rispetto a 2PC, 3PC risolve principalmente il problema del singolo punto di guasto e riduce il blocco, perché una volta che il partecipante non riceve un messaggio dal coordinatore in tempo, esegue il commit di default. Invece di tenere sempre le risorse delle transazioni e restare in uno stato di blocco. Ma questo meccanismo causa anche problemi di coerenza dei dati, perché la risposta di aborto inviata dal coordinatore non viene ricevuta in tempo dal partecipante per motivi di rete, quindi il partecipante esegue l'operazione di commit dopo aver atteso il timeout. Questo crea incongruenze nei dati con altri partecipanti che ricevono il comando di aborto ed eseguono un rollback.
|
Pubblicato su 17/03/2021 10:15:10
|
|
|
