Problème de transaction distribuée
1. Qu'est-ce qu'une transaction distribuée ?
Une opération de publication de cours nécessite l'écriture de quatre éléments de données dans la base de données, Redis, ElasticSearch et MinIO. Il y a ici un problème de transaction distribuée.
Qu'est-ce qu'une transaction distribuée ?
Comprenez d’abord ce que sont les affaires locales ?
Habituellement, nous utilisons Spring pour contrôler les transactions dans le programme en utilisant les caractéristiques de transaction de la base de données elle-même, c'est pourquoi on l'appelle transaction de base de données. Puisque l'application s'appuie principalement sur la base de données relationnelle pour contrôler la transaction, et que la base de données est généralement sur le même serveur comme l'application, il est basé sur le type relationnel. Les transactions de base de données sont également appelées transactions locales.
Les transactions locales ont quatre caractéristiques ACID. Une fois mises en œuvre, les transactions de base de données incorporeront toutes les opérations impliquées dans une transaction dans une unité d'exécution indivisible. Toutes les opérations de cette unité d'exécution réussiront ou échoueront, tant que l'une d'entre elles ne réussira pas à exécuter l'opération. entraîner l’annulation de l’intégralité de la transaction.
Après avoir compris les affaires locales, qu'est-ce qu'une transaction sous- 1 ?
L'exigence actuelle est d'écrire les données dans quatre emplacements : base de données, redis, elasticsearch et MinIO après l'opération de publication du cours. Ces quatre emplacements ne sont plus limités à une seule base de données. Ils sont fournis par quatre services dispersés. Ces quatre services. La communication nécessite un réseau. communication, et le réseau est inaccessible. Dans cet environnement de système distribué, la réalisation de transactions via une communication réseau avec différents services est appelée une transaction distribuée.
Il existe de nombreux scénarios pour les transactions distribuées dans les systèmes distribués :
Par exemple, les utilisateurs s'inscrivent pour recevoir des points, effectuer des virements bancaires et créer des commandes pour réduire les stocks. Ce sont toutes des transactions distribuées.
Prenons l'exemple du transfert :
Nous savons que les transactions locales reposent sur les fonctionnalités de transaction fournies par la base de données elle-même, donc la logique suivante peut contrôler les transactions locales :
| Java |
Mais dans un environnement distribué, cela ressemblera à ceci :
| Java |
On peut imaginer que lorsque l'appel à distance pour que Li Si augmente le montant ait réussi, l'appel à distance n'a pas été renvoyé en raison de problèmes de réseau. À ce moment-là, la soumission de la transaction locale a échoué et l'opération de réduction du montant de Zhang San a été annulée. A cette époque, les données de Zhang San et Li Si étaient incohérentes.
Par conséquent, sur la base de l'architecture distribuée, les transactions de base de données traditionnelles ne peuvent pas être utilisées. Les comptes de Zhang San et Li Si ne sont pas dans la même base de données ni même dans le même système d'application. Pour mettre en œuvre la transaction de transfert, des appels à distance sont nécessaires, ce qui permettra conduire à la distribution en raison de problèmes de réseau.
Les scénarios suivants généreront des transactions distribuées :
Sous l'architecture des microservices :
Service unique et plusieurs bases de données :
Base de données unique multi-serveurs :
2. Qu'est-ce que la théorie de la PAC
Pour contrôler les transactions distribuées, vous devez d’abord comprendre la théorie CAP. Qu’est-ce que la théorie CAP ?
CAP est l'abréviation de Cohérence, Disponibilité et Tolérance de partition, qui représentent respectivement la cohérence, la disponibilité et la tolérance de partition.
Utilisez la structure de système distribué suivante pour illustrer :
Le client accède aux deux nœuds du service utilisateur via la passerelle. La cohérence signifie que les données obtenues par l'utilisateur sont les dernières, quel que soit le nœud visité. Par exemple, l'interrogation des informations de Xiao Ming ne peut pas apparaître deux fois sans que les données ne changent. les résultats sont différents.
La disponibilité signifie que les résultats peuvent être récupérés à tout moment lors de l'interrogation des informations utilisateur, mais il n'y a aucune garantie que les données les plus récentes puissent être récupérées.
La tolérance de partition est également appelée tolérance aux pannes de partition. En raison d'anomalies de communication réseau, les demandes sont interrompues et les messages sont perdus, mais le service est toujours fourni au monde extérieur.
La théorie CAP souligne que ces trois points ne peuvent pas être satisfaits dans un système distribué. Puisqu'un système distribué doit respecter la tolérance de partition, des anomalies de réseau se produiront inévitablement entre les services et l'ensemble du système ne peut pas être indisponible en raison d'anomalies du réseau local.
Si P est satisfait alors C et A ne peuvent pas être satisfaits en même temps :
Par exemple, si nous ajoutons les informations d'un utilisateur Xiao Ming, les informations sont d'abord ajoutées au nœud 1 puis synchronisées avec le nœud 2, comme indiqué ci-dessous :
Si vous souhaitez atteindre la cohérence C, vous devez attendre que la synchronisation des informations de Xiao Ming soit terminée avant de pouvoir utiliser le système (sinon, les données ne peuvent pas être interrogées lorsque la requête est envoyée au nœud 2, ce qui viole la cohérence). n'est pas disponible pendant le processus de synchronisation des informations, donc A ne peut pas être satisfait alors que C est satisfait.
Si vous souhaitez répondre à la disponibilité A, vous devez vous assurer que le système est disponible à tout moment sans attendre la fin de la synchronisation des informations. À ce stade, la cohérence du système ne peut pas être assurée.
Par conséquent, lors de l'exécution d'un contrôle de transaction distribué dans un système distribué, CP ou AP doivent être garantis.
3. Solution de contrôle des transactions distribuées
Comment contrôler les transactions distribuées en apprenant la théorie CAP ?
Après avoir étudié la théorie CAP, nous savons que pour le contrôle distribué des transactions, nous devons faire un choix entre C et A. Pour assurer la cohérence, nous n'avons pas besoin d'assurer la disponibilité, et pour garantir la disponibilité, nous n'avons pas besoin d'assurer la cohérence. Tout d'abord, vous devez confirmer si vous avez besoin de CP ou d'AP, qui doit être basé sur le scénario d'application.
Scénario CP : satisfaire C et abandonner A, en mettant l'accent sur la cohérence.
Virement interbancaire : Une demande de transfert doit attendre que les deux systèmes bancaires aient terminé la totalité de la transaction avant de la finaliser. Tant que l'un d'eux échoue, l'autre partie effectue une opération de rollback.
Opération d'ouverture de compte : lors de l'ouverture d'un compte dans le système d'entreprise, vous devez ouvrir un compte auprès de l'opérateur en même temps. Si l'une ou l'autre des parties ne parvient pas à ouvrir un compte, l'utilisateur ne pourra pas l'utiliser, le CP doit donc être rencontré.
Scénario AP : satisfaire A et éliminer C, en mettant l'accent sur la disponibilité.
Pour les remboursements de commande, le remboursement est réussi aujourd'hui et sera crédité sur le compte demain, à condition que l'utilisateur puisse accepter que le crédit soit crédité dans un certain délai.
Inscrivez-vous pour obtenir des points, et les points seront crédités sur votre compte dans les 24 minutes si vous vous inscrivez avec succès.
Pour la communication par SMS de paiement, un message texte sera envoyé si le paiement est réussi. Le SMS peut être retardé ou même ne pas être envoyé avec succès.
Dans les applications pratiques, il existe de nombreux scénarios conformes à AP. En fait, même si AP abandonne la cohérence C, les données finales sont en réalité cohérentes, ce qui satisfait à la cohérence ultime. Par conséquent, l'industrie définit la théorie BASE.
Qu’est-ce que la théorie BASE ?
BASE est l'abréviation des trois expressions Basically Available, Soft state et Eventally cohérent.
Disponibilité de base : lorsque le système ne peut pas répondre à toutes les exigences disponibles, il suffit de s'assurer que les services de base sont disponibles. Par exemple, dans un système à emporter, la simultanéité du système est très élevée vers midi. À ce moment-là, il est nécessaire de garantir que les services impliqués dans le processus de commande sont disponibles et que les autres services sont temporairement indisponibles.
État doux : cela signifie qu'il peut y avoir un état intermédiaire, comme l'impression de vos propres statistiques de sécurité sociale. Le résultat de cette opération n'apparaîtra pas immédiatement, mais il vous indiquera que l'impression est en cours. Veuillez vérifier après XXX temps. Bien qu’il existe des états intermédiaires, l’état final est correct.
Cohérence finale : une fois que l'opération de remboursement n'est pas créditée à temps, le compte sera crédité après un certain temps, une cohérence forte est rejetée et une cohérence finale est satisfaite.