1. Antecedentes
Con el desarrollo del negocio, un solo sistema gradualmente no puede satisfacer las necesidades del negocio y la arquitectura distribuida se ha convertido gradualmente en la primera opción para las plataformas de Internet a gran escala. El problema concomitante es que el plan de transacciones locales ya no puede satisfacerse y han surgido las especificaciones y los marcos relevantes para las transacciones distribuidas.
En este caso, los grandes fabricantes han implementado diferentes marcos distribuidos de acuerdo con las especificaciones de implementación de transacciones distribuidas para simplificar el procesamiento del trabajo relacionado con transacciones distribuidas por parte de los desarrolladores comerciales y permitir que los desarrolladores se concentren en el desarrollo comercial principal.
Seata es un marco de procesamiento de transacciones distribuido. Seata es de código abierto de Ali, anteriormente conocido como Fescar, y se transforma en Seata después de una actualización de marca.
2. Especificación de transacciones distribuidas
1. Conceptos relacionados con transacciones distribuidas
Transacción: una unidad de ejecución de programa es un conjunto de secuencias de operaciones definidas por el usuario que deben cumplir los atributos de ACID.
Asuntos locales: los asuntos son gestionados por el administrador de recursos local.
Transacción distribuida: Las operaciones de la transacción se ubican en diferentes nodos.
Transacción de sucursal: en una transacción distribuida, una transacción local administrada por el administrador de recursos.
Transacción global: una transacción completada por varios administradores de recursos a la vez, que consta de un conjunto de transacciones de sucursales.
2. Especificaciones de implementación de transacciones distribuidas
Para transacciones locales, puede utilizar el sistema DBMS para lograr la gestión de transacciones, pero para transacciones distribuidas, no puede hacer nada. Para las transacciones distribuidas, existen actualmente dos ideas principales: la fuerte especificación de coherencia del protocolo XA y la última especificación de coherencia de las transacciones flexibles.
2.1 XA
XA es un estándar de interfaz diseñado en base al protocolo de confirmación de 2 fases. Un administrador de recursos que implementa la especificación XA puede participar en transacciones globales XA. La aplicación realiza el trabajo del administrador de transacciones TM, la base de datos realiza el trabajo del administrador de recursos RM, TM genera un ID de transacción global y controla el compromiso y la reversión del RM.
2.2 Consistencia eventual de transacciones flexibles
Esta especificación tiene principalmente 3 tipos de formas de realización, TCC, mensaje de transacción MQ, tabla de mensajes locales. (Hay otras implementaciones menos utilizadas como Saga).
TCC: probar / confirmar / cancelar, bloquear el recurso en la fase de prueba, enviarlo en la fase de confirmación y liberar el recurso en la fase de cancelación si falla el bloqueo del recurso.
Mensaje de transacción MQ: el sistema de mensajes de requisitos previos debe admitir transacciones como RocketMQ. Antes de que se ejecute la transacción local, se envía el mensaje de transacción preparado, la transacción local se ejecuta con éxito y la confirmación del mensaje de transacción se envía para lograr la máxima consistencia de las transacciones distribuidas. Si falla la confirmación del mensaje de transacción, RocketMQ verificará el remitente del mensaje para asegurarse de que el mensaje se envía normalmente. Si la ejecución del paso 5 falla, se realiza un reintento para lograr la consistencia final.
Tabla de mensajes locales: similar a los mensajes de transacciones de MQ, la diferencia es que MQ no admite mensajes de transacciones y necesita utilizar las capacidades de gestión de transacciones de la base de datos local. En el paso 1, el mensaje que se enviará se envía a la base de datos junto con la transacción local, y el mensaje se conserva con la ayuda de la gestión de transacciones de la base de datos. Paso 2 La aplicación escanea la tabla de mensajes locales y vuelve a intentar enviarlos para asegurarse de que el mensaje se pueda enviar correctamente.
Tres, arquitectura Seata
1. ** Composición del sistema **
Seata tiene tres componentes principales:
-
Coordinador de transacciones (TC, coordinador de transacciones)
Mantenga el estado de las transacciones globales y las transacciones de sucursales, impulse el compromiso o la reversión de transacciones globales.
-
Administrador de transacciones (TM, administrador de transacciones)
Defina el alcance de la transacción global, inicie una transacción, confirme una transacción y revertir una transacción.
-
Administrador de recursos (RM, administrador de recursos):
Administre los recursos en las transacciones de la sucursal, registre las transacciones de la sucursal con TC, informe del estado de las transacciones de la sucursal e impulse el compromiso o la reversión de las transacciones de la sucursal.
Los tres componentes cooperan entre sí. TC se implementa de forma independiente en forma de servidor, y TM y RM se integran y se inician en la aplicación. La interacción general es la siguiente:
2. Modo de trabajo
Seata admite cuatro modos de trabajo:
2.1 AT （Transacción automática）
El modo AT es el modo de trabajo predeterminado de Seata. Debe basarse en bases de datos relacionales que admitan transacciones ACID locales, aplicaciones Java y acceso a bases de datos a través de JDBC.
2.1.1 Mecanismo general
Este modo es una evolución del protocolo XA. El protocolo XA se implementa en función del administrador de recursos, mientras que AT no. Las dos etapas de AT son:
-
Fase 1: Los datos comerciales y los registros de reversión se comprometen en la misma transacción local, y se liberan los bloqueos locales y los recursos de conexión.
- La segunda etapa: el envío es asincrónico y se completa muy rápidamente; el retroceso se compensa en la dirección inversa a través del registro de retroceso de la primera etapa.
En la figura siguiente, el paso 1 abre la transacción global; el paso 2 registra la transacción de la sucursal, que corresponde a la primera fase; el paso 3 confirma o revierte la transacción de la sucursal, corresponde a la segunda fase.
2.1.2 Funciones
-
Ventajas: no hay intrusión en el código; alta concurrencia, el bloqueo local se liberará en una etapa; no se requiere soporte de base de datos para el protocolo XA.
- Desventajas: Solo se puede usar en bases de datos relacionales que admiten ACID; el análisis de SQL aún no puede admitir toda la sintaxis.
2.2 TCC
El trabajo de este modo se divide en tres etapas: preparar / confirmar / cancelar.
2.2.1 Mecanismo general
-
TM aplica para la transacción global XID de TC y se propaga a cada sub-llamada.
-
El TM donde se encuentra la sub-llamada registra la transacción de la sucursal con el TC, ejecuta la preparación local e informa el resultado de la ejecución al TC.
- TC determina si la segunda etapa es ejecutar el compromiso o la reversión de acuerdo con los resultados de ejecución de cada transacción de sucursal.
2.2.2 Funciones
-
Ventajas: No depende de los asuntos locales.
- Desventajas: la lógica de reversión se basa en la codificación manual; el negocio es más invasivo.
2.3 Modo Saga
2.3.1 ¿Qué es Saga?
En 1987, Héctor García-Molina y Kenneth Salem de la Universidad de Princeton publicaron un Paper Sagas sobre cómo lidiar con transacciones de larga duración. Saga es una transacción de larga duración que se puede descomponer en una colección de subtransacciones que se pueden intercalar. Vea el documento aquí.
En pocas palabras, Saga descompone una transacción larga (T) en una serie de subtransacciones (Ti), y cada subtransacción tiene una acción de compensación correspondiente (Ci) para deshacer el impacto de la transacción Ti. Las subtransacciones se envían directamente a la biblioteca y, cuando ocurre una excepción, se compensa lo contrario.
Por lo tanto, existen dos tipos de transacciones de Saga:
-
T1, T2, T3, ..., Tn
- T1, T2, ..., Tj, Cj, ..., C2, C1, donde 0 <j <n
El primero es el caso de la presentación normal y el segundo es el caso en el que se produce una excepción cuando se envía la transacción Tj y se inicia la compensación inversa.
El modo Saga es una solución de transacción larga proporcionada por Seata. Por ejemplo, un sistema externo está involucrado en una transacción global y su administrador de recursos no se puede administrar y no es fácil transformarlo en un TCC, este tipo de solución se puede utilizar en este momento.
2.3.2 Mecanismo general
En el modelo Saga, cada participante en el proceso de negocio envía una transacción local. Cuando un participante falla, compensa al participante previamente exitoso. Tanto el servicio de reenvío de la primera fase como el servicio de compensación de la segunda fase se implementan mediante el desarrollo empresarial.
Para las transacciones de varias sucursales en la figura anterior, se omite el paso 2. * que aparece varias veces. Para el tiempo de inactividad de la aplicación empresarial durante la ejecución de la transacción global, el nodo par en el clúster de la aplicación empresarial recuperará la sesión relevante del TC y cargará la información detallada de la base de datos para restaurar la máquina de estado.
2.3.3 Funciones
-
Ventajas: envío de transacciones locales en una etapa, sin bloqueos, alto rendimiento; arquitectura dirigida por eventos, los participantes pueden ejecutar de forma asíncrona, alto rendimiento; los servicios de compensación son fáciles de implementar.
- Desventajas: el aislamiento no está garantizado.
Modo 2.4 XA
XA es un estándar de interfaz basado en el diseño de envío de dos fases. Para los administradores de recursos que admiten XA, el modo XA del marco Seata hará que la solución XA sea más fácil de usar. Requisito previo para su uso: la base de datos de la sucursal es necesaria para admitir transacciones XA, la aplicación es una aplicación Java y se utiliza JDBC para acceder a la base de datos.
2.4.1 Mecanismo general
En el marco de transacciones distribuidas definido por Seata, un modo de transacción que usa recursos de transacción (base de datos, servicio de mensajes, etc.) para admitir el protocolo XA y usa el mecanismo del protocolo XA para administrar las transacciones de las sucursales.
-
Etapa de ejecución: Business SQL se ejecuta en la sucursal XA, administrado por el administrador de RM de la transacción de la sucursal, y luego se ejecuta la preparación XA.
- Etapa de finalización: TM notifica a cada rama que ejecute el compromiso XA o la reversión XA a través de TC de acuerdo con el resultado de ejecución de cada rama.
2.4.2 ** Características **
-
Ventajas: herede las ventajas del protocolo XA y la transacción tiene una gran coherencia.
- Desventajas: También hereda las desventajas del protocolo XA. Debido a que las transacciones de sucursales están abiertas durante mucho tiempo, la concurrencia es baja.
2.5 Comparación de los modos de Seata
No existe una fórmula mágica en la solución de transacciones distribuidas. Elija el modelo apropiado de acuerdo con sus propias características comerciales. Por ejemplo, en busca de una coherencia sólida, puede elegir AT y XA, existir para interactuar con sistemas externos, puede elegir el modo Saga, no puede confiar en transacciones locales, puede usar TCC, etc. Elija según las ventajas y desventajas de cada modo.
Cuarto, la realización principal del modo AT
En vista del hecho de que Seata admite muchos modos, y su modo predeterminado es AT, para ahorrar espacio, el siguiente análisis de la implementación de su módulo central relacionado con el modo AT.
1. Inicie el coordinador de transacciones
TC (coordinador de transacciones) comienza como un servicio independiente, como servidor, mantiene el estado de las transacciones globales y las transacciones de las sucursales, e impulsa la confirmación o reversión de transacciones globales. El siguiente es el proceso de inicio de TC:
2. ** Inicio de Transaction Manager **
TM (Transaction Manager) está integrado y se inicia en la aplicación, responsable de definir el alcance de la transacción global, iniciar una transacción, confirmar una transacción y revertir una transacción.
GlobalTransactionScannerbean debe configurarse en la aplicación donde se encuentra TM, y el siguiente proceso de inicialización se realizará cuando se inicie la aplicación:
3 . Inicie el Explorador
RM (administrador de recursos) está integrado y se inicia en la aplicación, responsable de administrar los recursos en las transacciones de la sucursal, registrar las transacciones de la sucursal con TC, informar el estado de las transacciones de la sucursal e impulsar el compromiso o la reversión de las transacciones de la sucursal.
En la aplicación donde se encuentra RM, además de configurar GlobalTransactionScanner para iniciar RMClient como TM, también necesita configurar DataSourceProxy para implementar el proxy para el acceso a la fuente de datos. El agente de la fuente de datos implementa operaciones como el análisis sintáctico de sql → la generación de undo-log → el sql empresarial y el undo-log se envían localmente.
4. Flujo de trabajo de asuntos mundiales
Aquí hay un ejemplo simple para ilustrar el principio de funcionamiento de las transacciones globales:
-
BusinessService: iniciar un servicio de compra
- StorageService: servicio de gestión de inventario
La operación de compra se implementa en businessService.purchase, el método de compra se anota a través de GlobalTransaction y el método de deducción del servicio de inventario se llama a través del servicio Dubbo. El ejemplo es el siguiente:
@GlobalTransactional(timeoutMills = 300000, name = "dubbo-demo-tx")
public void purchase(String userId, String commodityCode, int orderCount) {
storageService.deduct(commodityCode, orderCount);
// throw new RuntimeException("xxx");
}4.1 Proceso de transacción global exitoso
4.2 Proceso de transacción global exitoso
Aquí se establece que después de que BusinessService llame con éxito a StorageService, se produzca una excepción localmente.
5. Escribe la realización del aislamiento
Cuando la transacción global no se ha comprometido y la transacción de la sucursal se ha comprometido localmente (asumiendo que el recurso A se modifica), ¿cómo evitar que otras transacciones modifiquen el recurso A en este momento? Seata utiliza un bloqueo global para lograrlo, y su proceso es el siguiente:
6. Leer la realización del aislamiento
Sobre la base de que el nivel de aislamiento local de la base de datos es de lectura confirmada o superior, Seata proporciona lectura no confirmada. Esto se comprende bien. La transacción de la sucursal se ha comprometido localmente antes de que se confirme la transacción global. Si desea leer enviado, debe agregar para actualizar la declaración de selección.
Cinco, resumen
Seata es un poderoso marco de transacciones distribuidas en el campo de Java, que admite múltiples modos. El modo AT soportado por defecto, en comparación con el protocolo 2PC tradicional (protocolo XA basado en bases de datos), resuelve el problema de los recursos de bloqueo a largo plazo de 2PC y mejora la concurrencia. Entre los diversos modos admitidos por Seata, el modo AT implementa transacciones distribuidas para operaciones comerciales cero, que es más amigable para los desarrolladores. Además, el servidor de Seata se puede agrupar al seleccionar un medio de almacenamiento adecuado para reducir el impacto de puntos únicos de falla.
Este artículo se refiere principalmente al sitio web oficial y algunos blogs. Al mismo tiempo, leo el código fuente del modo AT. Si hay algo mal, espero señalarlo y discutir e intercambiar juntos.
Seis, referencia
Autor: equipo de desarrollo del centro comercial del sitio web oficial de vivo