Comment implémenter le traitement distribué des transactions en langage Go ?

À mesure que l'échelle des applications Internet continue de s'étendre et que les services verticaux se divisent progressivement, le développement de systèmes distribués devient de plus en plus important. La question qui se pose est de savoir comment gérer la cohérence des transactions dans un tel système. Cet article présentera quelques solutions traditionnelles de traitement de transactions distribuées dans le langage Go et leurs principes de mise en œuvre.

Transactions ACID traditionnelles

Dans les systèmes autonomes, les applications utilisent généralement des transactions ACID traditionnelles pour garantir la cohérence des données. ACID est l'abréviation d'Atomicité, Cohérence, Isolation et Durabilité, qui représentent respectivement les quatre attributs clés d'une transaction :

• Atomicité : Une série d'opérations dans une transaction, soit toutes réussissent , ou tous échouent, il n’y a pas d’état intermédiaire.
• Cohérence : L'exécution des transactions ne violera pas les contraintes d'intégrité de la base de données.
• Isolement : plusieurs transactions exécutées simultanément sont isolées et n'interféreront pas les unes avec les autres.
• Durabilité : Une fois qu'une transaction est engagée, ses résultats sont permanents.

Cependant, lorsqu'une application devient une application distribuée, des complexités plus importantes doivent être gérées, notamment la latence du réseau, la messagerie peu fiable, le fractionnement des données, etc., si les transactions ACID traditionnelles sont toujours utilisées, la complexité et la surcharge du système seront augmentées, des goulots d'étranglement en termes de performances se produiront et l'évolutivité du système sera limitée. Par conséquent, les systèmes distribués nécessitent une nouvelle solution capable de gérer la cohérence des transactions dans un environnement distribué. Cohérence de la théorie CAP : dans un environnement distribué, tous les nœuds ont la même vue.

Availability (Availability) : L'application limite la précision appropriée lors de la réponse aux demandes.

Partition Tolerance : Le système peut continuer à fonctionner lorsque des partitions réseau se produisent entre les machines.

• La théorie CAP soutient que dans tout système distribué, au plus deux de ces éléments peuvent être satisfaits simultanément. Autrement dit, si nous voulons assurer la cohérence et la disponibilité des systèmes distribués, nous devons tolérer l'apparition de partitions réseau. Si nous voulons atteindre la cohérence et la tolérance de partition, nous devons dans ce cas renoncer à la disponibilité.
• Transactions BASE
• Contrairement à ACID, les systèmes distribués utilisent généralement des transactions de style BASE pour gérer la cohérence des transactions. BASE est l'abréviation de Basically Available, Soft state, Finalement cohérent.

Basiquement disponible : essayez d'assurer la disponibilité du système, même si le système tombe en panne, cela n'affectera pas la disponibilité de l'ensemble du système.

État doux : le système rendra les données d'état incohérentes pendant un certain temps et ne garantit pas que les données d'état seront cohérentes en temps réel. Finalement cohérent : le système finira par atteindre un état cohérent.

Les transactions BASE ne garantissent pas une forte cohérence, mais atteignent l'objectif de cohérence des transactions grâce à une cohérence éventuelle. Les transactions BASE ne conviennent pas aux applications qui doivent satisfaire des contraintes, mais conviennent aux applications volumineuses, aux entrepôts de données et à d'autres projets qui doivent traiter de grandes quantités de données.

• Solution d'implémentation de transactions distribuées
• In Go, il existe actuellement trois solutions d'implémentation de transactions distribuées grand public :

Deux phases Deux phases Commit Protocol

Le Two-Phase Commit Protocol est un protocole de synchronisation utilisé pour la gestion des transactions distribuées. Il garantit l'atomicité, la cohérence et l'isolement des transactions distribuées lorsqu'elles sont exécutées sur plusieurs nœuds. Parmi eux, le coordinateur est responsable de la gestion du protocole de validation global, et chaque nœud est responsable de l'exécution du protocole de validation/rollback.

Dans le protocole de validation en deux phases, il y a deux phases :

1. 1 Phase de préparation : le coordinateur demande à tous les nœuds participants s'ils sont prêts à valider la transaction. Si tous les nœuds sont prêts, entrez dans la phase de soumission. Sinon, la transaction est annulée.

2. Phase de validation : tous les nœuds participants émettent des instructions de « soumission » ou de « rollback » au coordinateur. Si tous les nœuds sont soumis avec succès, la transaction distribuée est terminée. Si au moins un nœud ne parvient pas à valider, la transaction est annulée.

Cependant, le protocole de validation en deux phases aura un problème de blocage dans la phase de préparation (ce qu'on appelle le problème de blocage en deux phases). À ce stade, certains nœuds peuvent avoir soumis tandis que d'autres. les nœuds sont bloqués après la phase de préparation. Il en résulte que certains nœuds ne reçoivent probablement jamais d'instructions de restauration, ce qui entraîne une incohérence des données. Par conséquent, le protocole de validation en deux phases n’est pas une solution parfaite de traitement de transactions distribuées.

2. Protocole de validation en trois phases

Le protocole de validation en trois phases est une optimisation du protocole de validation en deux phases, dans le but de réduire le blocage en deux phases problème apparaît. Il divise la phase de préparation du protocole de validation en deux phases en deux sous-phases :

1 Phase de demande (phase de demande) : le coordinateur demande aux nœuds participants s'ils sont prêts à valider la transaction.

2. Phase de préparation : les nœuds participants confirment s'ils sont prêts à valider des transactions.

Comme son nom l'indique, le protocole de soumission en trois phases comprend trois étapes :

1. Phase CanCommit : Le coordinateur demande à chaque nœud participant s'il est prêt à valider la transaction.
2. Phase PreCommit : si tous les nœuds sont prêts, entrez dans la phase de pré-commit. Sinon, le coordinateur envoie un message de restauration.
3. Phase DoCommit : si chaque nœud participant est sûr qu'aucune erreur ne se produira pendant le processus de pré-commit et de validation, il enverra un message de validation. Si un nœud participant rencontre une erreur pendant le processus de pré-validation ou de validation, un message de restauration est envoyé.

L'avantage du protocole de validation en trois phases est que par rapport au protocole de validation en deux phases, il réduit la possibilité de blocage en deux phases et peut répondre plus rapidement aux échecs (tels que le basculement). Cependant, le problème persiste : il se peut qu'il ne soit pas en mesure de gérer les partitions réseau.

3.SAGA Pattern (Saga Pattern)

Le modèle SAGA est une solution de mise en œuvre de transactions longues qui atteint les objectifs suivants en divisant la transaction en une série d'étapes interdépendantes et en convertissant chaque étape en une opération atomique :

• Réduire la portée des transactions dans la plus grande mesure possible.
• Il n'est pas nécessaire de faire respecter la cohérence à toutes les étapes.
• Vous pouvez revenir en arrière partiellement, pas toutes les étapes.

Le mode SAGA se compose de plusieurs étapes, chaque étape effectue une partie des opérations de transaction. Ces opérations peuvent être n'importe quelle opération pouvant obtenir une garantie d'idempotence (c'est-à-dire que l'opération elle-même peut être exécutée à plusieurs reprises sans affecter les résultats). Si une étape échoue, le mode SAGA fera reculer l'étape en avant ou en arrière selon la situation d'exécution, et atteindra finalement un état dans lequel les opérations de toutes les étapes ont été exécutées correctement ou ne peuvent pas être annulées.

Grâce au mode SAGA, nous pouvons réaliser le développement, le déploiement et l'expansion indépendants de chaque module métier, au prix de la prise en charge d'un retour en arrière au moins partiel ; le mode SAGA garantira le résultat final, il n'est donc pas nécessaire de s'assurer que toutes les étapes sont strictement cohérentes, ce qui le rend capable de fonctionner dans des environnements distribués asynchrones/synchrones complexes.

Résumé

Dans le langage Go, nous disposons de nombreuses façons de gérer le traitement des transactions distribuées, telles que les protocoles distribués, les schémas de transactions longues et Saga. Chaque solution présente ses propres avantages et inconvénients et est appliquée de manière optimale dans des scénarios appropriés. Dans les applications pratiques, nous devons faire des choix en fonction de circonstances spécifiques pour mieux parvenir à une gestion distribuée des transactions.

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!