El patrón Saga como forma de garantizar la coherencia de los datos

Hola. Ya en OTUS está abriendo un set para un nuevo grupo del curso "Highload Architect" . En este sentido, continúo con una serie de mis publicaciones escritas específicamente para este curso, y también lo invito a mi lección de demostración gratuita sobre el tema: "Índices en MySQL: mejores prácticas y trampas". Puede inscribirse en el seminario web aquí .










Introducción



Como saben, la transición de una arquitectura monolítica a una de microservicio provoca una serie de dificultades asociadas tanto con la parte técnica del proyecto como con el factor humano. Uno de los desafíos técnicos más difíciles es garantizar la coherencia en un sistema distribuido.



La última vez, discutimos las causas de los problemas de coherencia en una arquitectura de microservicio, el enfoque optimista de la coherencia y la coherencia mediante un compromiso de dos fases.



Patrón de saga



Saga es un mecanismo para garantizar la coherencia de los datos en una arquitectura de microservicio sin utilizar transacciones distribuidas.



Para cada comando del sistema que necesite actualizar datos en varios servicios, se crea una saga. La saga es una especie de "lista de verificación" que consta de transacciones ACID locales secuenciales, cada una de las cuales actualiza datos en un servicio. Se aplica una transacción de compensación para manejar fallas. Dichas transacciones se ejecutan en caso de falla en todos los servicios en los que las transacciones locales se han completado con éxito.



Hay varios tipos de transacciones en la saga, hasta cuatro:



  • Compensación: cancela un cambio realizado por una transacción local.
  • Una compensación es una transacción que debe compensarse (revertirse) en caso de que las transacciones posteriores fallen.
  • Giro: una transacción que determina el éxito de toda la saga. Si tiene éxito, entonces se garantiza que la saga llegará al final.
  • Repetible: va tras el pivote y se garantiza que tendrá éxito.


Puedes organizar una saga usando coreografía u orquestación.



En el caso de la saga coreográfica, no hay un orquestador dedicado. Usando el servicio de pedidos y los usuarios como ejemplo, podría verse así: el servicio de pedidos recibe una solicitud y crea un pedido en el estado PENDIENTE, y luego publica el evento "Pedido creado". Un controlador de eventos en el servicio de usuario procesa este evento, intenta reservar un elemento y publica el resultado como un evento. El servicio de pedidos procesa este evento, confirmando o cancelando el pedido en función del resultado leído.



La saga orquestada parece un poco más interesante. Usando los servicios anteriores como ejemplo, podría verse así: el servicio de pedidos recibe una solicitud, crea una saga que crea un pedido en el estado PENDIENTE y luego envía un comando para reservar bienes para el servicio del usuario. El servicio al usuario intenta reservar el producto y envía un mensaje de respuesta indicando el resultado. La saga aprueba o cancela el pedido.



El patrón de saga permite que una aplicación mantenga la consistencia de datos en múltiples servicios sin usar transacciones distribuidas (confirmaciones de dos fases) y evitando los problemas discutidos en el artículo anterior. Pero, por otro lado, el modelo de programación es muy complicado: por ejemplo, el desarrollador de cada transacción debe escribir una transacción de compensación que revierte los cambios realizados anteriormente dentro de la saga.



La saga nos permite lograr un modelo ACD (Atomicidad + Consistencia + Durabilidad en términos ACID), pero perdimos una letra. La falta de la letra I conduce a los conocidos problemas de falta de aislamiento. Estos incluyen: actualizaciones perdidas: una saga sobrescribe los cambios realizados por otra sin leerlos, lecturas sucias: una transacción o saga lee actualizaciones inacabadas de otra saga, difusas / lecturas no repetibles): dos etapas diferentes de la saga leen los mismos datos, pero obtienen resultados diferentes porque otra saga hizo cambios. Hay una serie de patrones que permiten corregir determinadas anomalías: bloqueo semántico, actualizaciones conmutativas, representación pesimista, relectura de un valor, archivo de cambios y por valor.La cuestión de garantizar el aislamiento permanece abierta.



Otro tema interesante es la imposibilidad de actualizar la base de datos de forma atómica y publicar un mensaje al corredor de mensajes para desencadenar más pasos en la saga.



Conclusión



Hablamos sobre las formas de organizar una saga utilizando coreografía y orquestación, así como los problemas que conlleva este patrón. A continuación, hablaremos sobre las formas de solucionar algunas anomalías y enviar mensajes transaccionalmente al agente de mensajes.






All Articles