Le contenu de cet article est une explication détaillée des transactions distribuées avec des images et des textes. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.
Cette fois, j'ai acquis quelques connaissances sur les transactions distribuées en utilisant le cadre de transactions distribuées, donc dans cet article, nous parlerons des transactions distribuées. Voyons d’abord ce qu’est une transaction.
Transactions
Qu'est-ce qu'une transaction ? Il s'agit d'un développement back-end. Tant qu'il y aura une interaction avec la base de données dans le développement quotidien, les transactions seront certainement utilisées. Extrayez maintenant une explication du wiki pour expliquer ce qu'est une transaction.
est une unité logique dans le processus d'exécution du système de gestion de base de données, constituée d'une séquence limitée d'opérations de base de données
Le système de base de données a des caractéristiques de transaction, ce qui est une caractéristique importante qui le distingue de le système de fichiers. Dans un système de fichiers traditionnel, si un fichier est en cours d'écriture et que le système d'exploitation plante soudainement, le fichier peut être endommagé. Le système de base de données introduit des fonctionnalités de transaction pour garantir que la base de données passe d'un état à un autre. Lorsque vous soumettez votre travail, vous pouvez être sûr que toutes les modifications sont enregistrées ou qu'aucune n'est enregistrée.
Habituellement, une transaction consiste en plusieurs opérations de lecture et d'écriture.
Les transactions ont quatre caractéristiques de base, communément appelées ACID.
A (Atomicité) : Atomicité. La transaction sera traitée dans son ensemble. Soit toutes les instructions réussissent, soit toutes échouent. Il ne peut pas y avoir de situation dans laquelle certaines instructions réussissent et d'autres échouent.
C (Cohérence) : Cohérence. Lorsque l'état de la base de données passe d'un état à un autre, les contraintes d'intégrité de la base de données restent inchangées avant le début et après la fin de la transaction. Que signifie la contrainte d’intégrité de la base de données ? Par exemple, si le champ de nom d'une table est une contrainte unique, si le champ de nom devient non unique après la validation ou l'annulation de la transaction, cela détruira la contrainte d'intégrité de la base de données.
I (Isolement) : Isolement. Plusieurs transactions simultanées sont exécutées sans s'affecter mutuellement.
D (Durabilité) : Durabilité. Une fois la transaction validée, ses modifications dans la base de données peuvent être enregistrées de manière permanente dans la base de données. Par conséquent, cette fonctionnalité nécessite que le système de base de données soit capable de soumettre des données sans les perdre lorsqu'elles doivent être restaurées en cas de panne.
Par conséquent, au début, notre système ne disposait que d'une seule source de données. À cette époque, nous pouvions compter sur les transactions du système de base de données pour garantir l'exactitude de l'entreprise.
Cependant, à mesure que l'activité continue de se développer, une seule table de notre entreprise peut contenir des dizaines de millions de données. Lors de l'utilisation d'une autre instance de base de données, des problèmes de performances peuvent survenir. À ce stade, nous considérerons les sous-bases de données et les tables. Cependant, cela peut conduire à ce qu'une seule application se connecte à plusieurs sources de données. Voir l'exemple ci-dessous.
Dans le processus d'achat illustré ci-dessus, le tableau du solde du commerçant et le tableau du solde de l'utilisateur se trouvent dans deux instances de base de données distinctes, de sorte que des transactions distinctes puissent garantir déductions La déduction du solde du commerçant ou du solde de l'utilisateur réussit ou échoue. Mais nous ne pouvons garantir que les deux transactions réussiront ou échoueront en même temps.
Il existe une autre situation. À mesure que le système devient de plus en plus grand, nous choisirons de diviser l'application système en plusieurs microservices, de sorte qu'une seule application ne puisse exploiter qu'une seule source de données. À l’heure actuelle, nous rencontrerons une situation dans laquelle un appel professionnel appellera plusieurs applications et chaque application exploitera la source de données indépendamment, comme indiqué ci-dessous.
Dans ce cas, nous ne pouvons garantir que tous les appels aboutiront.
À partir de l'exemple ci-dessus, nous pouvons voir qu'avec le développement des affaires, les transactions autonomes traditionnelles ne peuvent plus répondre aux besoins de notre entreprise. À l'heure actuelle, nous avons besoin de transactions distribuées pour l'assurer.
Transactions distribuées
Extraire une explication du wiki.
Une transaction distribuée est une transaction de base de données dans laquelle deux ou plusieurs hôtes réseau sont impliqués.
Parlons d'abord de quelques bases théoriques pour la mise en œuvre de transactions distribuées.
Théorie de la technologie des transactions distribuées
Théorème CAP. Dans un système distribué (un ensemble de nœuds connectés les uns aux autres et partageant des données), lorsqu'il s'agit d'opérations de lecture et d'écriture, seules la cohérence, la disponibilité et la tolérance de partition peuvent être garanties. Des deux, l'autre doit être sacrifiée. .
Extrait de Geek Time Learning Architecture de 0 Chapitre 22 Explication
Bien que la définition théorique du CAP soit que seuls deux des trois éléments peuvent être pris, mais quand on y pense dans un environnement distribué, nous constaterons que l'élément P (tolérance de partition) doit être sélectionné car le réseau lui-même je ne peux pas atteindre 100%
Il est fiable et peut échouer, le partitionnement est donc un phénomène inévitable. Si nous choisissons CA et abandonnons P, alors lorsque le partitionnement se produit, afin de garantir
C, le système doit interdire l'écriture. Lorsqu'il y a une demande d'écriture, le système renvoie une erreur (par exemple, le système actuel n'autorise pas l'écriture), qui entre en conflit avec A, car A exige qu'aucune erreur ne soit renvoyée.
et pas de délai d'attente. Par conséquent, il est théoriquement impossible de choisir l'architecture CA pour les systèmes distribués, et ne peut choisir que l'architecture CP ou AP
Théorie BASE, qui sont les abréviations des trois mots suivants.
Basiquement disponible : lorsqu'une panne se produit dans un système distribué, certaines fonctions disponibles peuvent être perdues pour garantir que les fonctions principales sont disponibles.
État logiciel : permet l'existence d'états intermédiaires dans le système. Cet état n'affecte pas la disponibilité du système. Il fait référence aux incohérences dans le CAP.
Finalement cohérent : finalement, la cohérence signifie qu'après un certain temps, toutes les données des nœuds seront cohérentes.
BASE est un complément au dispositif AP en CAP. Utilisez l’état logiciel et la cohérence éventuelle dans BASE pour garantir une cohérence retardée. BASE et ACID sont opposés. ACID est un modèle de cohérence forte, mais BASE sacrifie cette forte cohérence, permettant aux données d'être incohérentes sur une courte période et finalement cohérentes.
Ensuite, examinons les options de mise en œuvre pour les transactions distribuées.
Plan de mise en œuvre des transactions distribuées
Basé sur le niveau de ressources de la base de données
Basé sur le niveau métier
Basé sur la solution de mise en œuvre au niveau des ressources de base de données, puisqu'il existe plusieurs transactions, nous devons avoir un rôle pour gérer le statut de chaque transaction. Nous appelons ce rôle le coordinateur et les participants à la transaction sont appelés participants. Les participants et les coordinateurs s'appuient généralement sur un protocole spécifique, actuellement le plus connu est le protocole d'interface XA. Sur la base des paramètres idéologiques du coordinateur et des participants, 2PC et 3PC ont été proposés pour mettre en œuvre des transactions distribuées XA.
Protocole de validation en deux phases 2PC
Comme son nom l'indique, ce processus est principalement divisé en deux étapes.
Dans la première phase, le coordinateur (gestionnaire de transactions) pré-soumettra la transaction concernée. À ce moment-là, les ressources de la base de données commencent à être verrouillées. Les participants écrivent les annulations et les rétablissements dans le journal des transactions.
Dans la deuxième phase, le participant (gestionnaire de ressources) valide la transaction ou utilise le journal d'annulation pour annuler la transaction et libérer les ressources.
L'ensemble du processus est indiqué ci-dessous.
Scénario réussi de soumission de transaction distribuée :
Scénario d'annulation de transaction distribuée :
Les avantages de cette solution sont : une mise en œuvre relativement simple, supportée par des bases de données grand public, et une forte cohérence. MySQL 5.5 et versions ultérieures seront implémentées sur la base du protocole XA
La solution correspondante présente également des défauts :
Le problème unique du coordinateur. Si le coordinateur tombe en panne pendant la phase de soumission et que les participants attendent, les ressources seront verrouillées et bloquées. Même s'il est possible de réélire le coordinateur, cela ne résout pas le problème.
Le temps de blocage de la synchronisation est trop long. L'ensemble du processus d'exécution de la transaction est bloqué jusqu'à ce que la soumission soit terminée et que les ressources soient libérées si pendant le processus de soumission/de restauration, en raison du retard du réseau. , les participants ont été Si aucune instruction n'est reçue, le participant reste bloqué.
Les données sont incohérentes. Dans la deuxième étape, le coordinateur envoie le premier signal de validation, puis descend. Ensuite, le premier participant valide la transaction, et le deuxième participant ne peut pas valider la transaction car il n'a pas reçu le signal du coordinateur.
Ainsi, sur la base des lacunes de 2PC, un plan d'amélioration a été proposé, 3PC.
Protocole de soumission en trois phases 3PC
La soumission en trois phases, basée sur la soumission en deux phases, améliore les deux phases. Les étapes en trois étapes sont les suivantes.
CanCommit, le coordinateur demande au participant si la transaction peut être validée.
PreCommit, si tous les participants peuvent valider la transaction, le coordinateur émet la commande PreCommit, et les participants verrouillent les ressources et attendent la commande finale.
Tous les participants renvoient des informations de confirmation et le coordinateur émet des notifications d'exécution de transaction pour chaque transaction, verrouille les ressources et renvoie l'état d'exécution.
Certains participants ont renvoyé des informations de refus ou le coordinateur a expiré. Dans ce cas, le coordinateur estime que la transaction ne peut pas être exécutée normalement, émet une commande d'interruption et chaque participant sort de l'état de préparation
Do Commit, si toutes les réponses à l'accusé de réception dans la deuxième phase sont émises, Do Commit sera émis pour la soumission finale de la transaction, sinon une commande d'interruption de transaction sera émise et tous les participants seront annuler la transaction.
Tous les participants exécutent les transactions normalement et le coordinateur émet les instructions de validation finales pour libérer les ressources verrouillées.
Certains participants n'ont pas réussi à exécuter la transaction, le délai du coordinateur a expiré et le coordinateur a émis une commande de restauration pour libérer les ressources verrouillées.
Voir l'image ci-dessous pour plus de détails.
Soumission en trois phases par rapport à deux phases, introduisant un mécanisme de délai d'attente pour réduire le blocage des transactions et résoudre les points de défaillance uniques. Dans la troisième phase, une fois que le participant ne reçoit pas le signal du coordinateur, après avoir attendu le délai d'attente, le participant exécute la validation par défaut et libère des ressources.
Les trois étapes ne peuvent toujours pas résoudre le problème de cohérence des données. Si le coordinateur émet une commande d'annulation, mais qu'en raison de problèmes de réseau, les participants ne peuvent pas la recevoir dans le délai d'attente, les participants valident la transaction par défaut et les autres transactions sont annulées, ce qui entraîne une incohérence des transactions.
TCC
Transaction TCC
Afin de résoudre le problème du verrouillage des ressources à grande granularité lors de l'exécution d'une transaction, l'industrie propose un nouveau modèle de transaction, basé sur le définition des transactions au niveau de l’entreprise. La granularité du verrouillage est entièrement contrôlée par l’entreprise elle-même. Il s'agit essentiellement d'une idée de compensation. Il divise le processus d'exécution de la transaction en deux étapes : Essayer et Confirmer/Annuler. La logique à chaque étape est contrôlée par le code métier. De cette manière, la granularité du verrouillage de la transaction peut être entièrement contrôlée librement. Les entreprises peuvent atteindre de meilleures performances au détriment de l’isolement.
TCC sont respectivement les abréviations de Trying, Confirm et Cancel. Contrairement à 2PC et 3PC qui sont basés sur le niveau base de données, TCC est basé sur le niveau application.
Les trois actions du TCC sont :
Essayer :
Confirmer :
Annuler :
L'énoncé ci-dessus peut sembler un peu maladroit et difficile à comprendre, mais cela n'a pas d'importance. Utilisons des cas réels pour l'expliquer.
Ci-dessous, nous simulons un processus de paiement dans un centre commercial. Les utilisateurs utilisent le paiement combiné lors de la passation de commandes, c'est-à-dire le solde et le paiement par enveloppe rouge. Un processus normal est le suivant :
Créer une commande
Passer une commande
Appeler le solde Système, déduisez le solde
Appelez le système des enveloppes rouges, déduisez le solde de l'enveloppe rouge
Modifiez le statut de la commande en payé
Payez une fois terminé.
Le processus réel est comme indiqué ci-dessous.
Cependant, un tel processus de paiement appelle plusieurs sous-services, et nous ne pouvons pas garantir que tous les services pourront réussir. Par exemple, nous appelons. le système d'enveloppe rouge pour déduire le système d'enveloppe rouge échoue. À ce moment-là, nous avons rencontré une scène embarrassante. En raison de l'échec du service enveloppe rouge, la méthode s'est terminée anormalement. À ce moment-là, le statut de la commande était le statut initial, mais le solde de l'utilisateur avait été déduit. Ceci est très défavorable à l’expérience utilisateur. Par conséquent, au cours de ce processus de paiement, nous devons disposer d'un mécanisme pour traiter ce processus comme un comportement global, et nous devons garantir que tous les appels de service dans ce processus réussissent ou échouent et deviennent une transaction globale.
À l'heure actuelle, nous pouvons introduire des transactions TCC pour traiter l'ensemble du processus de commande dans son ensemble. Après l'introduction, en raison de l'échec de la déduction du système de solde, nous avons annulé le système de commande et le système d'enveloppe rouge à ce moment-là. L’ensemble du processus est présenté ci-dessous.
En raison de la défaillance du système de solde, nous devons annuler toutes les modifications apportées à ce processus, nous envoyons donc un avis d'annulation au système de commande et un système d'enveloppes rouges Avis de révocation.
Ainsi, après que le système ait introduit les transactions TCC, nous devons transformer notre processus d'appel.
Comment introduire les transactions TCC dans le système
Selon les trois étapes des transactions TCC, à ce moment nous devons transformer chaque service en trois étapes de Try Confirm Cancelle,
TCC ESSAYER :
Sur la base de l'activité ci-dessus, le système de commande ajoute une méthode d'essai pour modifier le statut de la commande en PAYING. Le système de solde ajoute une méthode d'essai, qui vérifie d'abord si le solde est suffisant, puis déduit le solde, puis ajoute le solde déduit au montant gelé. Le système de l'enveloppe rouge est le même que le système de balance. Le processus de transformation montre que la méthode TCC try doit vérifier chaque ressource métier et que ce processus doit introduire des états intermédiaires. Examinons l'ensemble du processus en fonction de l'image ci-dessous.
Confirmer TCC :
Étape 1 de TCC ESSAYER Si tous les appels de sous-service réussissent, nous devons à ce moment-là confirmer chaque Servir. Ajoutez une méthode de confirmation à chaque service. Par exemple, la méthode de confirmation du système de solde est utilisée pour fixer le montant gelé à 0, et le système d'enveloppe rouge est comme ci-dessus. Le système de commande change le statut de la commande en SUCCÈS. La méthode de confirmation doit prêter attention à l’obtention de l’idempotence. Par exemple, avant de mettre à jour le système de commande, vous devez d'abord déterminer que le statut de la commande est PAYING avant de pouvoir mettre à jour la commande. L’ensemble du processus est présenté ci-dessous.
À ce stade, le cadre de transaction TCC doit être utilisé pour promouvoir chaque service. Une fois que le gestionnaire de transactions TCC a détecté la fin de la méthode TRY, il appelle automatiquement la méthode de confirmation fournie par chaque service pour modifier l'état de chaque service vers l'état final.
Annulation TCC :
Si la méthode de gel de l'enveloppe rouge échoue pendant le processus TCC Try, nous devons alors annuler toutes les modifications précédentes et les remettre à leur état initial. La méthode cancle doit également implémenter l'idempotence telle que la méthode de confirmation comme indiqué ci-dessous :
En voyant cela, nous pouvons voir que TCC Try est réussi et confirmer doit être un succès, essayer échoue et annuler doit réussir. Parce que la confirmation est la clé pour mettre à jour le système vers l’état final. Mais la réalité est si impitoyable qu'il y a certainement une chance que la confirmation ou l'annulation dans le système de production échoue. Dans ce cas, le cadre TCC est requis pour enregistrer le résultat de l'appel de confirmation. Si l'appel de confirmation échoue, le framework TCC doit l'enregistrer puis le rappeler à un certain intervalle.
Résumé et réflexions
Après avoir lu le texte intégral, vous devez essentiellement comprendre les transactions distribuées.
Sur cette base, nous résumons ceci. Pour utiliser des transactions distribuées, nous devons les appliquer en conjonction avec nos scénarios réels.
Si l'entreprise en est encore à ses débuts, nous pouvons en fait choisir des transactions de base de données pour garantir une itération en ligne rapide.
Lorsque l'entreprise atteint un certain stade, le système commence à être divisé et la base de données est également divisée. À ce moment-là, si l'entreprise doit assurer la cohérence, des transactions distribuées doivent être utilisées. Lorsque nous utilisons des transactions distribuées à l’heure actuelle, nous devons déterminer laquelle utiliser en fonction de l’activité.
Grâce au framework distribué implémenté par 2PC ou 3PC, la couche applicative métier n'a pas besoin d'être modifiée et l'accès est relativement simple. Cependant, les performances correspondantes sont faibles et les ressources de données sont verrouillées pendant une longue période. Ne convient pas aux scénarios commerciaux à forte concurrence tels qu'Internet.
L'utilisation d'un framework distribué basé sur TCC a des performances supérieures à 2PC et peut garantir la cohérence finale des données. Mais pour la couche application, une méthode doit être transformée en trois méthodes, et certains états intermédiaires doivent être introduits dans l'entreprise. Relativement parlant, le degré de transformation des applications est relativement important.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
