Introduction détaillée aux transactions distribuées Fescar (images et texte)

Le contenu de cet article est une introduction aux transactions distribuées Fescar (images et textes). Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

1. Transaction distribuée Fescar (présentation)

1.1 Présentation

Fescar est le middleware de transaction distribuée open source d'Alibaba, résout le problème distribué. problèmes de transaction rencontrés dans les scénarios de microservices de manière efficace et sans intrusion pour l'entreprise.

1.2. L'historique de développement de Fescar

En 2014, l'équipe middleware d'Alibaba a lancé TXC (Taobao Transaction Constructor) pour fournir des services de transactions distribuées pour les applications du groupe.

En 2016, TXC a subi une transformation de produit et a atterri sur Alibaba Cloud sous le nom de GTS (Global Transaction Service), devenant ainsi le seul produit de transaction distribué basé sur le cloud du secteur à l'époque dans le cloud public d'Alibaba, dans la solution cloud propriétaire. , elle a commencé à servir de nombreux clients externes.

Depuis 2019, sur la base de l'accumulation technologique de TXC et GTS, l'équipe middleware d'Alibaba a lancé le projet open source Fescar (Fast & EaSy Commit And Rollback, FESCAR) pour construire cette solution de transaction distribuée en collaboration avec la communauté. .

1.3. Intention de conception originale

Aucune intrusion dans l'entreprise

Haute performance

1.4.Principe et conception

1.4.1. Carte conceptuelle de conception

1. Coordinateur des transactions (TC) : Coordinateur des transactions, maintient l'état d'exécution des transactions globales, est responsable de coordonner et piloter la validation ou l'annulation des transactions mondiales.

2. Transaction Manager (TM) : Contrôle les limites de la transaction globale , est responsable de l'ouverture d'une transaction globale et initie finalement une commit global ou réponse globale La résolution à lancer.

3. Gestionnaire de ressources (RM) : Contrôler les transactions de la succursale, responsable de l'enregistrement de la succursale, du rapport d'état, de la réception des instructions du coordinateur des transactions et de la conduite des transactions de la succursale (locales) Validation et restauration.

1.4.2 Quelle est la différence avec XA ?

1. Le RM de la solution XA se trouve en fait dans la couche de base de données. Le RM est essentiellement la base de données elle-même (en fournissant). pilote à utiliser par l’application).

2. Le RM de Fescar est déployé en couche middleware sous forme de package second côté applicatif , ne dépend pas de la base de données elle-même La prise en charge du protocole, bien sûr ne nécessite pas que la base de données prenne en charge le protocole XA. Ceci est très important pour une architecture basée sur des microservices : la couche application n'a pas besoin de s'adapter à deux ensembles différents de pilotes de base de données pour les transactions locales et les transactions distribuées.

3. Cette conception supprime les exigences de la solution de transactions distribuées sur la prise en charge du protocole

1.4.3 de la base de données. Soumission en deux étapes

1.4.3.1. Processus 2PC pour XA

1. Processus 2PC pour XA
   

2. Peu importe que la résolution de la Phase2 soit une validation ou une annulation, le verrouillage des ressources transactionnelles doit être conservé jusqu'à ce que la Phase2 soit terminée avant d'être libérée.
   Imaginez une entreprise fonctionnant normalement. Il y a une forte probabilité que plus de 90 % des transactions soient finalement soumises avec succès. Pouvons-nous soumettre des transactions locales au cours de la phase 1 ? De cette manière, dans plus de 90 % des cas, le temps de maintien du verrou de la phase 2 peut être économisé et l’efficacité globale peut être améliorée.

1.4.3.2. Processus 2PC de fescar

1. local des données en transaction en succursale Le verrou est géré par la transaction locale et libéré à la fin de la transaction de branche Phase1.

2. En même temps, à la fin de la transaction locale, la connexion est également libérée.

3. Le verrouillage global des données dans la transaction de branche est géré du côté du coordinateur de la transaction. Lorsque la validation globale de la Phase2 est résolue, le verrou global peut être libéré. immédiatement. Ce n'est que lorsqu'un rollback global est résolu que le verrouillage global est maintenu jusqu'à la fin de la phase 2 de la branche.

4. Cette conception réduit considérablement le temps de verrouillage des ressources (données et connexions) par les transactions de succursale, fournissant ainsi une base pour améliorer la concurrence et le débit global.

1.4.4. Comment valider et annuler les transactions de branche ? (Point clé)

1. Tout d'abord, l'application doit utiliser le proxy de source de données JDBC de Fescar, qui est le RM de Fescar
   

2. L'agent de source de données JDBC de Fescar analyse le SQL métier et organise la mise en miroir des données métier avant et après la mise à jour dans un journal de restauration , en utilisant transactions locales La fonctionnalité ACID valide les mises à jour des données commerciales et les écritures du journal d'annulation dans la même transaction locale.

3. De cette manière, il peut être garanti que toute mise à jour des données commerciales soumises doit avoir un journal de restauration correspondant
   

4. Si la résolution est un commit global, la transaction de branche a été soumise à ce moment-là et aucune coordination synchrone n'est requise (seul le nettoyage asynchrone du journal de restauration est requis), Phase2 peut être réalisé très rapidement.

5. Si la résolution est une restauration globale, RM reçoit la demande de restauration du coordinateur, trouve l'enregistrement du journal de restauration correspondant via le XID et l'ID de branche, et génère des commentaires via l'enregistrement de restauration. Mettez à jour le SQL et exécutez-le pour terminer la restauration de la branche.

1.4.5. Mécanisme de propagation de transaction

1. XID est l'identifiant unique d'une transaction globale. Ce que le mécanisme de propagation de transaction doit faire. pour mettre le XID dedans Il est transmis via le lien d'appel de service et lié au contexte de transaction du service De cette manière, les opérations de mise à jour de la base de données dans le lien de service enregistreront les branches avec la transaction globale représentée par le XID et seront incluses dans. la juridiction de la même transaction mondiale.

2. Sur la base de ce mécanisme, Fescar peut prendre en charge n'importe quel framework RPC de microservices . Trouvez simplement un mécanisme dans un framework spécifique capable de propager XID de manière transparente, tel que Filter + RpcContext de Dubbo.

1.4.6. Le modèle de comportement de base des branches

Une transaction de branche qui fait partie de la transaction globale, en plus de sa propre logique métier, contient 4 interactions avec le coordinateur Comportement :

1. Enregistrement de la succursale : Avant que l'opération de données de la transaction de succursale ne soit effectuée, elle doit être enregistrée auprès du coordinateur pour inclure l'opération de données de transaction de succursale à venir dans un transaction globale déjà ouverte. Dans la gestion, les opérations sur les données ne peuvent être effectuées qu'une fois l'enregistrement de la succursale réussi.

2. Rapport d'état : une fois l'opération de données de la transaction de succursale terminée, ses résultats d'exécution doivent être signalés au coordinateur de la transaction.

3. Soumission de succursale : Répondez à la demande de soumission de transaction de succursale émise par le coordonnateur et complétez la soumission de succursale.

4. Annulation de branche : répondez à la demande d'annulation de transaction de branche émise par le coordinateur et terminez l'annulation de branche.
   

   1.4.7. Mode de comportement de la branche en mode AT

5. La logique métier n'a pas besoin de prêter attention au mécanisme de transaction et à l'interaction le processus entre les succursales et les transactions globales est automatique Réaliser
   

1.4.8 Modèle comportemental de la branche de modèle MT

1. . La logique métier doit être décomposée en 3 parties Prepare/Commit/Rollback pour former une branche MT et rejoindre la transaction globale.
   

1.4.9. Mode mixte

Parce que les branches des modes AT et MT ont un comportement fondamentalement cohérent, elles sont entièrement compatibles, c'est-à-dire c'est-à-dire, Dans une transaction globale, les succursales d'AT et MT peuvent exister en même temps . De cette manière, l'objectif de couverture complète des scénarios commerciaux peut être atteint : si le mode AT peut être pris en charge, utilisez le mode AT ; si le mode AT ne peut pas être pris en charge temporairement, utilisez plutôt le mode MT. De plus, bien entendu, les ressources non transactionnelles gérées en mode MT peuvent également être incluses dans la même gestion de transactions distribuées avec les ressources de bases de données relationnelles qui prennent en charge les transactions.

1.5. Planification de la version préliminaire

v0.1.0

• Prise en charge du framework microservice : Dubbo

• Base de données support : MySQL

• Annotation basée sur Spring AOP

• Coordinateur de transactions : version autonome

v0.5.x

• Prise en charge du framework microservice : Spring Cloud

• Mode MT

• Prise en charge de l'adaptation des transactions en mode TCC

• Configuration dynamique et découverte de services

• Coordinateur de transactions : version cluster haute disponibilité

v0.8.x

• Métriques

• Console : surveillance/déploiement/mise à niveau/mise à l'échelle/mise à l'échelle

v1.0.0

• Disponibilité générale : adaptée à l'environnement de production

v1.5.x

• Support de base de données : Oracle/PostgreSQL/OceanBase

• Annotation qui ne repose pas sur Spring AOP

• Mécanisme de traitement optimisé pour les données chaudes

• Les messages de transaction RocketMQ sont incorporés dans la gestion globale des transactions

• NoSQL est intégré dans le mécanisme d'adaptation de la gestion globale des transactions

• Support HBase

• Support Redis

v2.0.0

• Support XA
  Bien entendu, dans le processus d'évolution itérative du projet, ce à quoi nous attachons le plus d'importance est la voix de la communauté. La feuille de route sera entièrement communiquée à la communauté et ajustée. en temps opportun.

1.6.Résumé

 Après avoir lu l'aperçu, il est clairement indiqué qu'il prend en charge n'importe quel framework RPC de microservice dans lequel je souhaite maintenant le distribuer. une manière qui convient à Spring Cloud. Choisissez l'une des solutions de transaction. Vous me dites que Spring Cloud devrait être intégré dans la prochaine version. Si vous êtes un expert de passage, recommandez-en une

. 1.7. Adresse open source github

https://github.com/alibaba/fescar/

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!