¿Entenderá las transacciones distribuidas de esta manera?

Las transacciones distribuidas resuelven principalmente el problema de la coherencia distribuida. Después de todo, la operación distribuida de datos conduce al hecho de que solo las transacciones locales no pueden garantizar la originalidad. A diferencia de la versión independiente de la transacción, la máquina única empaqueta varios comandos en un procesamiento unificado, y la transacción distribuida empaqueta los comandos ejecutados en varias máquinas en un solo comando para el procesamiento unificado.

Escenarios comunes de transacciones distribuidas #

Las transacciones distribuidas están en realidad de nuestro lado, lo ha estado utilizando, pero no le ha prestado atención.

Transferir

Deduzca el saldo de su cuenta y aumente el saldo de la cuenta de otra persona. Si solo deduce su dinero y otros no lo aumentan, es un fracaso; si no deduce su dinero, otros también aumentan la pérdida del banco.

Realizar un pedido / deducir inventario

Este es un escenario muy común en el sistema de comercio electrónico: el usuario realizó un pedido con éxito, pero la tienda no recibió el pedido y no envió el pedido, el usuario canceló el pedido, pero la tienda vio el pedido y entregó la mercancía.

Escenario de subbase de datos y subtabla

Cuando nuestro volumen de datos es grande, podemos implementar muchas bases de datos independientes, pero una de sus lógicas puede operar en muchas tablas de bases de datos al mismo tiempo. En este momento, cómo garantizar que todas las operaciones tengan éxito o fracasen.

Problema de llamada al sistema distribuido

La separación de microservicios permite que cada sistema realice sus funciones, pero también trae mucho dolor. Una operación puede estar acompañada de muchas solicitudes externas. Si un sistema externo cuelga, ¿es necesario revertir la operación anterior? .

En respuesta a los problemas anteriores, las cuatro características principales de la base de datos que hemos aprendido antes: ACID parece ser muy difícil de lograr aquí. En el caso de una sola máquina, también puede controlar los datos a través del mecanismo de bloqueo y registro. ¿Qué pasa con el escenario distribuido? ¿Realización? Bajo diferentes arquitecturas de aplicaciones distribuidas, los aspectos a considerar para implementar una transacción distribuida no son exactamente los mismos, como la coordinación de múltiples recursos y la propagación de transacciones entre servicios. El mecanismo de implementación también es complejo y cambiante. Aunque hay tantos detalles de ingeniería a considerar, el núcleo de las transacciones distribuidas es su función ACID, pero este ACID cambia la escena.

Teoría distribuida #

Teorema de CAP

El modelo ACID tradicional ciertamente no puede resolver los desafíos en un entorno distribuido. Basado en esto, el profesor Eric Brewer de la Universidad de California en Berkeley presentó el teorema CAP. Señaló que los servicios web modernos no pueden satisfacer los siguientes tres atributos al mismo tiempo:

• Coherencia: todos los clientes pueden devolver la última operación.
• Disponibilidad (disponibilidad): los nodos no defectuosos devuelven una respuesta razonable en un tiempo razonable (no una respuesta de error y tiempo de espera).
• Tolerancia de partición: incluso si no se puede usar un solo componente, la operación aún se puede completar.

Hay tres direcciones detrás de la comprensión de la coherencia:

• Fuerte consistencia: los datos escritos más recientemente de ciertos datos se pueden leer en cualquier momento. Todos los procesos en el sistema, vea el orden de las operaciones, son consistentes con el orden bajo el reloj global. En resumen, en cualquier momento, los datos en todos los nodos son los mismos.
• Consistencia débil: una vez que se actualizan los datos, si puede tolerar que el acceso posterior solo se pueda acceder de forma parcial o total, es una consistencia débil.
• Eventualmente consistente: no hay garantía de que el mismo dato en cualquier nodo en cualquier momento sea el mismo, pero con la migración del tiempo, el mismo dato en diferentes nodos siempre cambiará en diferentes direcciones. En pocas palabras, después de un período de tiempo, los datos entre los nodos finalmente alcanzarán un estado consistente.

Con respecto a la diferente comprensión de la coherencia, la implementación de la teoría CAP será diferente más adelante.

Además, el profesor Eric Brewer señaló que los servicios WEB modernos no pueden satisfacer estos tres atributos al mismo tiempo, dijo que no pueden satisfacerlos al mismo tiempo. ¿Por qué?

Si no hay copia en un sistema distribuido, entonces se debe satisfacer una fuerte consistencia y disponibilidad, pero si estos datos caen, no se puede garantizar la disponibilidad.

Si un sistema satisface AP, no se puede garantizar la coherencia. Entonces, la esencia del principio CAP es AP, CP o AC, pero no hay CAP.

Teorema de BASE

Basado en el CAP mencionado anteriormente, no podemos cumplir con el CAP al mismo tiempo de todos modos. El propósito principal de diseñar el sistema es hacerlo correr sin cometer errores. Entonces, ¿es posible no requerir una gran consistencia y finalmente hacerlo consistente? Entonces, el teorema BASE se presentó más tarde:

• Básicamente disponible
• Estado suave
• Eventualmente consistente (eventualmente consistente)

Con base en la complejidad del sistema distribuido a gran escala actual, no podemos garantizar que el servicio siempre llegue a 999, por lo que si es posible elegir, el servicio central llega a 999 y se permite vincular el servicio no central para preservar el servicio central. Además, se permiten inconsistencias temporales en el sistema durante el tiempo de inactividad de los servicios no básicos, pero esta inconsistencia no afecta el uso de las funciones básicas del sistema.

Eventualmente, el sistema se restaura y todos los servicios reparan los datos juntos y finalmente alcanzan un estado consistente.

La industria generalmente se refiere a las transacciones que siguen estrictamente ACID como transacciones rígidas , y las transacciones basadas en la idea BASE se denominan transacciones flexibles . Las transacciones flexibles no abandonan completamente ACID, sino que simplemente relajan los requisitos de coherencia: se sigue estrictamente la coherencia después de que se completa la transacción, y la coherencia en la transacción se puede relajar adecuadamente.

Visualización recomendada: Portal

Esquema común de implementación de transacciones distribuidas #

El esquema de implementación de transacciones distribuidas distingue las transacciones rígidas y las transacciones flexibles del tipo. Transacción rígida: generalmente sin transformación comercial, fuerte consistencia, soporte nativo para reversión / aislamiento, baja concurrencia, adecuado para transacciones cortas. Transacción flexible: transformación empresarial, consistencia final, interfaz de compensación, interfaz de bloqueo de recursos, alta concurrencia, adecuada para transacciones largas.

• Transacción rígida: protocolo XA (2PC, JTA, JTS), 3PC
• Transacción flexible: TCC / FMT, Saga (modo de máquina de estado, modo Aop), mensaje de transacción local, transacción de mensaje (semi-mensaje), transacción de notificación de mayor esfuerzo

Confirmación de dos fases (XA)

Al igual que las transacciones locales, también se puede utilizar un esquema de compromiso de dos fases en escenarios de transacciones distribuidas. El nombre completo de XA es eXtended Architecture, que es un protocolo de transacciones distribuidas que garantiza una sólida coherencia a través de un protocolo de confirmación de dos fases.

La especificación XA define un modelo de procesamiento de transacciones distribuidas, que contiene cuatro funciones principales:

• RM (administradores de recursos): administrador de recursos, que proporciona interfaces de operación y administración para los recursos de datos para garantizar la coherencia e integridad de los datos. El más representativo es el sistema de gestión de bases de datos, por supuesto, algunos sistemas de archivos y sistemas MQ también pueden considerarse RM.
• TM (Transaction Managers): Transaction Manager, es el rol de un coordinador para coordinar el comportamiento de todos los RM asociados con transacciones entre bases de datos.
• AP (Programa de aplicación): el programa de aplicación llama a la interfaz de RM de acuerdo con las reglas comerciales para completar los cambios en los datos del modelo comercial. Cuando los cambios de datos involucran múltiples RM y las transacciones deben garantizarse, AP definirá los límites de las transacciones a través de TM, TM Responsable de coordinar cada RM que participa en la transacción para completar una transacción global juntos.
• CRM (Communication Resource Managers): se utiliza principalmente para la difusión de transacciones entre servicios.

 

Los dos procesos aproximados del protocolo XA son:

1. La primera etapa (preparación): el administrador de transacciones inicia una solicitud a todos los administradores de recursos locales para preguntar si está en el estado listo, y todos los participantes envían comentarios sobre si la transacción puede ser exitosa o no al coordinador;
2. La segunda etapa (compromiso / reversión): el administrador de transacciones notifica a todos los administradores de recursos locales basándose en los comentarios de todos los administradores de recursos locales y confirma o revierte todas las ramas al unísono.

¿Cómo satisface el protocolo XA ACID?

No hace falta decir que la originalidad y la durabilidad, veamos el aislamiento y la consistencia.

Aislamiento

El protocolo XA no describe cómo lograr el aislamiento de transacciones distribuidas, pero el protocolo XA requiere que cada administrador de recursos implemente transacciones locales, lo que significa que el aislamiento de transacciones distribuidas basado en el protocolo XA lo determina cada administrador de recursos. El aislamiento de las transacciones locales está garantizado Cuando todas las subtransacciones de una transacción distribuida están aisladas, la transacción distribuida logra el aislamiento de forma natural.

consistencia

La coherencia en un entorno autónomo es garantizar que los datos del servidor actual sean coherentes. Después de que se ejecuta la transacción, los datos finalmente son consistentes y el estado intermedio del proceso de ejecución de la transacción bajo diferentes niveles de aislamiento no puede ser observado por otras transacciones.

Después de que se ejecuta la transacción, es una buena garantía de que eventualmente será consistente, pero en el nivel de aislamiento RR, ¿cómo se puede lograr el estado intermedio de una transacción no comprometida en una situación distribuida? MySQL en una sola máquina proporciona un mecanismo MVCC, que utiliza control de múltiples versiones para manejarlo. ¿Puede un escenario de transacción distribuida también proporcionar tal mecanismo? El protocolo XA no define cómo implementar instantáneas globales. Una idea básica es utilizar algo centralizado o lógicamente monótonamente creciente para controlar la generación de instantáneas globales, que se obtendrán una vez por cada transacción o cada ejecución SQL para lograr un aislamiento diferente. Consistencia bajo el nivel. Por supuesto, el desarrollo sigue siendo bastante difícil.

Problemas existentes:

• Bloqueo síncrono: cuando los participantes de la transacción ocupan recursos públicos, uno de ellos ocupa los recursos, los otros participantes de la transacción solo pueden bloquear y esperar a que se libere el recurso y se encuentran en estado de bloqueo.
• Punto único de falla: una vez que falla el administrador de transacciones, todo el sistema no está disponible.
• Inconsistencia de datos: en la fase 2, si el administrador de transacciones solo envía parte del mensaje de confirmación y la red es anormal en este momento, entonces solo algunos participantes reciben el mensaje de confirmación, es decir, solo algunos participantes envían la transacción, lo que hace que los datos del sistema sean inconsistentes.
• Incertidumbre: después de que el administrador de transacciones envía un compromiso, y solo un participante recibe el compromiso en este momento, cuando el participante y el administrador de transacciones están inactivos al mismo tiempo, el administrador de transacciones reelegido no puede determinar si el mensaje se envía éxito.

En términos generales, la solución XA es sencilla de implementar, pero los problemas que surgen no se pueden garantizar si se coloca en un escenario con estrictos requisitos de coherencia de datos. Además, el punto único del administrador de transacciones traerá peligros ocultos y el modelo de bloqueo sincrónico también conduce a una concurrencia débil.

TCC

El concepto de TCC (Try-Confirm-Cancel) fue propuesto por primera vez por Pat Helland en un artículo titulado "La vida más allá de las transacciones distribuidas: la opinión de un apóstata" publicado en 2007. En comparación con el XA descrito anteriormente, el mecanismo de transacción de TCC resuelve varias deficiencias:

1. Se resuelve el punto único del coordinador, y esta actividad empresarial es iniciada y completada por la parte empresarial principal. El gerente de actividad empresarial también se ha vuelto multipunto, introduciendo clústeres.
2. Bloqueo síncrono: introduzca el tiempo de espera, compense después del tiempo de espera y no bloqueará todo el recurso, no transformará el recurso en una forma lógica empresarial y reducirá la granularidad.
3. Consistencia de los datos, después de tener un mecanismo de compensación, el gerente de actividad empresarial controla la consistencia.

La TCC es en realidad el mecanismo de compensación adoptado, su idea central es: Para cada operación, se debe registrar una operación de confirmación y compensación (revocación) correspondiente. El modelo TCC se entrega completamente a la empresa para que lo implemente, y cada sub-negocio necesita implementar las tres interfaces Try-Confirm-Cancel, lo cual es intrusivo para el negocio y el bloqueo de recursos se deja al lado del negocio.

• Etapa de prueba: intente ejecutar, completar todas las comprobaciones comerciales (coherencia) y reservar los recursos comerciales necesarios (cuasi aislamiento).
• Fase Confirmar: Confirmar que se realiza la ejecución real del negocio, sin ningún control comercial, y utilizar únicamente los recursos comerciales reservados en la fase Try, y la operación Confirmar satisface la idempotencia. Se requiere un diseño idempotente y se requiere un reintento después de que Confirmar falla.
• Fase Cancelar: Cancela la ejecución y libera los recursos comerciales reservados en la fase Try. La operación Cancelar satisface la idempotencia. Las excepciones en la fase Cancelar son básicamente las mismas que las de la fase Confirmar.

 

Una actividad comercial completa consta de un servicio comercial principal y varios servicios secundarios:

1. El principal servicio comercial se encarga de iniciar y completar toda la actividad comercial;
2. Los servicios comerciales proporcionan operaciones comerciales de tipo TCC;
3. El gerente de actividad comercial controla la consistencia de las actividades comerciales. Registra las operaciones en la actividad comercial y confirma la operación Confirmar de todas las operaciones tipo TCC cuando se presenta la actividad comercial, y llama a la operación Cancelar todas las operaciones tipo TCC cuando se cancela la actividad comercial.

Por ejemplo, una operación de transferencia:

1. Primero congele la billetera del cedente durante la fase de prueba.
2. En la fase Confirmar, llame a la interfaz de transferencia para operar la transferencia y descongele la transferencia después de una transferencia exitosa.
3. Si la fase Confirmar es exitosa, la transferencia es exitosa, de lo contrario se ejecuta la lógica de confirmación de falla de transferencia.

Basado en TCC para implementar transacciones distribuidas, la lógica que se puede implementar con una sola interfaz se divide en tres interfaces: Probar, Confirmar y Cancelar, por lo que la complejidad de implementación del código es relativamente alta y es necesario escribir mucho código del mecanismo de compensación en el negocio. .

TCC divide la transacción confirmada en dos etapas, Try es la primera etapa, Confirmar y Cancelar son dos ramas paralelas de la segunda etapa, elija una de las dos. La división del escenario es muy similar a 2PC, ¿podemos decir que TCC es un 2PC o una variante de 2PC?

En comparación con el modelo de transacción XA, todavía existen algunas diferencias entre el compromiso de dos fases de TCC y XA:

1. El objeto de operación de 2PC se encuentra en la capa de recursos y desconoce a los desarrolladores, mientras que la operación de TCC se encuentra en la capa de negocios, que tiene altos costos de desarrollo.
2. 2PC es una transacción larga en general y también una transacción rígida, mientras que TCC es un grupo de transacciones cortas locales, una transacción flexible.
3. Prepare (etapa de votación) de 2PC llevó a cabo la votación de la operación, mientras que Try de TCC no se preparó para la votación y combinó directamente las capacidades de preparación y operación de recursos.
4. 2PC es un recurso de bloqueo global, todos los participantes bloquean la interacción y esperan la notificación de TM; mientras que el bloqueo de recursos de TCC se encuentra en la operación Try, y la parte comercial puede elegir de manera flexible la granularidad de bloqueo de los recursos comerciales.

Tabla de mensajes locales #

La tabla de mensajes local fue mencionada originalmente por Dan Pritchett, un arquitecto de eBay, en un artículo "Base: An Acid Alternative" (https://queue.acm.org/detail.cfm?id=1394128) que explica el principio de BASE. Actualmente, la industria utiliza más este esquema y su idea central es dividir las transacciones distribuidas en transacciones locales para su procesamiento.

La solución es crear una tabla de mensajes de transacción adicional en el iniciador activo de la transacción. El iniciador de la transacción procesa el negocio y registra el mensaje de la transacción en una transacción local, sondea los datos en la tabla de mensajes de la transacción para enviar mensajes de la transacción y la parte pasiva consume la tabla de mensajes de la transacción en función del middleware de mensajes. Negocio.

Según la solución de tabla de mensajes local, cada iniciador de transacciones debe crear una tabla de registro de mensajes de transacciones adicional para registrar la ocurrencia y el estado de procesamiento de los mensajes de transacciones distribuidos.

 

El iniciador de la transacción debe guardar la transacción actual en la tabla de mensajes después de procesar la lógica empresarial, luego enviar el mensaje al middleware de mensajes y establecer el estado del mensaje en "enviando".

¿Qué pasa si el mensaje se pierde durante la entrega? El iniciador de la transacción puede establecer una tarea cronometrada para escanear activamente el mensaje cuyo estado es "enviando" y volver a entregarlo. Solo cuando el mensaje es consumido por la parte comercial y se devuelve el resultado del consumo exitoso, el éxito se confirma y el estado del mensaje cambia a "enviado".

Aquí, un mensaje puede enviarse repetidamente debido a anomalías en la red o anomalías en el envío, por lo que se requiere que el receptor sea idempotente y permita el consumo repetido.

La ventaja de este esquema es que el esquema es simple, el costo es bajo y la implementación no es complicada.

Pero hay muchas desventajas. Por ejemplo, la demora en el mensaje no es fácil de controlar; la tabla de mensajes locales está acoplada con la de negocios y no es universal; la tabla de mensajes locales se implementa en base a la base de datos, que tiene ciertos cuellos de botella.

Mensaje de transacción #

El modo de la tabla de mensajes locales mencionado anteriormente no puede soportar la consistencia de la ejecución de transacciones locales y el envío de mensajes.Si las transacciones se pueden agregar a las dos operaciones de ejecución de transacciones locales y envío de mensajes, no sería perfecto.

Basado en esta idea, el estado de almacenamiento del mensaje en MQ es la verdad. El productor del mensaje primero envía el mensaje a MQ. En este momento, el estado del mensaje es "por confirmar", y luego el productor ejecuta la transacción local. Si la ejecución es exitosa, lo envía a MQ. El mensaje le dice que cambie el estado del mensaje a "para ser enviado" y envíe el mensaje, y elimine el mensaje si la ejecución falla.

Esto asegura la coherencia de las transacciones locales y la entrega de mensajes.

 

1. En primer lugar, el iniciador de la transacción envía primero un mensaje de lectura previa a MQ. La diferencia entre este mensaje y el mensaje ordinario es que solo es visible para MQ y no se propagará hacia abajo.
2. Después de que MQ recibe el mensaje, primero persiste, luego se agregará al almacenamiento un nuevo mensaje con el estado a enviar, y luego el iniciador de la transacción devolverá un ACK procesado; el iniciador de la transacción comenzará a ejecutar la transacción local después de recibir el ACK procesado .
3. El iniciador decidirá si el mensaje de lectura previa debe continuar o retroceder en función del estado de ejecución de la transacción local. Además, MQ también debe respaldar su propia investigación inversa para resolver la situación anormal.Si la transacción local del iniciador se ha ejecutado y enviado un mensaje a MQ, pero el mensaje se pierde por razones de red, cómo resolverlo. Por tanto, este mecanismo de contracomprobación es muy importante.
4. Una vez que la transacción local se ejecuta con éxito, MQ también recibe una notificación correcta, luego actualiza el estado del mensaje a remitente y luego envía el mensaje a los consumidores descendentes En este momento, el consumidor puede manejar sus propias transacciones locales.

Nota : Dado que MQ generalmente garantiza que el mensaje se puede entregar correctamente, si la empresa no devuelve el resultado ACK a tiempo, puede causar el problema de entrega repetida de mensajes de MQ. Por lo tanto, para la solución de la coherencia final del mensaje, los consumidores de mensajes deben soportar el consumo idempotente de mensajes y no pueden provocar el consumo repetido del mismo mensaje.

Modelo de transacción SAGA #

¿Qué es Saga? Saga se define como "Transacción de larga duración" (Transacción de larga duración, en lo sucesivo denominada LLT). Es un concepto propuesto por el profesor HECTOR GARCIA-MOLINA de la Universidad de Princeton en un artículo de 1987 sobre bases de datos distribuidas.

Long Lived no está claro en el sentido literal ¿Cuánto tiempo significa Long? ¿La duración de la transacción es de una hora, un día o incluso una semana? En realidad tampoco, el lapso de tiempo no es importante. ¿Lo que es importante? La clave son múltiples "transacciones" entre sistemas. Saga a menudo se compone de múltiples transacciones externas, y se requieren múltiples interacciones de mensajes del sistema externo para migrar la transacción general desde el principio al estado final. Esto es similar a lo que hemos visto antes. La transacción corta de una base de datos no es la misma. Por ejemplo, una orden de viaje se compone de tres subórdenes de pasajes aéreos, hoteles y alquiler de automóviles, todos los cuales requieren confirmación externa. Sin ningún paso, no se puede realizar el viaje. Este es un LLT típico.

Parece que la definición de Sage no es diferente de otras transacciones distribuidas. ¿No es una transacción distribuida en la que múltiples subtransacciones diferentes forman un todo? Echemos un vistazo al mecanismo de compensación:

Cada transacción local tiene un módulo de ejecución y un módulo de compensación correspondientes.Cuando falla cualquier transacción local en la transacción de Sage, se puede restaurar llamando al método de compensación correspondiente de la transacción relacionada para lograr la consistencia final de la transacción.

El modelo Saga divide una transacción distribuida en múltiples transacciones locales. Cada transacción local tiene un módulo de ejecución correspondiente y un módulo de compensación (correspondiente a Confirmar y Cancelar en TCC). Cuando falla cualquier transacción local en la transacción Saga, La transacción anterior se puede restaurar llamando al método de compensación correspondiente para lograr la consistencia final de la transacción.

Dado que no hay una fase de preparación en el modelo de Saga, no se puede garantizar el aislamiento entre las transacciones. Cuando varias transacciones de Saga operan en el mismo recurso, se producirán problemas como la pérdida de actualizaciones y la lectura de datos sucios. En este momento, es necesario controlar la simultaneidad en la capa empresarial, por ejemplo:

• Bloquear a nivel de aplicación;
• Congele previamente los recursos a nivel de la aplicación.

Método de recuperación de saga

Saga admite la recuperación hacia adelante y hacia atrás:

• Recuperación hacia atrás: compensación por todas las transacciones completadas, si alguna transacción falla;
• Recuperación hacia adelante: vuelva a intentar las transacciones fallidas, asumiendo que cada subtransacción finalmente se realizará correctamente.

Aunque tanto Saga como TCC son transacciones de compensación, son diferentes debido a las diferentes fases de compromiso:

• Saga no compromete directamente el comportamiento de prueba, por lo que dejará rastros de la operación de transacción original. Cancelar es una compensación imperfecta y debe considerar el impacto en el negocio. TCC Cancel es un Rollback perfectamente compensado. La operación de compensación limpiará completamente la operación de transacción original anterior, y el usuario no percibirá la información de estado antes de que se cancele la transacción.
• La operación de compensación de Saga generalmente se puede ejecutar de forma asíncrona, y Cancelar y Confirmar de TCC puede hacer un seguimiento de si debe ser asíncrona.
• Saga es menos intrusivo para el negocio y solo necesita proporcionar una operación inversa de Cancelar, mientras que TCC necesita llevar a cabo una transformación de proceso global para el negocio.
• El número mínimo de comunicaciones TCC es 2n y Saga es n (n = el número de subtransacciones).

Debido a que también se usa el mecanismo de compensación, el servicio debe ser requerido para mantener la idempotencia Si la llamada de servicio se agota, se debe usar la idempotencia para evitar problemas causados ​​por múltiples solicitudes.

Satisfacción de las características de la transacción:

Atomicidad: el coordinador de Saga garantiza que toda la transacción se ejecuta correctamente o se revierte.

Consistencia: Sage garantiza una eventual consistencia.

Persistencia: Saga divide la transacción general en transacciones locales independientes, por lo que la persistencia se logra bien en las transacciones locales.

Pero el aislamiento de Saga no se puede realizar, debido a que la transacción grande se divide en múltiples transacciones pequeñas y el momento de cada transacción es diferente, es difícil garantizar que la transacción pequeña que se ha comprometido no sea visible para los demás.

Actualmente, la industria ofrece dos tipos de implementaciones de Saga:

• Uno es la realización de la coordinación centralizada. El método de coordinación centralizada es rastrear todas las invocaciones de las subtareas de Saga a través de un objeto de Saga, administrarlo y rastrear si la transacción completa debe enviarse o compensarse. La desventaja de este enfoque es que este enfoque de coordinación debe combinarse con la primera transacción de Saga, es decir, con el negocio.
• Uno es la implementación distribuida. La coordinación distribuida ciertamente puede evitar el problema del acoplamiento. También hay muchas soluciones de implementación distribuidas, como a través del mecanismo de eventos, todas las transacciones en una cadena de transacciones de Saga están suscritas al mismo evento y, si falla, se puede revertir a través del mensaje de evento correspondiente al error. Los beneficios de este enfoque son definitivamente obvios, pero habrá otro problema. El procesamiento de múltiples eventos debe ser altamente concurrente, por lo que habrá algunas dependencias circulares debido a problemas relacionados con el procesamiento de múltiples eventos. El problema.

Introducción al marco de transacciones distribuidas de código abierto #

Asiento

Seata (Arquitectura de transacción autónoma extensible simple) es una solución de transacción distribuida de código abierto conjunto de Ant Financial y Alibaba en enero de 2019.

Seata tendrá 4 soluciones de transacciones distribuidas, a saber, modo AT, modo TCC, modo Saga y modo XA.

 

Modo XA

El modo XA es otra solución de transacciones distribuidas no intrusivas que Seata abrirá en código abierto. Cualquier base de datos que implemente el protocolo XA se puede utilizar como recurso para participar en transacciones distribuidas. En la actualidad, las bases de datos convencionales, como MySql, Oracle, DB2 y Oceanbase Todos admiten el protocolo XA.

El protocolo XA tiene una serie de instrucciones, correspondientes a la primera y segunda etapa de operación. "Xa start" y "xa end" se utilizan para iniciar y finalizar transacciones XA; "xa prepare" se utiliza para confirmar previamente las transacciones XA, correspondiente a una etapa de preparación; "xa commit" y "xa rollback" se utilizan para confirmar y revertir transacciones XA , Correspondiente a la confirmación y reversión de dos fases.

En el modo XA, cada transacción XA es un participante de la transacción. Una vez iniciada la transacción distribuida, primero ejecute "xa start", "Business SQL", "xa end" y "xa prepare" en la primera etapa para completar la ejecución y la confirmación previa de la transacción XA; en la segunda etapa, ejecute "xa commit" si se envía , Si es una reversión, ejecute "xa reversión". Esto garantizará que todas las transacciones XA se confirmen o se deshagan.

 

En el modo XA, los usuarios solo deben prestar atención a su propio "SQL comercial", y el marco de Seata generará automáticamente operaciones de una y dos fases; la implementación del modo XA es la siguiente:

 

• El primer escenario:

En la primera etapa del modo XA, Seata interceptará el "Business SQL", iniciará la transacción XA ("xa start") antes del "Business SQL", luego ejecutará el "Business SQL", finalizará la transacción XA "xa end" y, finalmente, confirmará previamente XA Transacción ("xa prepare"), que completa la preparación de "Business SQL".

• Presentación en dos etapas:

Ejecute la instrucción "xa commit" para enviar la transacción XA. En este momento, el "Business SQL" se envía realmente a la base de datos.

• Retroceso en dos etapas:

Ejecute la instrucción "xa rollback" para retrotraer la transacción XA, completar la retrotracción "Business SQL" y liberar los recursos de bloqueo de la base de datos.

En el modo XA, los usuarios solo deben prestar atención al "SQL comercial", Seata generará automáticamente operaciones de compromiso de una fase, dos fases y reversión de dos fases. El modo XA, como el modo AT, es una solución no intrusiva para la empresa; pero a diferencia del modo AT, el modo XA delega los datos de las instantáneas y los bloqueos de filas en la base de datos mediante instrucciones XA, de modo que el modo XA logra más Ligero.

Modo AT

El modo AT es una solución de transacciones distribuidas no intrusivas. En el modo AT, los usuarios solo deben prestar atención a su propio "SQL comercial". El "SQL comercial" del usuario es la primera etapa, y el marco Seata generará automáticamente las operaciones de confirmación y reversión de la transacción en dos etapas.

 

Confirmación y reversión en una o dos fases del modo AT

Todos son generados automáticamente por el marco Seata. Los usuarios solo necesitan escribir "Business SQL" para acceder fácilmente a las transacciones distribuidas. El modo AT es una solución de transacciones distribuidas sin ninguna intrusión en el negocio.

Modo TCC

En marzo de 2019, Seata abrió el modelo TCC, que fue aportado por Ant Financial. El modo TCC requiere que los usuarios implementen las tres operaciones Probar, Confirmar y Cancelar de acuerdo con sus propios escenarios comerciales; el iniciador de la transacción ejecuta el método Try en la primera fase, envía el método Confirm en la segunda fase y revierte el método Cancelar en la segunda fase.

 

Se describen tres métodos de TCC:

• Prueba: detección y reserva de recursos;
• Confirmar: envíe la operación comercial ejecutada; si Try es exitoso, Confirmar debe ser exitoso;
• Cancelar: se liberan los recursos reservados.

Lo más importante para que los usuarios accedan al modo TCC es considerar cómo dividir el modelo de negocio en dos fases e implementarlo en los tres métodos de TCC, y asegurarse de que el Try sea exitoso y el Confirm sea exitoso. En comparación con el modo AT, el modo TCC es algo intrusivo para los códigos comerciales, pero el modo TCC no tiene el bloqueo de fila global del modo AT y el rendimiento de TCC es mucho más alto que el modo AT.

Modo saga

El modo Saga es la próxima solución de transacciones de código abierto a largo plazo de Seata, que será principalmente aportada por Ant Financial. En el modo Saga, hay varios participantes en una transacción distribuida, y cada participante es un servicio de compensación positiva, que requiere que los usuarios implementen sus operaciones de avance y retroceso inverso de acuerdo con los escenarios comerciales.

Durante la ejecución de una transacción distribuida, las operaciones forward de cada participante se ejecutan a su vez, si todas las operaciones forward se ejecutan con éxito, la transacción distribuida se compromete. Si falla alguna operación de avance, la transacción distribuida volverá para realizar la operación de reversión inversa de los participantes anteriores, revertirá a los participantes comprometidos y devolverá la transacción distribuida al estado inicial.

 

Las transacciones distribuidas en el modo Saga suelen estar controladas por eventos y cada participante se ejecuta de forma asincrónica. El modo Saga es una solución de transacción larga.

ServiceComb

ServiceComb es el marco de microservicio de código abierto de Huawei, que se ha actualizado al mejor proyecto de Apache. Para ser precisos, no es un marco de transacciones puramente distribuido, sino un marco de microservicio. La versión inicial es el lenguaje Go y luego es compatible con Java.

ServiceComb consta de 3 subproyectos:

• java-chassis: gobierno del servicio
• centro de servicio: registro de servicio
• saga: solución de transacciones distribuidas

Por el nombre, obviamente es una solución de transacción flexible desarrollada en base al modelo Saga. El sistema Saga se divide en dos partes: Alfa y Omega. Alpha es un servicio independiente que actúa como coordinador de transacciones. Como componente de desarrollo, Omega se ejecuta con procesos comerciales.

 

Omega inyectará módulos de procesamiento relevantes en la aplicación como una forma de programación de aspectos. Hay módulos para interceptar solicitudes que nos ayudan a construir el contexto de las llamadas de transacciones distribuidas. Al mismo tiempo, las operaciones de preparación relacionadas de la transacción se procesan en la etapa inicial del procesamiento de la transacción, como la creación de un evento de inicio de Saga y eventos de inicio relacionados, y producen eventos de terminación o falla de transacción relacionados en función del éxito o fracaso de la ejecución de la transacción.

Omega se vinculará con Alpha y notificará a Alpha de estos eventos. Alpha puede realizar análisis en segundo plano y emitir instrucciones relevantes a Omega para realizar la recuperación de reversión relacionada en función de la ejecución de transacciones de Saga.

La ventaja de este diseño es que el código de implementación de Saga está separado del código del usuario, el usuario solo necesita agregar algunas anotaciones y la implementación de Saga puede realizar la ejecución del evento de Saga y realizar el procesamiento relacionado.

Autor: rickiyang

Enlace original: https://www.cnblogs.com/rickiyang/p/13704868.html

Si cree que este artículo es útil para usted, le puede gustar y seguirlo para respaldarlo, o puede seguir mi cuenta pública. Hay más artículos técnicos sobre productos secos e información relacionada para compartir, ¡todos aprenden y progresan juntos!