Introducción del patrón SAGA

Sesión 5: 3h21m

Transacciones en un sistema distribuido

• Consistencia de los datos
• Las transacciones son el enfoque tradicional
• Transacciones del sistema monolítico
• Base de datos única, que es la única verdad
• Transacciones de microservicios
• Arquitectura distribuida
• Datos distribuidos
• Transacciones distribuidas
• Teorema de CAP
• La falla de la red sucederá
• Disponibilidad de datos o consistencia de datos

Opciones disponibles a nivel de transaccionalidad

• Transacciones ACID tradicionales
• Atomicidad, consistencia, aislamiento y durabilidad.
• Patrón de confirmación de dos fases (2PC)
• ACID es obligatorio
• Teorema CAP: Elección de consistencia.
• Patrón SAGA
• Atomicidad por disponibilidad y consistencia.
• Para sistemas distribuidos
• Patrón de consistencia eventual
• ACID
• Teorema CAP: Elección de disponibilidad.

Confirmación de 2 fases (Two Phase Commit / 2PC)

Lograr transacciones ACID en sistema distribuido.

• Patrón para transacciones distribuidas
• El administrador de transacciones maneja la transacciones
• Fase de preparación
• El gestor de transacciones notifica el inicio de preparación
• Fase de confirmación
• El gestor de transacciones recibe las confirmaciones.
• Gestor de transacciones
• Emite un Commit en caso todos hayan confirmado.
• Emite un Rollback en caso uno no haya confirmado.

• Advertencias
• Confianza en un administrador de transacciones
• Sin respuesta de confirmación
• Fallar después de una confirmación
• Las transacciones pendientes bloquean recursos
• Evitar implementaciones personalizadas
• Tiene problemas de escalado.
• Rendimiento reducido
• ANTIPATRÓN
• Considerar alternativas
• Patrón de Saga
• Consistencia eventual

Contexto

• Con la adopción del patrón "Base de datos por servicio" en la arquitectura de microservicios, significa que cada servicio tiene su propia base de datos.
• Existe un problema sobre cómo garantizar la coherencia de los datos entre los servicios.
• Por ejemplo, está implementando la función Pedido en un proyecto de Compras en línea. Cuando el usuario final realiza un pedido, la aplicación llamará al servicio de Stock para actualizar el número de producto en el stock, luego llamará al servicio de envío para entregar el producto solicitado al usuario final. 

•   ¿Cuál es el problema?
• ¿Qué sucede si la cantidad del producto es menor que la cantidad que pide el usuario final?
• ¿O qué sucede si hay un problema con el servicio de envío (shipping) y la aplicación no puede registrar el envío correctamente?
• Los pedidos, el artículo y el envío están en diferentes bases de datos, por lo que no podemos usar una transacción ACID local. Esa es la razón por la que no se puede usar uno de los tipos de transacciones que se llama "Confirmación de dos fases" - "2PC".
• Las transacciones distribuidas, como el protocolo de confirmación en dos fases (2PC), requieren que todos los participantes de una transacción la confirmen o reviertan antes de que la transacción pueda continuar. No obstante, algunas implementaciones de participantes, como las bases de datos NoSQL y la administración de mensajes, no admiten este modelo.

SAGA

• El patrón de saga proporciona la administración de transacciones mediante una secuencia de transacciones locales. 
• Una transacción local es el esfuerzo del trabajo atómico realizado por un participante de la saga. 
• Cada transacción local actualiza la base de datos y publica un mensaje o evento para desencadenar la siguiente transacción local en la saga. 
• Si se produce un error en una transacción local, la saga ejecuta una serie de transacciones de compensación que deshacen los cambios realizados por las transacciones locales anteriores.
• No existe el rollback en las transacciones distribuidas gestionadas por saga.
• Saga es la gestión de una transacción para mantener la disponibilidad como la consistencia.

• Las transacciones compensables son transacciones que se pueden invertir procesando otra transacción con el efecto opuesto.
• Una transacción dinámica es el punto en el que se debe continuar o no continuar en una saga. Si se confirma la transacción dinámica, la saga se ejecuta hasta su finalización. Una transacción dinámica puede ser una transacción que no es compensable ni reintentable, o puede ser la última transacción compensable o la primera transacción reintentable de la saga. 
• Las transacciones reintentables son transacciones que siguen a la transacción dinámica y que está garantizando que se realizarán correctamente.