Spécification XA
XA est la spécification d’interface (c’est-à-dire la fonction d’interface) entre le middleware transactionnel et la base de données définie par X/Open DTP, utilisée par le middleware transactionnel pour notifier la base de données du début, de la fin, du commit, du rollback, etc. des transactions. Les fonctions d’interface XA sont fournies par les fournisseurs de bases de données.
L’accord de soumission du second ordre et l’accord de soumission du troisième ordre sont dérivés de cette idée. On peut dire que les commits en deux étapes sont en réalité la clé pour implémenter les transactions distribuées XA (pour être précis : les commits en deux étapes assurent principalement l’atomicité des transactions distribuées : c’est-à-dire que tous les nœuds font soit tout, soit rien)
2PC
Le Commet en deux phases désigne un algorithme conçu pour maintenir la cohérence des commits de transaction pour tous les nœuds, basé sur l’architecture système distribuée dans le domaine des réseaux informatiques et des bases de données. Souvent, un commit en deux étapes est également appelé protocole. Dans un système distribué, chaque nœud peut connaître le succès ou l’échec de sa propre opération, mais il ne peut pas connaître le succès ou l’échec des opérations des autres nœuds. Lorsqu’une transaction s’étend sur plusieurs nœuds, afin de maintenir les caractéristiques ACID de la transaction, un composant agissant en tant que coordinateur doit être introduit pour contrôler les résultats de tous les nœuds (appelés participants) et finalement leur demander de soumettre effectivement les résultats (par exemple écrire des données mises à jour sur le disque, etc.). Ainsi, l’idée algorithmique de la soumission en deux étapes peut se résumer ainsi : les participants informeront le coordinateur du succès ou de l’échec de l’opération, puis le coordinateur décidera s’il soumet ou abandonne l’opération en fonction des informations de rétroaction de tous les participants.
Les deux étapes dites sont : la première étape : la phase de préparation (étape de vote) et la seconde étape : l’étape de soumission (étape d’exécution).
Étape de préparation
Le coordinateur de transaction (gestionnaire de transactions) envoie un message Prepare à chaque participant (gestionnaire de ressources), et chaque participant retourne soit directement une défaillance (comme une vérification d’autorisation échouée), soit exécute la transaction localement, écrit des journaux de refaire et d’annuler localement, mais ne fait pas de commit, et atteint un état de « tout est prêt, seul le vent d’est est dû ».
L’étape de préparation peut être subdivisée en trois étapes suivantes :
1) Le nœud coordinateur demande à tous les nœuds participants s’ils peuvent effectuer un vote et commence à attendre une réponse de chaque nœud participant.
2) Le nœud participant effectue toutes les opérations transactionnelles jusqu’au lancement de la requête, puis écrit les informations d’annulation et de refaire dans le journal. (Note : En cas de succès, chaque participant a déjà effectué l’opération de transaction)
3) Chaque nœud participant répond à la requête initiée par le nœud coordinateur. Si l’opération transactionnelle du nœud participant est effectivement exécutée avec succès, il renvoie un message « Accepter » ; Si l’opération de transaction du nœud participant échoue effectivement, elle renvoie un message « aborté ».
Étape de soumission
Si le coordinateur reçoit un message d’échec ou un délai d’attente d’un participant, il enverra un message de retour en arrière directement à chaque participant. Sinon, envoyez un message Commit ; Les participants effectuent des opérations de commit ou de retour en arrière selon les instructions du coordinateur pour libérer toutes les ressources de verrouillage utilisées dans le processus de transaction. (Note : Les ressources verrouillées doivent être libérées dans la dernière étape)
Ensuite, le processus de la phase de soumission est discuté séparément dans deux cas.
Lorsque le message correspondant reçu par le nœud coordinateur de tous les nœuds participants est Accord :
Étape de soumission
Si le coordinateur reçoit un message d’échec ou un délai d’attente d’un participant, il enverra un message de retour en arrière directement à chaque participant. Sinon, envoyez un message Commit ; Les participants effectuent des opérations de commit ou de retour en arrière selon les instructions du coordinateur pour libérer toutes les ressources de verrouillage utilisées dans le processus de transaction. (Note : Les ressources verrouillées doivent être libérées dans la dernière étape)
Ensuite, le processus de la phase de soumission est discuté séparément dans deux cas.
Lorsque le message correspondant reçu par le nœud coordinateur de tous les nœuds participants est Accord :
1) Le nœud coordinateur envoie une requête « commit » à tous les nœuds participants.
2) Le nœud participant termine officiellement l’opération et libère les ressources occupées tout au long de la période de transaction.
3) Le nœud participant envoie un message « Terminé » au nœud coordinateur.
4) Le nœud coordinateur termine la transaction après avoir reçu le retour du message « Terminé » de tous les nœuds participants.
1) Le nœud coordinateur envoie une demande de « retour en arrière » à tous les nœuds participants.
2) Le nœud participant utilise les informations d’annulation précédemment écrites pour effectuer un retour en arrière et libérer les ressources occupées pendant toute la période de transaction.
3) Le nœud participant envoie un message « retour en arrière terminé » au nœud coordinateur.
4) Le nœud coordinateur annule la transaction après avoir reçu le message « Rollback Complete » de tous les nœuds participants.
Les commits de phase 2 semblent fournir des opérations atomiques, mais malheureusement, les commits de phase 2 présentent encore quelques inconvénients :
1. Problème de blocage synchrone. Lors de l’exécution, tous les nœuds participants bloquent les transactions. Lorsqu’un participant occupe une ressource publique, d’autres nœuds tiers doivent être bloqués pour accéder à la ressource publique.
2. Point unique de défaillance. En raison de l’importance du coordinateur, une fois que le coordinateur échoue. Les participants continueront à bloquer l’obstruction. Surtout à la deuxième étape, si le coordinateur échoue, tous les participants restent dans un état de blocage des ressources transactionnelles et ne peuvent pas continuer à terminer les opérations transactionnelles. (Si le coordinateur raccroche, vous pouvez réélire un coordinateur, mais cela ne peut pas résoudre le problème que le participant est bloqué à cause du manque du coordinateur)
3. Incohérence des données. Lors de la deuxième étape de la deuxième étape du commit, lorsque le coordinateur envoie une requête de commit au participant, une exception réseau locale se produit ou le coordinateur échoue lors du processus de demande de commit, ce qui fait que seuls certains participants acceptent la requête de commit. Après avoir reçu la demande de validation, ces participants effectueront l’opération de validation. Cependant, les autres machines qui ne reçoivent pas de requête de commit ne peuvent pas exécuter le commit de la transaction. En conséquence, la cohérence du département des données se produit dans l’ensemble du système distribué.
4. Problèmes qui ne peuvent pas être résolus lors de la deuxième étape : Le coordinateur est désactivé après avoir envoyé un message de validation, et le seul participant qui reçoit ce message est également hors combat. Ainsi, même si le facilitateur élise un nouveau facilitateur via l’accord électoral, le statut de la transaction est incertain, et personne ne sait si la transaction a été soumise.
3PC
Le commit en trois phases, également appelé protocole de validation en trois phases, est une version améliorée du commit en deux phases (2PC).
Contrairement aux commits en deux étapes, il y a deux changements pour les commits en trois étapes.
1. Introduire un mécanisme de temps mort. En même temps, un mécanisme de délai est introduit à la fois chez le facilitateur et chez les participants.
2. Insérer une étape préparatoire lors des première et deuxième étapes. Cela garantit que l’état de tous les nœuds participants reste cohérent jusqu’à la dernière étape de validation.
En d’autres termes, en plus d’introduire un mécanisme de timeout, 3PC divise à nouveau l’étape de préparation de 2PC en deux, de sorte qu’il y a trois étapes de CanCommit, Precommit et DoCommit dans les trois étapes du commit.
Phase CanCommit
L’étape CanCommit de 3PC est en réalité très similaire à la phase de préparation de 2PC. Le coordinateur envoie une demande de commit au participant, qui répond Oui s’il peut s’engager, ou un Non-réponse.
1. Demande de transaction Le facilitateur envoie une requête CanCommit au participant. Demandez si vous pouvez effectuer une opération de commit de transaction. Ensuite, commencez à attendre une réponse des participants.
2. Retour d’information de réponse Après avoir reçu la requête CanCommitte, le participant répondra par Oui et entrera en état de prêt s’il pense que la transaction peut être exécutée sans encombre. Sinon, retour non
Phase de pré-engagement
Le facilitateur décide s’il doit ou non mémoriser l’opération de pré-commit de la transaction en fonction de la réponse du participant. Selon la réponse, il y a deux possibilités.
Si le retour que le facilitateur reçoit de tous les participants est une réponse Oui, alors la pré-exécution de la transaction est effectuée.
1. Envoyer une demande de pré-engagement Le facilitateur envoie une requête de pré-engagement au participant et passe à l’étape de préparation.
2. Pré-commit de transaction Après que le participant ait reçu la requête de pré-engagement, il effectue l’opération de transaction et enregistre les informations d’annulation et de remise dans le journal de transaction.
3. Retour de réponse Si le participant exécute avec succès l’opération de transaction, une réponse ACK est renvoyée alors qu’on commence à attendre l’instruction finale.
1. Envoyer une demande d’interruption Le facilitateur envoie une demande d’abandon à tous les participants.
2. Interrompre la transaction Après que le participant a reçu la demande d’ABORT du coordinateur (ou après le délai d’attente, la demande du coordinateur n’a pas été reçue), l’interruption de la transaction est exécutée.
Cette étape de l’engagement de transaction réelle peut également être divisée en deux situations suivantes.
Effectuer un commit
1. Envoyer une demande de commit Coordinating reçoit la réponse ACK envoyée par le participant, puis il passera de l’état de pré-commit à l’état de commit. et envoyer une demande de doCommit à tous les participants.
2. Soumission de la transaction Après avoir reçu la requête doCommitte, le participant exécute le commit formel de la transaction. et libérer toutes les ressources de transaction après avoir complété le commit de la transaction.
3. Répondre aux retours Après la soumission de la transaction, envoyer une réponse Ack au coordinateur.
4. Compléter la transaction Après que le coordinateur ait reçu la réponse ACK de tous les participants, la transaction est terminée.
Si le coordinateur ne reçoit pas de réponse ACK du participant (il se peut que ce ne soit pas une réponse ACK du récepteur, ou la réponse a pu expirer), alors la transaction d’interruption est exécutée.
1. Envoyer une demande d’interruption Le facilitateur envoie une requête d’abandon à tous les participants
2. Annulation de transaction Après avoir reçu la demande d’ABORT, le participant utilise les informations d’annulation enregistrées dans la Phase 2 pour effectuer l’opération de retour en arrière de transaction, et libère toutes les ressources de transaction après avoir terminé le retour.
3. Résultats de retour d’information Après que le participant a terminé le retour en arrière de la transaction, envoyez un message ACK au coordinateur
4. Interrompre la transaction Après que le coordinateur ait reçu le message ACK du participant, la transaction est interrompue.
La différence entre 2PC et 3PC
Par rapport à 2PC, 3PC résout principalement le problème du point unique de défaillance et réduit le blocage, car une fois que le participant ne reçoit pas un message du coordinateur à temps, il exécute le commit par défaut. Au lieu de retenir constamment les ressources transactionnelles et d’être en état de blocage. Mais ce mécanisme cause aussi des problèmes de cohérence des données, car la réponse d’abandon envoyée par le coordinateur n’est pas reçue à temps par le participant pour des raisons réseau, puis le participant exécute l’opération de validation après avoir attendu le timeout. Cela crée des incohérences de données avec les autres participants qui reçoivent la commande d’abandon et effectuent un retour en arrière.
|
Publié sur 17/03/2021 10:15:10
|
|
|
