Patrón de transacciones distribuidas de Saga

Azure

Mantenga la coherencia de los datos en los sistemas distribuidos mediante la coordinación de una secuencia de transacciones locales en varios servicios. Cada servicio realiza su operación y desencadena el siguiente paso a través de eventos o mensajes. Si se produce un error en un paso, una serie de transacciones de compensación deshace los cambios realizados en los pasos completados.

Contexto y problema

Una transacción representa una unidad de trabajo, que puede incluir varias operaciones. Dentro de una transacción, un evento hace referencia a un cambio de estado que afecta a una entidad. Un comando encapsula toda la información necesaria para realizar una acción o desencadenar un evento posterior.

Las transacciones deben cumplir los principios de atomicidad, coherencia, aislamiento y durabilidad (ACID).

  • Atomicidad: Todas las operaciones tienen éxito o ninguna tiene éxito.
  • Coherencia: Los datos pasan de un estado válido a otro estado válido.
  • Aislamiento: las transacciones simultáneas producen los mismos resultados que las transacciones secuenciales.
  • Durabilidad: Los cambios persisten una vez confirmados, incluso cuando se producen fallos.

En un único servicio, las transacciones siguen los principios ACID porque funcionan dentro de una base de datos única. Sin embargo, puede ser más complejo garantizar el cumplimiento de ACID entre varios servicios.

Desafíos en las arquitecturas de microservicios

Normalmente, las arquitecturas de microservicios asignan una base de datos dedicada a cada microservicio. Este enfoque proporciona varias ventajas:

  • Cada servicio encapsula sus propios datos.
  • Cada servicio puede usar la tecnología de base de datos y el esquema más adecuados para sus necesidades específicas.
  • Las bases de datos de cada servicio se pueden escalar de forma independiente.
  • Los errores de un servicio están aislados de otros servicios.

A pesar de estas ventajas, esta arquitectura complica la coherencia de los datos entre servicios. Las garantías de base de datos tradicionales, como ACID, no se aplican directamente a varios almacenes de datos administrados de forma independiente. Debido a estas limitaciones, las arquitecturas que se basan en la comunicación entre procesos o los modelos de transacción tradicionales, como el protocolo de confirmación en dos fases, suelen ser más adecuados para el patrón Saga.

Solución

El patrón Saga administra las transacciones dividiéndolas en una secuencia de transacciones locales.

Diagrama que muestra una introducción a la saga.

Cada transacción local:

  1. Completa su trabajo de forma atómica dentro de un único servicio.
  2. Actualiza la base de datos del servicio.
  3. Inicia la siguiente transacción a través de un evento o mensaje.

Si una transacción local falla, la saga realiza una serie de transacciones de compensación para revertir los cambios que realizaron las transacciones locales anteriores.

Conceptos clave en el patrón Saga

  • Transacciones compensables pueden deshacerse o compensarse mediante otras transacciones con el efecto opuesto. Si se produce un error en un paso de la saga, las transacciones compensatorias deshacen los cambios realizados en las transacciones compensables.

  • Las transacciones pivote constituyen el punto de no retorno en la saga. Una vez que una transacción pivote se completa correctamente, las transacciones compensables dejan de ser relevantes. Todas las acciones posteriores deben completarse para que el sistema logre un estado final coherente. Una transacción pivote puede desempeñar diferentes roles, dependiendo del flujo de la saga:

    • transacciones irreversibles o no compensables no se pueden deshacer ni reintentar.

    • El límite entre reversible y confirmada significa que la transacción pivote puede ser la última transacción reversible o compensable. O puede ser la primera operación reintentable de la saga.

  • Transacciones reintentables siguen la transacción pivote. Las transacciones reintentables son idempotentes y ayudan a garantizar que la saga pueda alcanzar su estado final, incluso si se producen fallos temporales. Ayudan a la saga a alcanzar con el tiempo un estado coherente.

Enfoques de implementación de Saga

Los dos enfoques típicos de implementación de saga son coreografía y orquestación. Cada enfoque tiene su propio conjunto de desafíos y tecnologías para coordinar el flujo de trabajo.

Coreografía

En el enfoque de coreografía, los servicios intercambian eventos sin un controlador centralizado. Con la coreografía, cada transacción local publica eventos de dominio que desencadenan transacciones locales en otros servicios.

Diagrama que muestra una saga mediante la coreografía.

Ventajas de la coreografía Desventajas de la coreografía
Adecuado para flujos de trabajo simples que tienen pocos servicios y no necesitan una lógica de coordinación. El flujo de trabajo puede resultar confuso al agregar nuevos pasos. Es difícil seguir a qué comandos responde cada participante en la saga.
No se requiere ningún otro servicio para la coordinación. Existe un riesgo de dependencia cíclica entre los participantes de la saga porque tienen que consumir los comandos entre sí.
No introduce un único punto de error porque las responsabilidades se distribuyen entre los participantes de la saga. Las pruebas de integración son difíciles porque todos los servicios deben ejecutarse para simular una transacción.

Orquestación

En orquestación, un controlador centralizado o orquestador, controla todas las transacciones e indica a los participantes qué operación realizar en función de los eventos. El orquestador realiza solicitudes dentro de una saga, almacena e interpreta los estados de cada tarea y gestiona la recuperación ante fallos mediante el uso de transacciones compensatorias.

Diagrama que muestra una saga mediante orquestación.

Ventajas de la orquestación Desventajas de la orquestación
Más adecuado para flujos de trabajo complejos o cuando se agregan nuevos servicios. Otra complejidad de diseño requiere una implementación de una lógica de coordinación.
Evita las dependencias cíclicas porque el orquestador administra el flujo. Presenta un punto de error porque el orquestador administra el flujo de trabajo completo.
La separación clara de responsabilidades simplifica la lógica del servicio.

Problemas y consideraciones

Tenga en cuenta los siguientes puntos a medida que decida cómo implementar este patrón:

  • Cambio en el pensamiento de diseño: Adoptar el patrón Saga requiere una mentalidad diferente. Requiere que se centre en la coordinación de transacciones y la coherencia de los datos en varios microservicios.

  • Complejidad de las sagas de depuración: Sagas de depuración pueden ser complejas, específicamente a medida que crece el número de servicios participantes.

  • Cambios irreversibles en la base de datos local: Los datos no se pueden revertir porque los participantes de la saga confirman los cambios en sus respectivas bases de datos.

  • Control de errores transitorios e idempotencia: El sistema debe controlar los errores transitorios de forma eficaz y garantizar la idempotencia, al repetir la misma operación no modifica el resultado. Para obtener más información, vea procesamiento de mensajes idempotentes.

  • Necesidad de supervisar y hacer seguimiento de las sagas: La supervisión y el seguimiento del flujo de trabajo de las sagas son tareas esenciales para mantener la supervisión operativa.

  • Limitaciones de las transacciones de compensación: es posible que transacciones de compensación no siempre se realicen correctamente, lo que puede dejar el sistema en un estado incoherente.

Posibles anomalías de datos en las sagas

Las anomalías de datos son incoherencias que pueden producirse cuando las sagas operan en varios servicios. Dado que cada servicio administra sus propios datos, denominados datos de participantes, no hay aislamiento integrado entre los servicios. Esta configuración puede dar lugar a incoherencias de datos o problemas de durabilidad, como actualizaciones aplicadas parcialmente o conflictos entre servicios. Entre los problemas típicos se incluyen:

  • Actualizaciones perdidas: Cuando una saga modifica los datos sin tener en cuenta los cambios realizados por otra saga, resulta en actualizaciones sobrescritas o que faltan.

  • Lecturas sucias: Cuando una saga o transacción lee datos que otra saga ha modificado, pero la modificación no se ha completado.

  • Lecturas difusas, o no repetibles: Cuando distintos pasos de una saga leen datos incoherentes porque se producen actualizaciones entre las lecturas.

Estrategias para abordar anomalías de datos

Para reducir o evitar estas anomalías, tenga en cuenta las siguientes contramedidas:

  • Bloqueo semántico: Use bloqueos a nivel de aplicación cuando una transacción compensable de una saga emplee un semáforo para indicar que una actualización está en curso.

  • actualizaciones conmutantes: Actualizaciones de diseño para que se puedan aplicar en cualquier orden mientras se produce el mismo resultado. Este enfoque ayuda a reducir los conflictos entre sagas.

  • Visión pesimista: Reordenar la secuencia de la saga de modo que las actualizaciones de datos se produzcan en transacciones reintentables para eliminar las lecturas sucias. De lo contrario, una saga podría leer datos sucios o cambios no confirmados, mientras que otra saga realiza simultáneamente una transacción compensable para revertir sus actualizaciones.

  • Volver a leer los valores: Confirme que los datos permanecen sin cambios antes de hacer actualizaciones. Si cambian los datos, detenga el paso actual y reinicie la saga según sea necesario.

  • Archivos de versión: Mantener un registro de todas las operaciones realizadas en un registro y asegurarse de que se realizan en la secuencia correcta para evitar conflictos.

  • simultaneidad basada en riesgos en función del valor: elegir dinámicamente el mecanismo de simultaneidad adecuado en función del riesgo empresarial potencial. Por ejemplo, use sagas para actualizaciones de bajo riesgo y transacciones distribuidas para actualizaciones de alto riesgo.

Cuándo usar este patrón

Use este patrón cuando:

  • Debe garantizar la coherencia de los datos en un sistema distribuido sin acoplamiento estricto.
  • Debe revertir o compensar si se produce un error en una de las operaciones de la secuencia.

Este patrón podría no ser adecuado cuando:

  • Las transacciones están estrechamente acopladas.
  • Las transacciones de compensación se producen en participantes anteriores.
  • Hay dependencias cíclicas.

Paso siguiente

Los patrones siguientes pueden ser relevantes al implementar este patrón:

  • El patrón de coreografía hace que cada componente del sistema participe en la toma de decisiones sobre el flujo de trabajo de una transacción empresarial, en lugar de depender de un punto central de control.

  • El patrón Compensating Transaction pattern deshace el trabajo realizado por una serie de pasos y, en última instancia, define una operación consistente si uno o varios pasos fallan. Las aplicaciones hospedadas en la nube que implementan flujos de trabajo y procesos empresariales complejos suelen seguir este modelo de coherencia final .

  • El patrón Reintento permite a una aplicación controlar errores transitorios cuando intenta conectarse a un servicio o recurso de red mediante la reintento transparente de la operación con errores. Este patrón puede mejorar la estabilidad de la aplicación.

  • El patrón Circuit Breaker controla los errores que tardan una cantidad variable de tiempo en recuperarse cuando se conecta a un servicio remoto o recurso. Este patrón puede mejorar la estabilidad y la resistencia de una aplicación.

  • El patrón de supervisión de puntos de conexión de estado implementa comprobaciones funcionales en una aplicación, a las que las herramientas externas pueden acceder a través de puntos de conexión expuestos a intervalos regulares. Este patrón puede ayudarle a comprobar que las aplicaciones y los servicios funcionan correctamente.