Modèle Saga de transactions distribuées

Azure

Maintenir la cohérence des données dans les systèmes distribués en coordonnant une séquence de transactions locales entre plusieurs services. Chaque service effectue son opération et déclenche l’étape suivante dans les événements ou les messages. En cas d’échec d’une étape, une série de transactions de compensation annule les modifications apportées aux étapes terminées.

Contexte et problème

Une transaction représente une unité de travail, qui peut inclure plusieurs opérations. Dans une transaction, un événement fait référence à une modification d’état qui affecte une entité. Une commande encapsule toutes les informations nécessaires pour effectuer une action ou déclencher un événement suivant.

Les transactions doivent respecter les principes de l’atomicité, de la cohérence, de l’isolation et de la durabilité (ACID).

• Atomicité : Toutes les opérations réussissent ou ne réussissent pas.
• cohérence : les données passent d’un état valide à un autre état valide.
• Isolation: Les transactions concurrentes produisent les mêmes résultats que les transactions séquentielles.
• Durabilité : Les modifications persistent une fois validées, même en cas de défaillance.

Dans un seul service, les transactions suivent les principes ACID, car elles fonctionnent dans une base de données unique. Toutefois, il peut être plus complexe d’atteindre la conformité ACID entre plusieurs services.

Défis liés aux architectures de microservices

Les architectures de microservices attribuent généralement une base de données dédiée à chaque microservice. Cette approche offre plusieurs avantages :

• Chaque service encapsule ses propres données.
• Chaque service peut utiliser la technologie et le schéma de base de données les plus appropriés pour ses besoins spécifiques.
• Les bases de données pour chaque service peuvent être mises à l’échelle indépendamment.
• Les échecs d’un service sont isolés des autres services.

Malgré ces avantages, cette architecture complique la cohérence des données interservices. Les garanties de base de données traditionnelles comme ACID ne sont pas directement applicables à plusieurs magasins de données gérés indépendamment. En raison de ces limitations, les architectures qui s’appuient sur la communication interprocesseur ou les modèles transactionnels traditionnels tels que le protocole de validation en deux phases sont souvent mieux adaptées au modèle Saga.

Solution

Le patron Saga gère les transactions en les décomposant en une séquence de transactions locales.

Chaque transaction locale :

1. Exécute son travail de manière atomique dans un seul service.
2. Met à jour la base de données du service.
3. Lance la transaction suivante via un événement ou un message.

En cas d’échec d’une transaction locale, la saga effectue une série de transactions de compensation pour inverser les modifications apportées aux transactions locales précédentes.

Concepts clés dans le modèle Saga

• transactions compensables peuvent être annulées ou compensées par d’autres transactions ayant l’effet inverse. Si une étape de la saga échoue, les transactions de compensation annulent les modifications apportées par les transactions compensables.

• Les transactions pivots servent de point de non-retour dans la saga. Une fois qu’une transaction pivot réussit, les transactions compensables ne sont plus pertinentes. Toutes les actions suivantes doivent être effectuées pour que le système atteigne un état final cohérent. Une transaction pivot peut jouer différents rôles, en fonction du flux de la saga :

  • transactions irréversibles ou noncompensables ne peuvent pas être annulées ni retentées.

  • La frontière entre réversible et validé signifie que la transaction pivot peut être la dernière transaction annulable ou compensable. Ou il peut s’agir de la première opération pouvant être retentée dans la saga.

• Les transactions pouvant faire l’objet d’une nouvelle tentative suivent la transaction pivot. Les transactions pouvant faire l’objet de nouvelles tentatives sont idempotentes et contribuent à garantir que la saga peut atteindre son état final, même si des échecs temporaires se produisent. Ils aident la saga finalement à atteindre un état cohérent.

Approches d’implémentation de Saga

Les deux approches typiques de mise en œuvre du modèle Saga sont la chorégraphie et l’orchestration. Chaque approche a son propre ensemble de défis et de technologies pour coordonner le flux de travail.

Chorégraphie

Dans l’approche chorégraphique, les services échangent des événements sans contrôleur centralisé. Avec la chorégraphie, chaque transaction locale publie des événements de domaine qui déclenchent des transactions locales dans d’autres services.

Avantages de la chorégraphie	Inconvénients de la chorégraphie
Convient pour les flux de travail simples qui ont peu de services et n’ont pas besoin d’une logique de coordination.	Le flux de travail peut être déroutant lorsque vous ajoutez de nouvelles étapes. Il est difficile de suivre les commandes auxquelles chaque participant de saga répond.
Aucun autre service n’est nécessaire pour la coordination.	Il y a un risque de dépendance cyclique entre les participants d’une saga parce qu’ils doivent consommer les commandes des uns des autres.
N’introduit pas de point de défaillance unique, car les responsabilités sont réparties entre les participants de la saga.	Les tests d’intégration sont difficiles, car tous les services doivent s’exécuter pour simuler une transaction.

Orchestration

Dans l’orchestration, un contrôleur centralisé ou orchestrateur, gère toutes les transactions et indique aux participants quelle opération effectuer en fonction des événements. L’orchestrateur exécute des demandes de la saga, stocke et interprète les états de chaque tâche, et gère la récupération en cas de défaillance à l’aide de transactions de compensation.

Avantages de l’orchestration	Inconvénients de l’orchestration
Mieux adapté aux flux de travail complexes ou lorsque vous ajoutez de nouveaux services.	Une autre complexité de conception nécessite une implémentation d’une logique de coordination.
Évite les dépendances cycliques, car l’orchestrateur gère le flux.	Introduit un point de défaillance, car l’orchestrateur gère le flux de travail complet.
La séparation claire des responsabilités simplifie la logique de service.

Problèmes et considérations

Tenez compte des points suivants lorsque vous décidez comment implémenter ce modèle :

• Changement de paradigme de conception : L’adoption du patron Saga nécessite un état d’esprit différent. Il vous oblige à vous concentrer sur la coordination des transactions et la cohérence des données sur plusieurs microservices.

• Complexité du débogage des sagas : Le débogage des sagas peut être complexe, en particulier à mesure que le nombre de services participants augmente.

• Modifications irréversibles de la base de données locale : Les données ne peuvent pas être annulées, car les participants de la saga valident leurs modifications dans leur base de données respective.

• Gestion des défaillances temporaires et de l’idempotence : le système doit gérer efficacement les défaillances temporaires et garantir l’idempotence, lors de la répétition de la même opération ne modifie pas le résultat. Pour plus d’informations, consultez le modèle de consommateur idempotent.

• Nécessité de surveiller et de suivre les sagas : La surveillance et le suivi du déroulement d’une saga sont essentiels pour assurer la supervision opérationnelle.

• Limitations des transactions de compensation : transactions de compensation peuvent ne pas toujours réussir, ce qui peut laisser le système dans un état incohérent.

Anomalies potentielles des données dans les sagas

Les anomalies de données sont des incohérences qui peuvent se produire lorsque des sagas opèrent sur plusieurs services. Étant donné que chaque service gère ses propres données, appelées données des participants, il n’existe aucune isolation intégrée entre les services. Cette configuration peut entraîner des incohérences de données ou des problèmes de durabilité, tels que des mises à jour partiellement appliquées ou des conflits entre services. Les problèmes classiques sont les suivants :

• Mises à jour perdues : Lorsqu’une saga modifie des données sans tenir compte des changements apportés par une autre saga, cela entraîne des mises à jour écrasées ou manquantes.

• Lectures sales : lorsqu’une saga ou une transaction lit des données qu’une autre saga a modifiées, alors que cette modification n’est pas encore terminée.

• Lectures floues, ou non répétables : Lorsque différentes étapes d’une saga lisent des données incohérentes parce que des mises à jour surviennent entre les lectures.

Stratégies de résolution des anomalies de données

Pour réduire ou empêcher ces anomalies, tenez compte des contre-mesures suivantes :

• verrou sémantique : utiliser des verrous au niveau de l’application lorsque la transaction compensable d’une saga utilise un sémaphore pour indiquer qu’une mise à jour est en cours.

• mises à jour commutatives : mises à jour de conception afin qu’elles puissent être appliquées dans n’importe quel ordre tout en produisant le même résultat. Cette approche permet de réduire les conflits entre sagas.

• Vue pessimiste : réorganiser la séquence de la saga afin que les mises à jour des données se produisent dans des transactions retentables pour éliminer les lectures incorrectes. Sinon, une saga pourrait lire des données incorrectes ou modifications non validées, tandis qu’une autre saga effectue simultanément une transaction compensable pour restaurer ses mises à jour.

• valeurs de relecture : Confirmer que les données restent inchangées avant d’effectuer des mises à jour. Si les données changent, arrêtez l’étape actuelle et redémarrez la saga si nécessaire.

• Fichiers de version : conserver un journal de toutes les opérations effectuées sur un enregistrement et s’assurer qu’elles sont effectuées dans la séquence appropriée pour éviter les conflits.

• Contrôle de concurrence fondé sur le risque en fonction de la valeur : Choisissez dynamiquement le mécanisme de contrôle de concurrence approprié en fonction du risque métier potentiel. Par exemple, utilisez des sagas pour les mises à jour à faible risque et les transactions distribuées pour les mises à jour à haut risque.

Quand utiliser ce modèle

Utilisez ce modèle quand :

• Vous devez garantir la cohérence des données dans un système distribué sans couplage serré.
• Vous devez annuler ou compenser si l’une des opérations de la séquence échoue.

Ce modèle peut ne pas convenir lorsque :

• Les transactions sont étroitement couplées.
• Les transactions de compensation se produisent dans les participants antérieurs.
• Il existe des dépendances cycliques.

Étape suivante

• modèles de données natifs cloud

Ressources associées

Les modèles suivants peuvent être pertinents lorsque vous implémentez ce modèle :

• Le modèle chorégraphie a chaque composant du système à participer au processus décisionnel sur le flux de travail d’une transaction métier, au lieu de s’appuyer sur un point central de contrôle.

• Le modèle de transaction de compensation annule le travail exécuté par une série d’étapes et définit à terme une opération cohérente si une ou plusieurs étapes échouent. Les applications hébergées dans le cloud qui implémentent des processus métier et des flux de travail complexes suivent souvent ce modèle de cohérence .

• Le modèle de nouvelle tentative permet à une application de gérer les défaillances temporaires lorsqu’elle tente de se connecter à une ressource de service ou réseau en réessayant de manière transparente l’opération ayant échoué. Ce modèle peut améliorer la stabilité de l’application.

• Le modèle Circuit Breaker gère les défaillances dont la récupération peut prendre un temps variable lors de la connexion à un service ou une ressource distants. Ce modèle peut améliorer la stabilité et la résilience d’une application.

• Le modèle Supervision de point de terminaison d’intégrité implémente des contrôles fonctionnels dans une application à laquelle des outils externes peuvent accéder par le biais de points de terminaison exposés à intervalles réguliers. Ce modèle peut vous aider à vérifier que les applications et services fonctionnent correctement.

Maintenir la cohérence des données dans les systèmes distribués en coordonnant une séquence de transactions locales entre plusieurs services. Chaque service effectue son opération et déclenche l’étape suivante dans les événements ou les messages. En cas d’échec d’une étape, une série de transactions de compensation annule les modifications apportées aux étapes terminées.

Contexte et problème

Une transaction représente une unité de travail, qui peut inclure plusieurs opérations. Dans une transaction, un événement fait référence à une modification d’état qui affecte une entité. Une commande encapsule toutes les informations nécessaires pour effectuer une action ou déclencher un événement suivant.

Les transactions doivent respecter les principes de l’atomicité, de la cohérence, de l’isolation et de la durabilité (ACID).

• Atomicité : Toutes les opérations réussissent ou ne réussissent pas.
• cohérence : les données passent d’un état valide à un autre état valide.
• Isolation: Les transactions concurrentes produisent les mêmes résultats que les transactions séquentielles.
• Durabilité : Les modifications persistent une fois validées, même en cas de défaillance.

Dans un seul service, les transactions suivent les principes ACID, car elles fonctionnent dans une base de données unique. Toutefois, il peut être plus complexe d’atteindre la conformité ACID entre plusieurs services.

Défis liés aux architectures de microservices

Les architectures de microservices attribuent généralement une base de données dédiée à chaque microservice. Cette approche offre plusieurs avantages :

• Chaque service encapsule ses propres données.
• Chaque service peut utiliser la technologie et le schéma de base de données les plus appropriés pour ses besoins spécifiques.
• Les bases de données pour chaque service peuvent être mises à l’échelle indépendamment.
• Les échecs d’un service sont isolés des autres services.

Malgré ces avantages, cette architecture complique la cohérence des données interservices. Les garanties de base de données traditionnelles comme ACID ne sont pas directement applicables à plusieurs magasins de données gérés indépendamment. En raison de ces limitations, les architectures qui s’appuient sur la communication interprocesseur ou les modèles transactionnels traditionnels tels que le protocole de validation en deux phases sont souvent mieux adaptées au modèle Saga.

Solution

Le patron Saga gère les transactions en les décomposant en une séquence de transactions locales.

Chaque transaction locale :

1. Exécute son travail de manière atomique dans un seul service.
2. Met à jour la base de données du service.
3. Lance la transaction suivante via un événement ou un message.

En cas d’échec d’une transaction locale, la saga effectue une série de transactions de compensation pour inverser les modifications apportées aux transactions locales précédentes.

Concepts clés dans le modèle Saga

• transactions compensables peuvent être annulées ou compensées par d’autres transactions ayant l’effet inverse. Si une étape de la saga échoue, les transactions de compensation annulent les modifications apportées par les transactions compensables.

• Les transactions pivots servent de point de non-retour dans la saga. Une fois qu’une transaction pivot réussit, les transactions compensables ne sont plus pertinentes. Toutes les actions suivantes doivent être effectuées pour que le système atteigne un état final cohérent. Une transaction pivot peut jouer différents rôles, en fonction du flux de la saga :

  • transactions irréversibles ou noncompensables ne peuvent pas être annulées ni retentées.

  • La frontière entre réversible et validé signifie que la transaction pivot peut être la dernière transaction annulable ou compensable. Ou il peut s’agir de la première opération pouvant être retentée dans la saga.

• Les transactions pouvant faire l’objet d’une nouvelle tentative suivent la transaction pivot. Les transactions pouvant faire l’objet de nouvelles tentatives sont idempotentes et contribuent à garantir que la saga peut atteindre son état final, même si des échecs temporaires se produisent. Ils aident la saga finalement à atteindre un état cohérent.

Approches d’implémentation de Saga

Les deux approches typiques de mise en œuvre du modèle Saga sont la chorégraphie et l’orchestration. Chaque approche a son propre ensemble de défis et de technologies pour coordonner le flux de travail.

Chorégraphie

Dans l’approche chorégraphique, les services échangent des événements sans contrôleur centralisé. Avec la chorégraphie, chaque transaction locale publie des événements de domaine qui déclenchent des transactions locales dans d’autres services.

Avantages de la chorégraphie	Inconvénients de la chorégraphie
Convient pour les flux de travail simples qui ont peu de services et n’ont pas besoin d’une logique de coordination.	Le flux de travail peut être déroutant lorsque vous ajoutez de nouvelles étapes. Il est difficile de suivre les commandes auxquelles chaque participant de saga répond.
Aucun autre service n’est nécessaire pour la coordination.	Il y a un risque de dépendance cyclique entre les participants d’une saga parce qu’ils doivent consommer les commandes des uns des autres.
N’introduit pas de point de défaillance unique, car les responsabilités sont réparties entre les participants de la saga.	Les tests d’intégration sont difficiles, car tous les services doivent s’exécuter pour simuler une transaction.

Orchestration

Dans l’orchestration, un contrôleur centralisé ou orchestrateur, gère toutes les transactions et indique aux participants quelle opération effectuer en fonction des événements. L’orchestrateur exécute des demandes de la saga, stocke et interprète les états de chaque tâche, et gère la récupération en cas de défaillance à l’aide de transactions de compensation.

Avantages de l’orchestration	Inconvénients de l’orchestration
Mieux adapté aux flux de travail complexes ou lorsque vous ajoutez de nouveaux services.	Une autre complexité de conception nécessite une implémentation d’une logique de coordination.
Évite les dépendances cycliques, car l’orchestrateur gère le flux.	Introduit un point de défaillance, car l’orchestrateur gère le flux de travail complet.
La séparation claire des responsabilités simplifie la logique de service.

Problèmes et considérations

Tenez compte des points suivants lorsque vous décidez comment implémenter ce modèle :

• Changement de paradigme de conception : L’adoption du patron Saga nécessite un état d’esprit différent. Il vous oblige à vous concentrer sur la coordination des transactions et la cohérence des données sur plusieurs microservices.

• Complexité du débogage des sagas : Le débogage des sagas peut être complexe, en particulier à mesure que le nombre de services participants augmente.

• Modifications irréversibles de la base de données locale : Les données ne peuvent pas être annulées, car les participants de la saga valident leurs modifications dans leur base de données respective.

• Gestion des défaillances temporaires et de l’idempotence : le système doit gérer efficacement les défaillances temporaires et garantir l’idempotence, lors de la répétition de la même opération ne modifie pas le résultat. Pour plus d’informations, consultez le modèle de consommateur idempotent.

• Nécessité de surveiller et de suivre les sagas : La surveillance et le suivi du déroulement d’une saga sont essentiels pour assurer la supervision opérationnelle.

• Limitations des transactions de compensation : transactions de compensation peuvent ne pas toujours réussir, ce qui peut laisser le système dans un état incohérent.

Anomalies potentielles des données dans les sagas

Les anomalies de données sont des incohérences qui peuvent se produire lorsque des sagas opèrent sur plusieurs services. Étant donné que chaque service gère ses propres données, appelées données des participants, il n’existe aucune isolation intégrée entre les services. Cette configuration peut entraîner des incohérences de données ou des problèmes de durabilité, tels que des mises à jour partiellement appliquées ou des conflits entre services. Les problèmes classiques sont les suivants :

• Mises à jour perdues : Lorsqu’une saga modifie des données sans tenir compte des changements apportés par une autre saga, cela entraîne des mises à jour écrasées ou manquantes.

• Lectures sales : lorsqu’une saga ou une transaction lit des données qu’une autre saga a modifiées, alors que cette modification n’est pas encore terminée.

• Lectures floues, ou non répétables : Lorsque différentes étapes d’une saga lisent des données incohérentes parce que des mises à jour surviennent entre les lectures.

Stratégies de résolution des anomalies de données

Pour réduire ou empêcher ces anomalies, tenez compte des contre-mesures suivantes :

• verrou sémantique : utiliser des verrous au niveau de l’application lorsque la transaction compensable d’une saga utilise un sémaphore pour indiquer qu’une mise à jour est en cours.

• mises à jour commutatives : mises à jour de conception afin qu’elles puissent être appliquées dans n’importe quel ordre tout en produisant le même résultat. Cette approche permet de réduire les conflits entre sagas.

• Vue pessimiste : réorganiser la séquence de la saga afin que les mises à jour des données se produisent dans des transactions retentables pour éliminer les lectures incorrectes. Sinon, une saga pourrait lire des données incorrectes ou modifications non validées, tandis qu’une autre saga effectue simultanément une transaction compensable pour restaurer ses mises à jour.

• valeurs de relecture : Confirmer que les données restent inchangées avant d’effectuer des mises à jour. Si les données changent, arrêtez l’étape actuelle et redémarrez la saga si nécessaire.

• Fichiers de version : conserver un journal de toutes les opérations effectuées sur un enregistrement et s’assurer qu’elles sont effectuées dans la séquence appropriée pour éviter les conflits.

• Contrôle de concurrence fondé sur le risque en fonction de la valeur : Choisissez dynamiquement le mécanisme de contrôle de concurrence approprié en fonction du risque métier potentiel. Par exemple, utilisez des sagas pour les mises à jour à faible risque et les transactions distribuées pour les mises à jour à haut risque.

Quand utiliser ce modèle

Utilisez ce modèle quand :

• Vous devez garantir la cohérence des données dans un système distribué sans couplage serré.
• Vous devez annuler ou compenser si l’une des opérations de la séquence échoue.

Ce modèle peut ne pas convenir lorsque :

• Les transactions sont étroitement couplées.
• Les transactions de compensation se produisent dans les participants antérieurs.
• Il existe des dépendances cycliques.

Étape suivante

• modèles de données natifs cloud

Ressources associées

Les modèles suivants peuvent être pertinents lorsque vous implémentez ce modèle :

• Le modèle chorégraphie a chaque composant du système à participer au processus décisionnel sur le flux de travail d’une transaction métier, au lieu de s’appuyer sur un point central de contrôle.

• Le modèle de transaction de compensation annule le travail exécuté par une série d’étapes et définit à terme une opération cohérente si une ou plusieurs étapes échouent. Les applications hébergées dans le cloud qui implémentent des processus métier et des flux de travail complexes suivent souvent ce modèle de cohérence .

• Le modèle de nouvelle tentative permet à une application de gérer les défaillances temporaires lorsqu’elle tente de se connecter à une ressource de service ou réseau en réessayant de manière transparente l’opération ayant échoué. Ce modèle peut améliorer la stabilité de l’application.

• Le modèle Circuit Breaker gère les défaillances dont la récupération peut prendre un temps variable lors de la connexion à un service ou une ressource distants. Ce modèle peut améliorer la stabilité et la résilience d’une application.

• Le modèle Supervision de point de terminaison d’intégrité implémente des contrôles fonctionnels dans une application à laquelle des outils externes peuvent accéder par le biais de points de terminaison exposés à intervalles réguliers. Ce modèle peut vous aider à vérifier que les applications et services fonctionnent correctement.