Résumé de l'article : Sagas

Feb 16 2023

H. Garcia-Molina et K.

Photo de Nathan Riley sur Unsplash

H. Garcia-Molina et K. Salem. 1987. Sagas . Dans Actes de la conférence internationale ACM SIGMOD de 1987 sur la gestion des données (SIGMOD '87). Association pour les machines informatiques, New York, NY, États-Unis, 249–259.

Mots-clés : processus de longue durée, sagas, transactions, compensation, atténuation des défaillances, tolérance aux défaillances, transparence des défaillances

Bien que l'article original sur les sagas ait été écrit il y a 35 ans, le problème est toujours aussi pertinent aujourd'hui. Cet article explore les origines du concept de Sagas, des processus de longue durée qui s'étendent sur plusieurs transactions de base de données.

Introduction

Dans leur article Sagas, Hector Garcia-Molina et Kenneth Salem introduisent le concept de sagas pour mettre en œuvre des opérations « de longue durée ».

Molina et Salem qualifient les processus constitués d'une seule étape de processus « de courte durée » ou de « courte durée » et les processus constitués de plusieurs étapes de « longue durée » ou de « longue durée de vie ». Par conséquent, l'exécution courte ou longue n'est pas une déclaration sur le temps physique mais une déclaration sur le temps logique, chaque étape étant un tic d'horloge (Figure 1).

Figure 1 Court et long terme

Le problème

Dans un écosystème qui rejette largement l'idée de transactions distribuées ou de maintien de verrous pendant une période prolongée, tout processus de longue durée ne peut pas simplement être mappé à une transaction distribuée de longue durée. Au lieu de cela, nous avons besoin d'un mécanisme différent pour composer des processus de longue durée à partir de transactions de courte durée et non distribuées.

L'article définit un processus P comme une séquence d'étapes a, b, etc., où chaque étape est une transaction de base de données. Pour utiliser des termes plus familiers, vous pouvez considérer un processus comme une fonction et la séquence d'étapes comme une séquence d'appels d'API vers la base de données.

Nous nous référons à la séquence des étapes a, b, etc comme une trace :

trace(P) = a • b • …

En d'autres termes : une séquence de deux transactions n'est pas une transaction !

Figure 2. La composition séquentielle de deux transactions n'est pas en soi une transaction.

Trivialement, si un processus consiste en une seule transaction, le processus présente les garanties d'atomicité d'une transaction (Figure 3).

Figure 3. Un processus P consiste en une étape a

Cependant, si un processus se compose de plusieurs transactions, le processus ne présente pas les garanties d'atomicité d'une transaction : le processus peut s'exécuter partiellement (Figure 4).

Figure 4. Un processus P se compose de deux étapes a et b

Cependant, contrairement aux autres transactions, les transactions d'un processus sont liées et doivent être exécutées comme une unité, toute exécution partielle d'un processus n'est pas souhaitable.

Le document traite d'une application de réservation de voyage, où un voyage se compose de plusieurs vols potentiellement sur différentes compagnies aériennes. Ici, la réservation d'un voyage implique plusieurs transactions, une par étape de voyage. En tant que voyageurs, nous voulons que toutes les transactions soient exécutées comme une unité : soit nous voulons réserver tous les vols, soit aucun vol, réserver certains vols est inacceptable.

La solution

L'article présente Sagas, un protocole pour la mise en œuvre de processus de longue durée. Le protocole Saga garantit qu'un processus est atomique, c'est-à-dire qu'un processus s'exécute de manière observable équivalente à complètement ou pas du tout.

Figure 5. Récupération en amont et en aval

Pour atténuer l'exécution partielle, un processus peut implémenter une récupération avant ou arrière [2] :

Récupération vers l'avant

La reprise après échec fait référence aux stratégies d'atténuation des échecs qui font passer le système de l'état intermédiaire à un état équivalent à l'état final (faire avancer le processus).

Récupération en arrière

La récupération après défaillance fait référence aux stratégies d'atténuation des défaillances qui font passer le système de l'état intermédiaire à un état équivalent à l'état initial (recul du processus).

Récupération et compensation en amont

Pour activer la récupération en amont, chaque processus doit enregistrer une étape de compensation pour chaque étape (Figure 6).

Figure 6. Transaction sᵢ & Compensation cᵢ

L'étape de compensation annule — d'un point de vue sémantique — l'étape, mais ne ramène pas nécessairement la base de données à l'état qui existait au début de l'étape. La compensation restaurera le monde dans un état qui est une approximation acceptable de l'état qu'il avait avant le début de la transaction.

Par exemple, pour revenir à l'application de réservation de voyage, si un voyage se compose de deux vols et que la réservation du premier vol a réussi mais que la réservation du deuxième vol a échoué, la saga doit annuler la première réservation pour ramener la base de données à une approximation acceptable de l'état il avait avant le début de la réservation du voyage.

Exécution

Donc en l'absence d'échec, un processus P produit la trace désirée

trace(P) = s₁ • s₂ • … sₙ • ✔️

trace(P) = s₁ • s₂ • … sᵢ • × • cᵢ … • c₂ • c₁ • ✔️

Lorsqu'une panne interrompt une saga, une saga doit être capable de récupérer son état actuel et d'effectuer une récupération en avant ou en arrière. Par conséquent, une saga doit être capable d'enregistrer le début d'une saga, l'achèvement d'une saga, et d'enregistrer des points de contrôle et des compensations.

Si vous possédez la base de données, vous pouvez enregistrer des points de contrôle et des compensations de manière transactionnelle à chaque étape. Si vous ne pouvez pas enregistrer les points de contrôle et les compensations de manière transactionnelle à chaque étape, vous devez concevoir un mécanisme pour enregistrer les compensations des points de contrôle de manière fiable.

Discussion

Bien que l'article ait été écrit il y a plus de 35 ans, le problème et Sagas en tant que solution proposée sont toujours d'actualité. Cependant, l'attention s'est déplacée de la composition des transactions de base de données vers la composition des invocations de service.

Gardez à l'esprit que les services ne présentent pas de propriétés transactionnelles : les services peuvent ne pas être atomiques, après un appel de service, et si le service plante, vous ne pouvez pas savoir si le service a pris effet ou non.

Par conséquent, vous devez enregistrer une action de compensation avant d'invoquer un service et concevoir une logique de compensation correcte, que le service ait pris effet ou non.

Conclusion

Les sagas restent pertinentes, malgré des avancées significatives en théorie et en pratique depuis la publication de l'article. Le concept de base d'une saga en tant que protocole de mise en œuvre de l'atomicité dans un environnement distribué à travers des transactions ou des services, les techniques décrites dans le document continuent d'être largement utilisées aujourd'hui.