Resumen del artículo: Sagas

Feb 16 2023

H. García-Molina y K.

Foto de Nathan Riley en Unsplash

H. García-Molina y K. Salem. 1987. Sagas . En Actas de la conferencia internacional ACM SIGMOD de 1987 sobre gestión de datos (SIGMOD '87). Association for Computing Machinery, Nueva York, NY, EE. UU., 249–259.

Palabras clave: Procesos de larga ejecución, Sagas, Transacciones, Compensación, Mitigación de fallas, Tolerancia a fallas, Transparencia de fallas

Aunque el artículo original sobre Sagas se escribió hace 35 años, el problema sigue siendo igual de relevante en la actualidad. Esta publicación explora los orígenes del concepto de Sagas, procesos de larga ejecución que abarcan múltiples transacciones de bases de datos.

Introducción

En su artículo Sagas, Héctor García-Molina y Kenneth Salem introducen el concepto de sagas para implementar operaciones de “ejecución prolongada”.

Molina y Salem se refieren a los procesos que consisten en un solo paso como procesos de "ejecución corta" o "de corta duración" y a los procesos que consisten en varios pasos como "de ejecución prolongada" o "de larga duración". Por lo tanto, de ejecución corta o de ejecución prolongada no es una afirmación sobre el tiempo físico, sino una afirmación sobre el tiempo lógico en el que cada paso es un tictac del reloj (Figura 1).

Figura 1 De ejecución corta y de ejecución prolongada

El problema

En un ecosistema que rechaza en gran medida la idea de las transacciones distribuidas o la retención de bloqueos durante un período prolongado, cualquier proceso de ejecución prolongada no puede asignarse simplemente a una transacción distribuida de ejecución prolongada. En cambio, necesitamos un mecanismo diferente para componer procesos de ejecución prolongada a partir de transacciones no distribuidas de ejecución corta.

El documento define un proceso P como una secuencia de pasos a, b, etc., donde cada paso es una transacción de base de datos. Para usar términos más familiares, puede pensar en un proceso como una función y la secuencia de pasos como una secuencia de llamadas API a la base de datos.

Nos referimos a la secuencia de pasos a, b, etc como una traza:

trace(P) = a • b • …

En otras palabras: ¡una secuencia de dos transacciones no es una transacción!

Figura 2. La composición secuencial de dos transacciones no es en sí misma una transacción.

Trivialmente, si un proceso consta de una sola transacción, el proceso exhibe las garantías de atomicidad de una transacción (Figura 3).

Figura 3. Un proceso P consta de un paso a

Sin embargo, si un proceso consta de múltiples transacciones, el proceso no exhibe las garantías de atomicidad de una transacción: el proceso puede ejecutarse parcialmente (Figura 4).

Figura 4. Un proceso P consta de dos pasos a y b

Sin embargo, a diferencia de otras transacciones, las transacciones de un proceso están relacionadas y deben ejecutarse como una unidad; cualquier ejecución parcial de un proceso no es deseable.

El documento analiza una aplicación de reserva de viajes, donde un viaje consta de múltiples vuelos potencialmente en diferentes aerolíneas. Aquí, reservar un viaje implica múltiples transacciones, una por tramo de viaje. Como viajeros, queremos que todas las transacciones se ejecuten como una unidad: queremos reservar todos los vuelos o ninguno, reservar algunos vuelos es inaceptable.

La solución

El documento presenta Sagas, un protocolo para implementar procesos de ejecución prolongada. El protocolo Saga asegura que un proceso es atómico, es decir, un proceso se ejecuta de forma observable equivalente a completamente o no se ejecuta en absoluto.

Figura 5. Recuperación hacia atrás y hacia adelante

Para mitigar la ejecución parcial, un proceso puede implementar una recuperación hacia adelante o hacia atrás [2]:

Recuperación hacia adelante

La recuperación de fallas hacia adelante se refiere a las estrategias de mitigación de fallas que hacen que el sistema pase del estado intermedio a un estado que es equivalente al estado final (hacer avanzar el proceso).

Recuperación hacia atrás

La recuperación de fallas hacia atrás se refiere a las estrategias de mitigación de fallas que hacen que el sistema pase del estado intermedio a un estado equivalente al estado inicial (haciendo retroceder el proceso).

Recuperación hacia atrás y compensación

Para habilitar la recuperación hacia atrás, cada proceso debe registrar un paso de compensación para cada paso (Figura 6).

Figura 6. Transacción sᵢ & Compensación cᵢ

El paso de compensación deshace, desde un punto de vista semántico, el paso, pero no necesariamente devuelve la base de datos al estado que existía cuando comenzó el paso. La compensación restaurará el mundo a un estado que es una aproximación aceptable al estado que tenía antes del inicio de la transacción.

Por ejemplo, volviendo a la aplicación de reserva de viajes, si un viaje consta de dos vuelos y la reserva del primer vuelo fue exitosa pero la reserva del segundo falló, la saga necesita cancelar la primera reserva para devolver la base de datos a una aproximación aceptable al estado tenía antes del inicio de la reserva del viaje.

Ejecución

Entonces, en ausencia de falla, un proceso P produce la traza deseada

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

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

Cuando una falla interrumpe un Saga, un Saga debe poder recuperar su estado actual y realizar una recuperación hacia adelante o hacia atrás. Por lo tanto, una Saga debe poder registrar el comienzo de una Saga, la finalización de una Saga y registrar puntos de control y compensaciones.

Si es el propietario de la base de datos, puede registrar puntos de control y compensaciones transaccionales con cada paso. Si no puede registrar los puntos de control y las compensaciones de manera transaccional con cada paso, debe diseñar un mecanismo para registrar las compensaciones de los puntos de control de manera confiable.

Discusión

Aunque el documento fue escrito hace más de 35 años, el problema y Sagas como la solución propuesta siguen siendo relevantes hoy en día. Sin embargo, la atención se ha desplazado de la composición de transacciones de bases de datos a la composición de invocaciones de servicios.

Tenga en cuenta que los servicios no exhiben propiedades transaccionales: los servicios pueden no ser atómicos, después de una invocación de servicio, y si el servicio falla, es posible que no sepa si el servicio tuvo efecto o no.

Por lo tanto, debe registrar una acción de compensación antes de invocar un servicio y diseñar la lógica de compensación para que sea correcta, ya sea que el servicio tenga efecto o no.

Conclusión

Las sagas siguen siendo relevantes, a pesar de los avances significativos en la teoría y la práctica desde la publicación del artículo. El concepto básico de Saga como protocolo para implementar atomicidad en un entorno distribuido a través de transacciones o servicios, las técnicas descritas en el documento continúan siendo ampliamente utilizadas en la actualidad.