Preguntas de la entrevista sobre transacciones distribuidas

1. Introducción comercial

Una transacción es una unidad de ejecución de programa (unidad) que opera sobre un elemento de datos en la base de datos.

Las transacciones deben tener cuatro atributos: atomicidad, coherencia, aislamiento y durabilidad. Estas cuatro propiedades a menudo se denominan propiedades ÁCIDAS.

1.1 Glosario de términos

• Transacción: Una transacción es una unidad de trabajo confiable e independiente compuesta por un conjunto de operaciones. La transacción tiene características ACID, a saber, atomicidad, consistencia, aislamiento y durabilidad.
• Transacciones locales: cuando el administrador de recursos gestiona una transacción localmente, se denomina transacción local. La ventaja de las transacciones locales es que admite características ACID estrictas, es eficiente y confiable, el estado solo se puede mantener en el administrador de recursos y el modelo de programación de aplicaciones es simple. Sin embargo, las transacciones locales no tienen las capacidades de procesamiento de las transacciones distribuidas y la unidad de aislamiento más pequeña está limitada por el administrador de recursos.
• Transacción global: cuando una transacción es administrada globalmente por el administrador de transacciones global, se convierte en una transacción global. El administrador de transacciones es responsable de administrar el estado de la transacción global y los recursos participantes, y coordina la confirmación y reversión consistentes de los recursos.
• Protocolo TX: la interfaz entre la aplicación o el servidor de aplicaciones y el administrador de transacciones.
• Protocolo XA: la interfaz entre el administrador de transacciones global y el administrador de recursos. XA es una especificación de transacción distribuida propuesta por la organización X/Open. Esta especificación define principalmente la interfaz entre el administrador de transacciones global y el administrador de recursos local. Todos los productos de bases de datos convencionales implementan la interfaz XA. La interfaz XA es una interfaz de sistema bidireccional que sirve como puente de comunicación entre el administrador de transacciones y múltiples administradores de recursos. La razón por la que se necesita XA es que, en teoría, dos máquinas no pueden alcanzar un estado consistente en un sistema distribuido, por lo que se introduce un único punto de coordinación. Las transacciones administradas y coordinadas por el administrador de transacciones global pueden abarcar múltiples recursos y procesos. El administrador de transacciones global generalmente utiliza el protocolo de dos fases XA para interactuar con la base de datos.
• AP: Programa de aplicación, que puede entenderse como un programa que utiliza DTP (Plataforma de herramientas de datos).
• RM: Administrador de recursos, que puede ser un DBMS o un sistema de administración de servidores de mensajes. Las aplicaciones controlan los recursos a través del administrador de recursos. Los recursos deben implementar la interfaz definida por XA. El administrador de recursos es responsable de controlar y gestionar los recursos reales.
• TM: Transaction Manager, responsable de coordinar y gestionar transacciones, proporcionar interfaces de programación AP y gestionar administradores de recursos. El administrador de transacciones controla las transacciones globales, gestiona los ciclos de vida de las transacciones y coordina los recursos.
• 两阶段提交协议：XA用于在全局事务中协调多个资源的机制。TM和RM之间采取两阶段提交的方案来解决一致性问题。两节点提交需要一个协调者（TM）来掌控所有参与者（RM）节点的操作结果并且指引这些节点是否需要最终提交。两阶段提交的局限在于协议成本，准备阶段的持久成本，全局事务状态的持久成本，潜在故障点多带来的脆弱性，准备后，提交前的故障引发一系列隔离与恢复难题。
• BASE理论：BA指的是基本业务可用性，支持分区失败，S表示柔性状态，也就是允许短时间内不同步，E表示最终一致性，数据最终是一致的，但是实时是不一致的。原子性和持久性必须从根本上保障，为了可用性、性能和服务降级的需要，只有降低一致性和隔离性的要求。
• CAP定理：对于共享数据系统，最多只能同时拥有CAP其中的两个，任意两个都有其适应的场景，真是的业务系统中通常是ACID与CAP的混合体。分布式系统中最重要的是满足业务需求，而不是追求高度抽象，绝对的系统特性。C表示一致性，也就是所有用户看到的数据是一样的。A表示可用性，是指总能找到一个可用的数据副本。P表示分区容错性，能够容忍网络中断等故障。

1.2、分布式事务与分布式锁的区别：

分布式锁解决的是分布式资源抢占的问题；分布式事务和本地事务是解决流程化提交问题。

1.3、事务的四个特征：

Atomic原子性

• 事务必须是一个原子的操作序列单元，事务中包含的各项操作在一次执行过程中，要么全部执行成功，要么全部不执行，任何一项失败，整个事务回滚，只有全部都执行成功，整个事务才算成功。

Consistency一致性

• 事务的执行不能破坏数据库数据的完整性和一致性，事务在执行之前和之后，数据库都必须处于一致性状态。

Isolation隔离性

• 在并发环境中，并发的事务是相互隔离的，一个事务的执行不能被其他事务干扰。即不同的事务并发操纵相同的数据时，每个事务都有各自完整的数据空间，即一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能相互干扰。

• SQL中的4个事务隔离级别：

  （1）读未提交

允许脏读。如果一个事务正在处理某一数据，并对其进行了更新，但同时尚未完成事务，因此事务没有提交，与此同时，允许另一个事务也能够访问该数据。例如A将变量n从0累加到10才提交事务，此时B可能读到n变量从0到10之间的所有中间值。

（2）读已提交

允许不可重复读。只允许读到已经提交的数据。即事务A在将n从0累加到10的过程中，B无法看到n的中间值，之中只能看到10。同时有事务C进行从10到20的累加，此时B在同一个事务内再次读时，读到的是20。

(3) Lectura repetible

允许幻读。保证在事务处理过程中，多次读取同一个数据时，其值都和事务开始时刻时是一致的。禁止脏读、不可重复读。幻读即同样的事务操作，在前后两个时间段内执行对同一个数据项的读取，可能出现不一致的结果。保证B在同一个事务内，多次读取n的值，读到的都是初始值0。幻读，就是不同事务，读到的n的数据可能是0，可能10，可能是20

(4) Serialización

 最严格的事务，要求所有事务被串行执行，不能并发执行。

Si no existe control de concurrencia en las transacciones, echemos un vistazo a las situaciones anormales que pueden ocurrir en las operaciones concurrentes de la base de datos.

• Un tipo de actualización perdida: dos cosas leen los mismos datos, una modifica el campo 1 y la otra modifica el campo 2. La enviada más tarde restaura el campo enviado primero.
• Actualización perdida tipo II: Dos cosas leen los mismos datos, ambas modifican el mismo campo y la enviada más tarde sobrescribe la modificación enviada primero.
• Lectura sucia: se lee un valor no confirmado. Si la transacción se revierte, se producirá una lectura sucia.
• Lectura no repetible: entre dos consultas, el contenido de los datos fue modificado por otra transacción, lo que provocó una inconsistencia en el contenido.
• Lectura fantasma: entre dos consultas, otra transacción inserta o elimina registros, lo que genera inconsistencia en el conjunto de resultados.

DurabilidadPersistencia

• Durabilidad: La durabilidad, también conocida como permanencia, significa que una vez que se envía una transacción, sus cambios de estado a los datos correspondientes en la base de datos deben ser permanentes.

• Incluso si se produce una falla del sistema o un tiempo de inactividad de la máquina, siempre que se pueda reiniciar la base de datos, se puede restaurar al estado en el que la transacción finalizó exitosamente.

1.4, esquema de implementación de transacciones locales de MySQL

En la mayoría de los escenarios, nuestras aplicaciones solo necesitan operar una única base de datos, en este caso la transacción se denomina transacción local (Transacción local). Las propiedades ACID de las transacciones locales están respaldadas directamente por la base de datos.

Los estudiantes que hayan aprendido sobre las transacciones de MySQL sabrán que para lograr transacciones locales, MySQL ha trabajado mucho, como registros de reversión, registros de rehacer, MVCC, bloqueos de lectura y escritura, etc.

El principio de realización de transacciones de la base de datos MySQL.

Tomando InnoDB de MySQL (InnoDB es un motor de almacenamiento de MySQL) como ejemplo, presentaremos el principio de implementación de transacciones de una única base de datos.

InnoDB garantiza las características ACID de las transacciones a través de registros y bloqueos, de la siguiente manera:

(1) Garantizar el aislamiento de las transacciones a través del mecanismo de bloqueo de la base de datos;

(2) Garantizar la durabilidad de las transacciones a través de Redo Log;

(3) Garantizar la atomicidad de las transacciones a través de Deshacer Registro;

(4) Garantizar la coherencia de las transacciones a través del Registro de deshacer;

¿Cómo garantiza Undo Log la atomicidad de las transacciones?

El método específico es: antes de operar cualquier dato, primero haga una copia de seguridad de los datos en un lugar (el lugar donde se almacena la copia de seguridad de los datos se llama Deshacer registro) y luego modifique los datos. Si ocurre un error o el usuario ejecuta una instrucción Rollback, el sistema puede usar la copia de seguridad en el Registro de deshacer para restaurar los datos al estado anterior a que comenzara la transacción.

¿Cómo garantiza Redo Log la durabilidad de las transacciones?

La forma específica es: Redo Log registra la copia de seguridad de nuevos datos (a diferencia de Undo Log). Antes de confirmar la transacción, siempre que se conserve el registro de rehacer, no es necesario conservar los datos. Cuando el sistema falla, aunque los datos no se conservan, el registro de rehacer sí se conserva. El sistema puede restaurar todos los datos al estado anterior al fallo de acuerdo con el contenido del Redo Log.

1.5 Lectura sucia, lectura fantasma, lectura no repetible

Cuando se operan varias transacciones al mismo tiempo, se producirán los siguientes tres problemas en la base de datos: lecturas sucias, lecturas fantasma y lecturas no repetibles.

1.5.1 Lectura sucia

La transacción A lee los datos no confirmados de la transacción B:

Antes de que la transacción A lea los datos y la transacción B modifique los datos antes de enviarlos, la transacción A lee los datos nuevamente y leerá los datos que la transacción B ha modificado. Si la transacción B revierte o modifica los datos nuevamente en este momento, luego confirme , los datos leídos por la transacción A son datos sucios, esta situación se llama lectura sucia (lectura sucia).

1.5.2 Lectura fantasma

Cuando la transacción A realiza una consulta de rango, la transacción B agrega nuevos registros que cumplen con las condiciones del rango. Cuando la transacción A realiza una consulta de rango nuevamente según las condiciones, encontrará nuevos registros que cumplan con las condiciones enviadas en la transacción B (Fila fantasma) .

1.5.3, lectura no repetible (lectura irrepetible)

Después de que la transacción A lee algunos datos, los lee nuevamente y descubre que los datos leídos se han modificado o eliminado en la transacción B.

La diferencia entre lectura fantasma y no repetibilidad:

Lectura fantasma: en la misma transacción, en las mismas condiciones, el número de registros consultados dos veces es diferente;
Lectura no repetible: en la misma transacción, en las mismas condiciones, los datos consultados dos veces son diferentes;

1.6 Nivel de aislamiento de transacciones

Para solucionar los problemas causados ​​por la concurrencia de transacciones en la base de datos, en la especificación SQL estándar se definen cuatro niveles de aislamiento de transacciones, cada nivel especifica las modificaciones realizadas en una transacción y cuáles son visibles dentro y entre transacciones, cuáles son invisibles. .

Los niveles de aislamiento más bajos generalmente admiten una mayor concurrencia y tienen una menor sobrecarga del sistema.

Controle el nivel de aislamiento de las transacciones modificando los parámetros del sistema MySQL. En MySQL8, este parámetro es transaction_isolation, y en MySQL5, este parámetro es tx_isolation:

MySQL8：
-- 查看系统隔离级别：
SELECT @@global.transaction_isolation;

-- 查看当前会话隔离级别
SELECT @@transaction_isolation;

-- 设置当前会话事务隔离级别
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;

-- 设置全局事务隔离级别
SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

Cuatro niveles de aislamiento de transacciones:

Lectura no confirmada (LEER NO COMPROMETIDA): todas las transacciones pueden ver las modificaciones no confirmadas de otras transacciones. Generalmente rara vez se usa;

LEER COMPROMETIDO: Nivel de aislamiento predeterminado de Oracle, las transacciones solo pueden ver los cambios enviados entre sí;

Lectura repetible (LECTURA REPETIBLE): nivel de aislamiento predeterminado de MySQL, varias consultas en la misma transacción verán las mismas filas de datos; la lectura no repetible se puede resolver, pero pueden ocurrir lecturas fantasmas;

SERIALIZABLE: El nivel de aislamiento más alto, ejecución en serie de transacciones, una vez ejecutada la transacción anterior, se ejecutarán las transacciones posteriores. Cada dato leído se bloqueará, lo que provocará muchos tiempos de espera y problemas de contención de bloqueo;

2. Conceptos básicos de transacciones distribuidas.

2.1 Complejidad de las transacciones en un entorno distribuido

Diversidad en el lado del almacenamiento.

La primera es la diversidad de almacenamiento. En el caso de transacciones locales, todos los datos caerán en la misma base de datos, pero en el caso de transacciones distribuidas, los datos pueden caer en varias bases de datos o en Redis, MQ, etc.

Diversidad final de almacenamiento, como se muestra en la siguiente figura:

Escalabilidad de los enlaces de transacciones

En el caso de transacciones locales, normalmente encapsularemos todas las operaciones comerciales relacionadas con transacciones en un método de Servicio. En el caso distribuido, el enlace de solicitud se extiende y alarga, y una operación se dividirá en múltiples servicios, que son lineales o en forma de malla, y dependen de la comunicación de red para formar un todo. En este caso, sin duda, las cosas se complican más.

Escalabilidad del enlace de transacción, como se muestra en la siguiente figura:

Teniendo en cuenta las dos complejidades anteriores, no es realista esperar una solución de transacciones distribuidas unificadas que pueda satisfacer varios medios de almacenamiento y varios enlaces complejos de una manera casi no invasiva como las transacciones locales.

Al menos, por el momento, no existe una solución muy madura. Por lo tanto, en circunstancias normales, en condiciones distribuidas, las transacciones se dividirán y resolverán, y se adoptarán diferentes soluciones según las diferentes situaciones.

2.2 ¿Qué es una transacción distribuida?

Para los sistemas distribuidos, es necesario garantizar la coherencia de los datos en el sistema distribuido, garantizar que los datos siempre sean coherentes en el subsistema y evitar problemas comerciales. En un sistema distribuido, los pares de números tienen éxito o fracasan juntos, y debe ser una transacción holística.

Las transacciones distribuidas significan que los participantes de la transacción, los servidores de soporte de la transacción, los servidores de recursos y los administradores de transacciones están ubicados en diferentes nodos en diferentes sistemas distribuidos.

En pocas palabras, una operación grande en un sistema distribuido consta de diferentes operaciones pequeñas. Estas pequeñas operaciones se distribuyen en diferentes nodos de servicio y pertenecen a diferentes aplicaciones. Las transacciones distribuidas deben garantizar que todas estas pequeñas operaciones tengan éxito, o todo lo demás fallará.

Por ejemplo: en un sitio web de comercio electrónico, cuando un usuario realiza un pedido de un producto, debe crear datos de pedido en la tabla de pedidos y, al mismo tiempo, modificar la cantidad de inventario restante del producto actual en la tabla de pedidos. tabla de inventario. Hay dos pasos: uno para agregar y otro para modificar. Debemos asegurarnos de que estos dos pasos deben tener éxito o fallar al mismo tiempo, de lo contrario ocurrirán problemas comerciales.

Al implementar cualquier mecanismo de transacción, se deben considerar las características ACID de las transacciones, incluidas: transacciones locales y transacciones distribuidas. Para las transacciones distribuidas, incluso si no todas pueden estar bien satisfechas, debemos considerar hasta qué punto son compatibles.

Escenario típico de transacciones distribuidas:

Transacción entre bases de datos
La transacción entre bases de datos significa que una determinada función de una aplicación necesita operar varias bibliotecas y diferentes datos comerciales se almacenan en diferentes bibliotecas. El autor ha visto un negocio relativamente complejo en el que funcionaban 9 bibliotecas al mismo tiempo.

La siguiente figura muestra un servicio que opera dos bibliotecas al mismo tiempo:

División de bases de datos y tablas
Por lo general, cuando una base de datos tiene un gran volumen de datos o el volumen de datos futuro esperado es relativamente grande, se dividirá horizontalmente, es decir, en bases de datos y tablas.

Como se muestra en la siguiente figura, la base de datos B se divide en dos bibliotecas:

Para el caso de subbases de datos y subtablas, los desarrolladores generalmente utilizan algún middleware de base de datos para reducir la complejidad de las operaciones SQL.

Por ejemplo, para SQL: inserte en los valores de usuario (id, nombre) (1, "tianshouzhi"), (2, "wangxiaoxiao"). Este SQL es la sintaxis para operar una sola base de datos. En el caso de una sola base de datos, se puede garantizar la coherencia de las transacciones.

Sin embargo, dado que la base de datos y las tablas ahora están divididas en subbases de datos, el desarrollador espera insertar el registro número 1 en la subbase de datos 1 y el registro número 2 en la subbase de datos 2. Por lo tanto, el middleware de la base de datos necesita reescribirlo en dos declaraciones SQL e insertarlas en dos subbases de datos diferentes respectivamente. En este momento, es necesario garantizar que ambas bibliotecas tengan éxito o fallen, por lo que básicamente todo el middleware de la base de datos enfrenta el problema Distribuido cuestiones de transacciones.

Microservicio
La arquitectura de microservicio es un concepto relativamente popular en la actualidad. Por ejemplo, en el caso mencionado por el autor anterior, una aplicación opera 9 bibliotecas al mismo tiempo. La lógica de negocios de dicha aplicación debe ser muy compleja, lo cual es un gran desafío para los desarrolladores. Debe dividirse en diferentes servicios independientes. para simplificar la lógica de negocio. Después de la división, los servicios independientes pueden realizar llamadas remotas a través del marco RPC para comunicarse entre sí. La siguiente figura muestra una arquitectura en la que tres servicios se llaman entre sí:

El servicio A necesita operar directamente la base de datos para completar una determinada función y necesita llamar al servicio B y al servicio C al mismo tiempo. El servicio B opera dos bases de datos al mismo tiempo y el servicio C también opera una biblioteca. Es necesario garantizar que estas operaciones entre servicios en múltiples bases de datos tengan éxito o fracasen. De hecho, este puede ser el escenario de transacciones distribuidas más típico.

Las soluciones de implementación de transacciones distribuidas deben considerar los problemas de rendimiento. Si el rendimiento se degrada severamente para garantizar estrictamente las características ACID, entonces es inaceptable para algunas empresas que requieren una respuesta rápida.

3. Teorema de la PAC

3.1 Base teórica de las transacciones distribuidas

Las cuatro características principales de las transacciones de bases de datos ACID no pueden satisfacer las necesidades reales de las transacciones distribuidas. En este momento, algunos nuevos expertos han propuesto algunas teorías nuevas.

3.2 Teorema de la PAC

El teorema CAP fue propuesto por el profesor Eric Brewer de la Universidad de California, Berkeley, quien señaló que los servicios WEB no pueden satisfacer los tres atributos siguientes al mismo tiempo:

• Consistencia: El cliente sabe que una serie de operaciones ocurrirán (entrarán en vigor) al mismo tiempo.
• Disponibilidad: Cada operación debe finalizar con una respuesta predecible.
• Tolerancia de partición: incluso si un solo componente deja de estar disponible, la operación aún se puede completar

Específicamente, en un sistema distribuido, una aplicación web solo puede admitir los dos atributos anteriores al mismo tiempo. Por tanto, los diseñadores deben elegir entre coherencia y usabilidad.

Lo que el profesor Eric Brewer propuso en julio de 2000 fue solo una conjetura. Dos años más tarde, Seth Gilbert y Nancy Lynch del MIT demostraron teóricamente la teoría CAP, y un sistema distribuido solo puede satisfacer los requisitos de CAP como máximo 2 elementos. Después de eso, la teoría CAP se convirtió oficialmente en un teorema reconocido en el campo de la computación distribuida.

Por lo tanto, ¡el teorema CAP es aplicable a sistemas distribuidos hasta ahora!

La coherencia, disponibilidad y tolerancia de partición de CAP son las siguientes:

consistencia

La coherencia de los datos se refiere a "todos los nodos ven los mismos datos al mismo tiempo", es decir, después de que la operación de actualización es exitosa y se devuelve al cliente, los datos de todos los nodos al mismo tiempo son completamente consistentes y ningún estado intermedio puede existir.

En un entorno distribuido, la coherencia se refiere a la capacidad de que varias copias sigan siendo coherentes. Según el requisito de coherencia, cuando un sistema realiza una operación de actualización en un estado de datos coherente, debe garantizar que los datos del sistema todavía estén en un estado coherente.

Por ejemplo, para que un usuario del sistema de comercio electrónico realice un pedido, operaciones como la reducción de inventario, la deducción de la cuenta de capital del usuario y el aumento de puntos deben ser consistentes una vez completada la operación del pedido del usuario. No puede haber una situación en la que el inventario se haya reducido, pero la cuenta de capital del usuario no se haya deducido y los puntos no se hayan aumentado. Si esto ocurre, se considera inconsistente.

La coherencia de los datos se divide en coherencia fuerte, coherencia débil y coherencia final.

Si es cierto que los datos vistos por el cliente siempre son consistentes como se describe anteriormente, se llama consistencia fuerte.
Si se permite un estado intermedio, y sólo después de un período de tiempo, los datos finalmente son consistentes, se llama consistencia final.
Además, si se permite una inconsistencia parcial de los datos, se denomina consistencia débil.

Disponibilidad

Los servicios proporcionados por el sistema deben estar siempre disponibles y los resultados deben devolverse dentro de un tiempo limitado para cada solicitud de operación del usuario.

Dos dimensiones medidas:

(1) Dentro de un tiempo limitado
, para la solicitud de operación de un usuario, el sistema debe poder devolver el resultado del procesamiento correspondiente dentro del tiempo especificado (tiempo de respuesta), si se excede este rango de tiempo, el sistema se considera no disponible. Es decir, el tiempo de respuesta debe estar dentro de un valor razonable para no decepcionar a los usuarios.

Imagínese, si una operación de pedido tarda 10 minutos en completarse para garantizar la coherencia de las transacciones distribuidas, los usuarios obviamente no podrán soportarlo.

(2) Devolver un resultado normal
Se requiere que el sistema devuelva un resultado de respuesta normal después de procesar la solicitud del usuario. Los resultados de la respuesta normal generalmente reflejan claramente el resultado del procesamiento de la solicitud, es decir, el éxito o el fracaso, en lugar de un resultado devuelto que confunde al usuario. Por ejemplo, si se devuelve un error del sistema como OutOfMemory, el sistema se considera no disponible.

El "resultado devuelto" es otro indicador muy importante de disponibilidad: requiere que el sistema devuelva un resultado de respuesta normal después de completar el procesamiento de la solicitud del usuario, independientemente de si el resultado es exitoso o fallido.

Tolerancia de partición

Es decir, cuando un sistema distribuido encuentra cualquier falla en la partición de la red, aún necesita poder garantizar que proporciona servicios externos que cumplan con la coherencia y la disponibilidad, a menos que falle todo el entorno de la red.

La partición de red se refiere a que en un sistema distribuido, diferentes nodos se distribuyen en diferentes subredes (sala de computadoras/red remota). Debido a algunas razones especiales, existe un estado de desconexión de red entre estas subredes, pero cada subred red La red interna es normal, lo que hace que el entorno de red de todo el sistema se divida en varias áreas aisladas. La unión y salida de cada nodo que forma un sistema distribuido puede considerarse como una partición de red especial.

3.3 Aplicación de la PAC

rendirse

Si renuncia a la tolerancia a fallos de la partición, renuncia a la distribución y la escalabilidad del sistema.

renunciar a una

Si se pierde la disponibilidad, al encontrar una partición de red u otra falla, el servicio afectado deberá esperar un cierto período de tiempo, durante este período el servicio de política no se puede brindar al mundo exterior, es decir, será indisponible.

renunciar a C

Si se abandona la coherencia (aquí se refiere a una coherencia fuerte), el sistema no puede garantizar la coherencia de los datos en tiempo real. Cuando los datos alcanzan la coherencia final, hay una ventana de tiempo y los datos son inconsistentes dentro de la ventana de tiempo.

Para los sistemas distribuidos, no se puede renunciar a P, por lo que los arquitectos suelen hacer un equilibrio entre disponibilidad y coherencia.

La teoría CAP nos dice:
en la actualidad, muchos sitios web y aplicaciones grandes se implementan de manera distribuida, y la cuestión de la coherencia de los datos en escenarios distribuidos siempre ha sido un tema importante.

Según la teoría CAP, muchos sistemas deben hacer concesiones entre estos tres al comienzo del diseño:

Ningún sistema distribuido puede satisfacer la coherencia, la disponibilidad y la tolerancia de partición al mismo tiempo, solo puede satisfacer dos como máximo. En la mayoría de los escenarios en el campo de Internet, es necesario sacrificar una fuerte coherencia a cambio de una alta disponibilidad del sistema, y ​​el sistema a menudo sólo necesita garantizar una coherencia final.

P: ¿Por qué no se pueden garantizar tanto la coherencia como la disponibilidad en un sistema distribuido?

Respuesta: En primer lugar, para los sistemas distribuidos, la tolerancia a fallas de partición es el requisito más básico, por lo que básicamente solo podemos elegir entre consistencia (C) y disponibilidad (A) al diseñar un sistema distribuido.

Si se garantiza la coherencia (C): para los nodos N1 y N2, al escribir datos en N1, se debe suspender la operación en N2. Solo cuando N1 sincroniza los datos con N2 se pueden realizar solicitudes de lectura y escritura en N2. Solicitudes enviadas por el cliente durante la operación de pausa recibirá una falla o un tiempo de espera. Obviamente, esto es contrario a la usabilidad.

Si se garantiza la disponibilidad (A): entonces las operaciones de lectura y escritura de N2 no se pueden suspender, pero si N1 está escribiendo datos al mismo tiempo, esto viola el requisito de coherencia.

3.4 Compensación de la PAC

A través de la teoría CAP, sabemos que las tres características de consistencia, disponibilidad y tolerancia a fallas de partición no se pueden satisfacer al mismo tiempo, entonces, ¿cuál debería descartarse?

Para la mayoría de los escenarios de aplicaciones de Internet a gran escala, hay muchos hosts e implementaciones dispersas, y el tamaño del clúster actual es cada vez mayor, por lo que las fallas de los nodos y las fallas de la red son normales, y se debe garantizar que la disponibilidad del servicio alcance N 9, es decir , P y A están garantizados y se descarta C (lo mejor que puede hacer es garantizar la coherencia final). Aunque algunos lugares afectarán la experiencia del cliente, pero no hasta el punto de provocar un flujo de usuarios.

Para escenarios que involucran dinero donde no puede haber compromiso, C debe garantizarlo. Si la red falla, es mejor detener el servicio, esto es para asegurar CA y abandonar P. Parece que en los últimos años han ocurrido no menos de 10 accidentes en el sector bancario nacional, pero el impacto no fue grande, no hubo muchos informes y el público en general sabía poco. Otra opción es garantizar CP y descartar A. Por ejemplo, la falla de la red es solo de lectura pero no de escritura.

3.5 A y C en CAP y ACID son completamente diferentes.

La diferencia entre A:

• La A en ACID se refiere a atomicidad, lo que significa que la transacción se considera una unidad mínima de trabajo indivisible. Todas las operaciones en la transacción se envían con éxito o se revierten después de una falla;
• La A en CAP se refiere a Disponibilidad, que se refiere a si todo el clúster aún puede responder a las solicitudes de lectura y escritura del cliente después de que falla una parte de los nodos del clúster;

La diferencia entre C:

• La coherencia ACID tiene que ver con las reglas de la base de datos. La base de datos siempre pasa de un estado consistente a otro estado consistente;
• La consistencia de CAP es copiar datos entre múltiples servidores distribuidos para que estos servidores tengan los mismos datos. Debido a las limitaciones de velocidad de la red, el tiempo consumido por esta replicación en diferentes servidores no es fijo. El clúster organiza a los clientes para ver diferentes datos. el nodo que no se ha sincronizado mantiene una vista lógica, que es un concepto de coherencia en el campo distribuido;

En resumen:

La coherencia en ACID se refiere a la integridad de la base de datos antes y después de la ejecución de la transacción, mientras que la coherencia CAP se refiere a la coherencia de los datos en nodos distribuidos. Diferentes orígenes, sin comparación

4. Teorema básico

CAP es una teoría de diseño de sistemas distribuidos y BASE es una extensión de la solución AP en la teoría CAP. Los métodos y estrategias que adoptamos para C son garantizar la coherencia final;

El arquitecto de eBay, Dan Pritchett, publicó un artículo sobre ACM basado en su resumen práctico de sistemas distribuidos a gran escala y propuso la teoría BASE. La teoría BASE es una extensión de la teoría CAP. La idea central es que incluso si una consistencia fuerte (StrongConsistency, CAP) no puede ser logrado, la consistencia es una consistencia fuerte), pero las aplicaciones pueden lograr una consistencia eventual (consitencia eventual) de una manera adecuada.

4.1 Teorema BASE

BASE es un acrónimo de las tres frases Básicamente Disponible (básicamente disponible), Estado blando (estado blando) y Eventualmente consistente (consistencia final). BASE evolucionó basándose en el teorema CAP. La idea central es que no se puede lograr una consistencia fuerte de inmediato, pero cada aplicación puede adoptar métodos apropiados de acuerdo con sus propias características comerciales para lograr la consistencia final del sistema.

1. Básicamente disponible

基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分可用性，但不等于系统不可用。

(1) Pérdida en el tiempo de respuesta

当出现故障时，响应时间增加

(2) Pérdida funcional

   当流量高峰期时，屏蔽一些功能的使用以保证系统稳定性（服务降级）

2. Estado blando

Significa que se permite que los datos del sistema existan en un estado intermedio y se cree que la existencia de este estado intermedio no afectará la disponibilidad general del sistema.

A diferencia del estado duro, significa que se permite que los datos del sistema existan en un estado intermedio, y se cree que la existencia de este estado intermedio no afectará la disponibilidad general del sistema, es decir, el proceso de permitir que el sistema sincronice datos entre copias de datos de diferentes nodos se retrasa una hora.

3.Eventualmente consistente (eventualmente consistente)

Enfatice que todas las copias de datos en el sistema finalmente pueden alcanzar un estado consistente después de un período de sincronización. La esencia es que el sistema debe garantizar que los datos finales puedan ser coherentes y no es necesario garantizar una gran coherencia de los datos del sistema en tiempo real.

La consistencia final se puede dividir en los siguientes tipos:

(1) Consistencia causal (consistencia causal)
significa que el proceso A notifica al proceso B después de actualizar los datos, luego el rango de datos del proceso B será el último valor actualizado por el proceso A.
(2) Lea sus escrituras:
después de que el proceso A actualiza un dato, siempre puede acceder al último valor que ha actualizado.
(3) La coherencia de la sesión (consistencia de la sesión)
enmarca la coherencia de los datos en la sesión y logra la coherencia de la lectura y la escritura en una sesión. Es decir, después de ejecutar la actualización, el cliente siempre puede leer el último valor de los datos en la misma sesión
(4) Coherencia de lectura monótona (consistencia de lectura monótona)
Si un proceso lee un determinado valor de un elemento de datos del sistema Después de eso , el sistema no debe devolver un valor anterior para ningún acceso posterior a datos por parte del proceso.
(5) Consistencia de escritura monótona (Consistencia de escritura monotónica)
Un sistema necesita garantizar que las operaciones de escritura del mismo proceso se ejecuten secuencialmente.
La teoría BASE propone obtener disponibilidad sacrificando la coherencia y permite que los datos sean inconsistentes durante un período de tiempo, pero eventualmente alcanzan un estado consistente.

4.2 Características de la teoría BASE:

La teoría BASE está orientada a sistemas distribuidos escalables y altamente disponibles a gran escala, que es lo opuesto a las características ACID tradicionales de las cosas.

Es completamente diferente del modelo de consistencia fuerte de ACID, pero obtiene disponibilidad sacrificando una consistencia fuerte y permite que los datos sean inconsistentes durante un período de tiempo, pero eventualmente alcanza un estado consistente.

Pero al mismo tiempo, en escenarios distribuidos reales, diferentes unidades de negocios y componentes tienen diferentes requisitos de coherencia de datos, por lo que en el proceso de diseño de arquitectura de sistema distribuido específico, las características ACID y la teoría BASE a menudo se combinan.

4.3 La relación entre la teoría BASE y CAP

La teoría BASE es el resultado del equilibrio entre consistencia y disponibilidad en CAP, se deriva del resumen de prácticas distribuidas en sistemas de Internet a gran escala y evoluciona gradualmente sobre la base del teorema de CAP. La idea central de la teoría BASE es: incluso si no se puede lograr una coherencia sólida, cada aplicación puede adoptar métodos apropiados de acuerdo con sus propias características comerciales para lograr la coherencia final del sistema.

La teoría BASE es en realidad una extensión y complemento de la teoría CAP, principalmente de AP. Se sacrifica la fuerte coherencia de los datos para garantizar la disponibilidad de los datos. Aunque hay una carga intermedia, los datos finalmente son consistentes.

4.4 Diferencias y conexiones entre ACID y BASE

ACID es un concepto de diseño comúnmente utilizado en bases de datos tradicionales, que persigue un modelo de coherencia sólido. BASE admite sistemas distribuidos a gran escala y propone obtener alta disponibilidad sacrificando una fuerte coherencia.

ACID y BASE representan dos filosofías de diseño completamente opuestas. En el escenario del diseño de sistemas distribuidos, los componentes del sistema tienen diferentes requisitos de coherencia, por lo que ACID y BASE se utilizan juntos.

6. Clasificación de transacciones distribuidas

En un escenario distribuido, varios servicios atienden un proceso al mismo tiempo. Por ejemplo, en un escenario de pedido de comercio electrónico, se requiere un servicio de pago para pagar, un servicio de inventario para deducir el inventario y un servicio de pedido para generar Se requiere un pedido y un servicio de logística para actualizar la información de logística. Si un servicio no se ejecuta o la solicitud se pierde debido a una falla de la red, pueden ocurrir inconsistencias de datos en todo el sistema.

El escenario anterior es un problema de coherencia distribuida. En última instancia, la causa fundamental de la coherencia distribuida radica en la operación distribuida de los datos, lo que provoca transacciones locales que no pueden garantizar la atomicidad de los datos.

Hay dos formas de resolver el problema de coherencia distribuida: una son las transacciones distribuidas y la otra es tratar de evitar las transacciones distribuidas a través de procesos comerciales. Las transacciones distribuidas resuelven directamente los problemas, mientras que la evitación de negocios en realidad resuelve el problema (resolviendo a la persona que planteó el problema). De hecho, en escenarios comerciales reales, si evitar negocios no es muy problemático, la solución más elegante es evitar negocios.

Las soluciones de implementación de transacciones distribuidas se dividen en transacciones rígidas y transacciones flexibles en términos de tipo :

• Las transacciones rígidas satisfacen la teoría CP de CAP

• Las transacciones flexibles satisfacen la teoría BASE (básicamente disponibles, eventualmente consistentes)

6.1 Asuntos rígidos

Transacciones rígidas: por lo general, no hay transformación empresarial, gran coherencia, soporte nativo para reversión/aislamiento, baja concurrencia, adecuado para transacciones cortas.

Principio: Las transacciones rígidas satisfacen la teoría CP de CAP

Las transacciones rígidas se refieren a hacer que las transacciones distribuidas tengan una fuerte coherencia de datos como las transacciones locales, desde la perspectiva de CAP, es decir, alcanzar el estado CP.

Transacciones rígidas: protocolo XA (2PC, JTA, JTS), 3PC, pero debido al bloqueo de sincronización y la baja eficiencia de procesamiento, no son adecuados para escenarios distribuidos de sitios web grandes.

6.2 Transacciones flexibles

Las transacciones flexibles no requieren una consistencia fuerte, pero sí una consistencia final, permitiendo estados intermedios, que es la teoría Base, en otras palabras, el estado AP.

En comparación con las transacciones rígidas, las características de las transacciones flexibles son: transformación empresarial, máxima coherencia, implementación de interfaz de compensación, implementación de interfaz de bloqueo de recursos, alta concurrencia y adecuada para transacciones largas.

Las transacciones flexibles se dividen en:

• Tipo de compensación
• Asincrónico garantizado
• Tipo de notificación de mejor esfuerzo.

Transacciones flexibles: TCC/FMT, Saga (modo máquina de estado, modo Aop), mensajes de transacciones locales, transacciones de mensajes (semimensaje)

6.3 Transacciones rígidas: modelo XA, especificación de interfaz XA, implementación XA

6.3.1, modelo XA o modelo X/Open DTP

X/OPEN es una organización. X/Open International Alliance Ltd. es una fundación europea establecida para proporcionar estándares para el entorno UNIX. Su principal objetivo es promover el desarrollo de protocolos de sistemas abiertos para lenguajes, interfaces, redes y aplicaciones UNIX. También promueve la interoperabilidad de aplicaciones entre diferentes entornos UNIX y es compatible con la especificación de interfaz de sistema operativo portátil (POSIX) del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) para UNIX.

X/Open DTP (Proceso de transacciones distribuidas) es un modelo de transacciones distribuidas. Este modelo utiliza principalmente confirmación de dos fases (2PC - Two-Phase-Commit) para garantizar la integridad de las transacciones distribuidas.

En el modelo X/Open DTP (Proceso de transacciones distribuidas), existen tres roles:

• AP: Aplicación, aplicación. Esa es la capa empresarial. AP define qué operaciones pertenecen a una transacción.

• TM: Administrador de transacciones, administrador de transacciones. Reciba solicitudes de transacciones AP, administre transacciones globales, administre el estado de las sucursales de transacciones, coordine el procesamiento de RM, notifique a RM qué operaciones pertenecen a qué transacciones globales y sucursales de transacciones, etc. Esta es también la parte central de todo el modelo de programación de transacciones.

• RM: Administrador de recursos, administrador de recursos. Por lo general, es una base de datos, pero también pueden ser otros administradores de recursos, como colas de mensajes (como fuentes de datos JMS), sistemas de archivos, etc.

XA divide los roles involucrados en la transacción en AP, RM y TM.

AP, es decir, aplicación, es nuestro servicio comercial.

RM se refiere al administrador de recursos, es decir, DB, MQ, etc.

TM es el administrador de transacciones.

El AP opera el TM por sí mismo. Cuando se necesita una transacción, el AP solicita al TM que inicie una transacción, y el TM es responsable del envío, reversión, etc. de toda la transacción.

La especificación XA define principalmente la interfaz entre el Administrador de transacciones (global) y el Administrador de recursos (local). La interfaz XA es una interfaz de sistema bidireccional que forma un puente de comunicación entre el Administrador de transacciones y uno o más Administradores de recursos.

La razón por la que XA necesita introducir un administrador de transacciones es porque, en teoría, en un sistema distribuido (consulte el artículo de Fischer et al.), dos máquinas teóricamente no pueden alcanzar un estado consistente y es necesario introducir un solo punto para la coordinación. . El administrador de transacciones controla las transacciones globales, gestiona el ciclo de vida de las transacciones y coordina los recursos. El administrador de recursos es responsable de controlar y administrar los recursos reales (como bases de datos o colas JMS)

6.3.2, especificación XA

¿Qué es XA?

En términos muy oficiales:

• La especificación XA es un estándar de procesamiento de transacciones distribuidas (DTP) definido por la organización X/Open.

• La especificación XA describe la interfaz entre el administrador de transacciones global y el administrador de recursos local. El propósito de la especificación XA es permitir el acceso a múltiples recursos (como bases de datos, servidores de aplicaciones, colas de mensajes, etc.) en la misma transacción, de modo que las propiedades ACID sigan siendo válidas en todas las aplicaciones.

• La especificación XA utiliza un protocolo de confirmación de dos fases (2PC, confirmación de dos fases) para garantizar que todos los recursos confirmen o reviertan cualquier transacción en particular al mismo tiempo.

• La especificación XA se propuso a principios de los años 1990. Actualmente, casi todas las bases de datos convencionales admiten la especificación XA.

La especificación XA (especificación XA) es una especificación de procesamiento de transacciones distribuidas propuesta por X/OPEN. XA estandariza la interfaz de comunicación entre TM y RM y forma un puente de comunicación bidireccional entre TM y múltiples RM, garantizando así las cuatro características de ACID en múltiples recursos de bases de datos. En la actualidad, todas las bases de datos conocidas, como Oracle, DB2, mysql, etc., implementan la interfaz XA y pueden usarse como RM.

XA es una transacción distribuida de la base de datos, con una fuerte coherencia. Durante todo el proceso, los datos están en un estado bloqueado, es decir, durante todo el proceso desde la preparación hasta la confirmación y la reversión, TM sigue manteniendo el bloqueo de la base de datos. alguien más quiere modificar este dato en la base de datos, debe esperar a que se libere el bloqueo y existe el riesgo de transacciones largas.

Las siguientes funciones permiten al administrador de transacciones realizar operaciones en el administrador de recursos:
1) xa_open, xa_close: establece y cierra la conexión con el administrador de recursos.
2)xa_start,xa_end: inicia y finaliza una transacción local.
3) xa_prepare, xa_commit, xa_rollback: confirmación previa, confirmación y reversión de una transacción local.
4) xa_recover: revertir una transacción previamente confirmada.
5) Las funciones que comienzan con ax_ permiten que el administrador de recursos se registre dinámicamente en el administrador de transacciones y opere en XID (TRANSACTION IDS).
6) ax_reg, ax_unreg; permite que un administrador de recursos se registre o cancele el registro dinámicamente en un TMS (TRANSACTION MANAGER SERVER).

El flujo de procesamiento de cada etapa de XA.

6.3.3 Implementación del protocolo XA

Protocolo 2PC/3PC

El protocolo de confirmación de dos fases (2PC) es un protocolo de coherencia de datos definido por la especificación XA.

El protocolo de confirmación de tres fases (3PC) es una extensión del protocolo 2PC.

Colocar

Seata es una solución de transacciones distribuidas de código abierto dedicada a proporcionar servicios de transacciones distribuidas de alto rendimiento y fáciles de usar bajo una arquitectura de microservicio. Seata proporcionará a los usuarios modos de transacción AT, TCC, SAGA y XA

Antes de que Seata fuera de código abierto, la versión interna correspondiente de Seata había desempeñado el papel de middleware distribuido y consistente dentro de la economía de Alibaba, ayudando a la economía a sobrevivir al Doble 11 a lo largo de los años y brindando un fuerte apoyo para el negocio de cada BU. El producto comercial GTS se vendió en Alibaba Cloud y Financial Cloud.

especificación jta

Como especificación de transacción en la plataforma Java, JTA (Java Transaction API) también define el soporte para transacciones XA. De hecho, JTA está modelado en base a la arquitectura XA. En JTA, el administrador de transacciones se abstrae como interfaz javax.transaction.TransactionManager, Y se implementa a través del servicio de transacciones subyacente (es decir, JTS). Como muchas otras especificaciones de Java, JTA solo define interfaces y los proveedores (como los proveedores de J2EE) proporcionan implementaciones específicas. Actualmente, las implementaciones de JTA incluyen principalmente lo siguiente: 1. Implementación de JTA proporcionada por contenedores J2EE (JBoss) 2. Implementación de
JTA
independiente : como JOTM, Atomikos.

Estas implementaciones se pueden utilizar en entornos que no utilizan un servidor de aplicaciones J2EE para proporcionar garantías de transacciones distribuidas. Como Tomcat, Jetty y aplicaciones java ordinarias.

especificación JTS

Las transacciones son una parte esencial de la programación, en base a esto, para estandarizar el desarrollo de transacciones, Java ha agregado especificaciones sobre transacciones, a saber, JTA y JTS.

JTA define un conjunto de interfaces, en las que se acuerdan varios roles principales: TransactionManager, UserTransaction, Transaction, XAResource, y define las especificaciones que deben seguirse entre estos roles, como la delegación de Transaction a TransactionManager.

JTS también es un conjunto de especificaciones. Como se mencionó anteriormente, JTA requiere interacción entre roles, ¿cómo deberían interactuar? JTS es una especificación que especifica los detalles de la interacción.

En términos generales, JTA se trata más de acordar la interfaz de las funciones del programa desde la perspectiva del marco, mientras que JTS se trata de acordar la interfaz entre las funciones del programa desde la perspectiva de una implementación específica, y ambos cumplen con sus funciones.

Implementación de transacciones distribuidas de Atomikos

Atomikos tiene dos productos comerciales distribuidos muy conocidos:

TransactionEssentials: producto gratuito de código abierto
ExtremeTransactions: versión comercial, requiere una tarifa.
La relación entre estos dos productos se muestra en la siguiente figura:

Como puede ver, la versión de código abierto admite transacciones JTA/XA, JDBC y JMS.

atomikos también admite la integración con transacciones de primavera.

La abstracción de nivel superior del administrador de transacciones de Spring es la interfaz PlatformTransactionManager, que proporciona una clase de implementación importante:

DataSourceTransactionManager: utilizado para implementar transacciones locales
JTATransactionManager: utilizado para implementar transacciones distribuidas
Obviamente, aquí lo que necesitamos configurar es JTATransactionManager.

public class JTAService {
    
      
    @Autowired   
    private UserMapper userMapper;//操作db_user库   
    @Autowired  
    private AccountMapper accountMapper;//操作db_account库  

    @Transactional   
    public void insert() {
    
        
        User user = new User();     
        user.setName("wangxiaoxiao");     
        userMapper.insert(user);  
        //模拟异常，spring回滚后，db_user库中user表中也不会插入记录     
        Account account = new Account();     
        account.setUserId(user.getId());    
        account.setMoney(123456789);    
        accountMapper.insert(account); 
    }
}

Principales limitaciones de XA

Se deben obtener todas las fuentes de datos, y las fuentes de datos también deben admitir el protocolo XA. Actualmente, sólo el motor de almacenamiento InnoDB admite el protocolo XA en MySQL.
El rendimiento es relativamente pobre, todos los datos involucrados deben estar bloqueados, es muy consistente y se generarán transacciones largas.

Modo Seata AT

El modo Seata AT es un modo mejorado de 2 piezas.

Modo AT: la evolución del protocolo de confirmación de dos fases, sin bloquear la tabla todo el tiempo

Fase 1: los datos comerciales y los registros de reversión se confirman en la misma transacción local, lo que libera bloqueos locales y recursos de conexión.
Fase 2: la confirmación es asincrónica y se completa muy rápidamente. O revertir la compensación inversa a través de un registro de reversión de una etapa

LCN (2 unidades)

TX-LCN, documento oficial, github, más de 3000 estrellas, dado que el marco es compatible con los modos de transacción LCN (2pc), TCC y TXC después de 5.0, para distinguir el modo LCN, la transacción distribuida LCN pasa a llamarse Marco empresarial de distribución TX-LCN.

TX-LCN se posiciona como un marco de coordinación de transacciones: el marco en sí no genera transacciones, sino que coordina las transacciones locales, logrando así la coherencia de las transacciones.

TX-LCN tiene principalmente dos módulos, Tx-Client(TC) y Tx-Manager™.

TM (Tx-Manager): es un servicio independiente. Es el controlador de transacciones distribuidas. Coordina el envío y la reversión de transacciones distribuidas. TC (Tx-Client): integrado
por el sistema empresarial, el iniciador de la transacción y los participantes son todo controlado por TxClient.control de terminal

6.4, 2PC (modelo XA estándar)

2PC es un compromiso de dos fases, un compromiso de dos fases.

6.4.1 Explicación detallada: dos etapas

Se usa ampliamente en el campo de las bases de datos para garantizar que todos los nodos basados ​​​​en la arquitectura distribuida puedan mantener la atomicidad y la coherencia al procesar transacciones. La mayoría de las bases de datos relacionales completan el procesamiento de transacciones distribuidas basado en 2PC.

Como sugiere el nombre, 2PC se divide en dos etapas de procesamiento: etapa uno: enviar la solicitud de transacción, etapa dos: ejecutar el envío de la transacción;

Si la fase uno caduca o se produce una excepción, 2PC fase dos: interrumpe la transacción

Fase 1: enviar solicitud de transacción

Preguntas de negocios. El coordinador envía el contenido de la transacción a todos los participantes, pregunta si se puede realizar la operación de confirmación y comienza a esperar a que cada participante responda;
ejecuta la transacción. Cada nodo participante realiza operaciones de transacción y cuenta las operaciones de Deshacer y Rehacer en el registro de transacciones local;
cada participante devuelve la respuesta a la consulta de transacción al coordinador. Devuelve Sí si se ejecuta correctamente; en caso contrario, devuelve No.

Fase 2: ejecutar el envío de la transacción

El coordinador decide en la fase dos si finalmente ejecuta la operación de confirmación de la transacción. Esta etapa incluye dos situaciones:

Ejecutar compromiso de transacción

Todos los participantes responden Sí, luego se ejecuta la confirmación de la transacción.

Envíe una solicitud de confirmación. El coordinador envía una solicitud de compromiso a todos los participantes;
la transacción se confirma. Después de recibir la solicitud de confirmación, el participante realizará formalmente la operación de envío de la transacción y, después de completar la operación de envío, liberará los recursos ocupados durante toda la ejecución de la transacción y enviará comentarios sobre los resultados del envío de la transacción
. Después de que el participante completa el envío de la transacción, el coordinador de redacción envía un mensaje de confirmación para confirmar;
la transacción se completa. El coordinador completa la transacción después de recibir el Ack de todos los participantes.

Fase 2: Interrupción de la transacción

Las cosas siempre salen mal cuando uno de los participantes envía un No respuesta al coordinador o se agota el tiempo de espera. El coordinador abortará la transacción siempre que no pueda recibir respuestas Sí de todos los participantes.

Enviar una solicitud de reversión. El coordinador envía una solicitud de Rollback a todos los participantes;
rollback. Después de recibir la solicitud, el participante utiliza la información de Deshacer local para realizar la operación de Reversión. Y una vez finalizada la reversión, libere los recursos del sistema ocupados por la transacción;
envíe información sobre el resultado de la reversión. Una vez que el participante completa la operación de reversión, envía un mensaje de confirmación al coordinador;
la transacción se interrumpe. Una vez que el coordinador recibe el mensaje Ack de reversión de todos los participantes, se completa la interrupción de la transacción.

6.4.2, 2pc resuelve el problema de la fuerte coherencia de los datos distribuidos

Como sugiere el nombre, el envío de dos fases se divide en dos etapas cuando se procesan transacciones distribuidas: votación (etapa de votación, a veces llamada etapa de preparación) y etapa de confirmación.

Hay dos roles en 2pc, coordinador de transacciones (seata, atomikos, lcn) y participantes de la transacción. Los participantes de la transacción generalmente se refieren a la base de datos de la aplicación.

6.4.3 Características de la presentación 2PC de segunda etapa

La solución 2PC es más adecuada para una sola aplicación.

En la solución 2PC, existe un rol de administrador de transacciones, que es responsable de coordinar las transacciones de múltiples bases de datos (administradores de recursos). El administrador de transacciones primero pregunta a cada base de datos si está lista. Si cada base de datos responde que está bien, entonces la transacción se envía oficialmente y se realizan operaciones en cada base de datos; si alguna de las bases de datos responde que no está bien, entonces la transacción se revierte.

La solución 2PC es más adecuada para transacciones distribuidas en múltiples bibliotecas en una sola aplicación y, debido a que depende en gran medida del nivel de la base de datos para manejar transacciones complejas, la eficiencia es muy baja y definitivamente no es adecuada para escenarios de alta concurrencia.

La solución 2PC rara vez se utiliza en la práctica. En términos generales, si dicha operación ocurre en varias bibliotecas dentro de un sistema, es ilegal. Puedo presentarles, ahora microservicios, un gran sistema se divide en cientos de servicios, docenas de servicios. En términos generales, nuestras normativas y especificaciones exigen que cada servicio sólo pueda operar con su propia base de datos correspondiente.

Si desea operar las bibliotecas correspondientes a otros servicios, no se permite la conexión directa a las bibliotecas de otros servicios, lo que viola las especificaciones de la arquitectura de microservicios. Si cruza y accede a cientos de servicios a voluntad, todo se arruinará. arriba Tal conjunto de servicios no puede Si no se puede administrar o administrar, puede suceder que otros corrijan los datos, o que otros anoten su propia base de datos, etc.

Si desea operar la biblioteca de los servicios de otras personas, debe hacerlo llamando a la interfaz de otros servicios. El acceso cruzado a las bases de datos de otras personas no está permitido en absoluto.

2PC tiene ventajas y desventajas obvias:

Las ventajas se reflejan principalmente en el sencillo principio de implementación;
existen muchas desventajas:

• Durante la ejecución del envío 2PC, toda la lógica involucrada en la operación de la transacción está en un estado bloqueado, es decir, cada participante está esperando la respuesta de los demás participantes y no puede realizar otras operaciones;

• El coordinador es un punto único: una vez que ocurre un problema, otros participantes no podrán liberar recursos de transacción y completar operaciones de transacción;

• Los datos son inconsistentes. Al ejecutar el envío de transacciones, si se produce una excepción en la red local después de que el coordinador envía una solicitud de confirmación a todos los participantes o el coordinador no ha terminado de enviar la solicitud de confirmación, se bloqueará y solo algunos participantes recibirán y ejecutarán la solicitud. Como resultado, se producirán inconsistencias en los datos en todo el sistema;

• mantener. 2PC no tiene un mecanismo completo de tolerancia a fallas. Cuando un participante falla, el coordinador no puede aprender rápidamente sobre la falla y solo puede confiar estrictamente en la configuración del tiempo de espera para decidir si ejecutar más la confirmación o interrumpir la transacción.

De hecho, las transacciones distribuidas son un asunto muy complejo. El compromiso de dos fases solo resuelve el problema de que una transacción en un sistema distribuido necesita abarcar múltiples nodos de servicio agregando la función del coordinador de transacciones (Coordinador) a través de un proceso de procesamiento de dos etapas. ... problemas de coherencia de los datos. Sin embargo, considerando situaciones anormales, este proceso no es tan impecable.

Supongamos que en la segunda fase, si el Coordinador cuelga después de recibir la "Solicitud de voto" del Participante o hay una anomalía en la red, entonces el nodo del Participante siempre estará en un estado de suspensión de transacciones locales, ocupando así recursos durante mucho tiempo. . Por supuesto, esta situación sólo ocurrirá en casos extremos, pero como sistema de software robusto, el manejo de casos de excepción es la prueba real de la corrección de la solución.

Para resumir: algunos problemas encontrados en el protocolo de confirmación de dos fases XA

Problemas de desempeño

Del proceso podemos ver que su mayor desventaja es que los nodos quedan bloqueados en medio de su ejecución. Cada nodo que opera la base de datos ocupa recursos de la base de datos en este momento. Solo cuando todos los nodos estén listos, el coordinador de transacciones notificará la confirmación global y los recursos se liberarán solo después de que los participantes confirmen las transacciones locales. Un proceso de este tipo llevará mucho tiempo y tendrá un gran impacto en el rendimiento.

Problema de punto único de falla del coordinador

El coordinador de transacciones es el núcleo de todo el modelo XA. Una vez que el nodo del coordinador de transacciones cuelga, los participantes no recibirán la notificación de confirmación o reversión, y los nodos participantes siempre estarán en un estado intermedio donde la transacción no se puede completar.

Inconsistencia de datos causada por mensajes faltantes

En la segunda etapa, si ocurre un problema en la red local, algunos participantes de la transacción reciben el mensaje de confirmación y los otros participantes de la transacción no reciben el mensaje de confirmación, lo que provocará inconsistencia de datos entre los nodos.

6,5 、 3 piezas

En vista de las deficiencias de 2PC, los investigadores propusieron 3PC, es decir, Three-Phase Commit.

Como versión mejorada de 2PC, 3PC vuelve a dividir el proceso original de dos etapas en tres etapas: CanCommit, PreCommit y do Commit.

6.5.1 Explicación detallada: tres etapas

Fase 1: Puede comprometerse

Preguntas de negocios. El coordinador envía una solicitud canCommit que contiene el contenido de la transacción a todos los participantes, pregunta si la transacción se puede confirmar y espera una respuesta;
cada participante responde a la consulta de la transacción. En circunstancias normales, si el participante cree que la transacción se puede ejecutar sin problemas, se devuelve Sí; de lo contrario, se devuelve No.

Fase 2: Precompromiso

En esta fase, el coordinador decidirá si realiza la operación PreCommit de la transacción en función de los comentarios de la fase anterior. Hay dos posibilidades:

Ejecutar transacción previa al compromiso

Envíe una solicitud de confirmación previa. El coordinador emite una solicitud de PreCommit a todos los nodos y entra en la fase de preparación;

Precompromiso de transacción. Después de recibir la solicitud de PreCommit, el participante realizará la operación de transacción y escribirá los registros de Deshacer y Rehacer en el registro de transacciones local;

Cada participante ejecuta con éxito la operación de transacción y, al mismo tiempo, envía comentarios al coordinador en forma de respuesta Ack, y los colegas esperan la instrucción final de confirmación o cancelación.

interrumpir transacción

Únase a cualquier participante para enviar una respuesta No al coordinador, o espere un tiempo de espera, y el coordinador puede interrumpir la transacción cuando no recibe una respuesta de todos los participantes:

Enviar una solicitud de interrupción. El coordinador envía una solicitud de cancelación a todos los participantes;

Interrumpir transacción. Ya sea que reciba una solicitud de cancelación del coordinador o se agote el tiempo de espera mientras espera la solicitud del coordinador, los participantes interrumpirán la transacción;

Fase 3: comprometerse

En esta etapa, la transacción realmente se confirmará y existen dos posibilidades.

Ejecutar compromiso

Envíe una solicitud de confirmación. Si el coordinador recibe respuestas Ack de todos los participantes, pasará del estado de precompromiso al de compromiso y enviará solicitudes de doCommit a todos los participantes;

Compromiso de transacción. Después de recibir la solicitud doCommit, el participante ejecutará formalmente la operación de confirmación de la transacción y liberará los recursos ocupados una vez completada la operación de confirmación;

Resultados del envío de transacciones de comentarios. El participante enviará un mensaje de confirmación al coordinador después de completar el envío de la transacción;

Complete la transacción. Una vez que el coordinador recibe los mensajes de confirmación de todos los participantes, se completa la transacción.

interrumpir transacción

En esta etapa, suponiendo que el coordinador en el estado normal reciba una respuesta No de cualquier participante, o no reciba un mensaje de retroalimentación dentro del período de tiempo de espera, la transacción se interrumpirá:

Enviar una solicitud de interrupción. El coordinador envía una solicitud de cancelación a todos los participantes;

Reversión de transacciones. Después de recibir la solicitud de cancelación, el participante utilizará el mensaje Deshacer en la fase 2 para realizar la reversión de la transacción y liberar los recursos ocupados después de completar la reversión;

Resultados de reversión de transacciones de comentarios. El participante envía un mensaje de confirmación al coordinador después de completar la reversión;

Asuntos de rango medio. Una vez que el coordinador recibe el mensaje Ack devuelto por todos los participantes, se completa la interrupción de la transacción.

6.5.2 La diferencia entre 2PC y 3PC:

3PC reduce efectivamente el rango de bloqueo de participantes causado por 2PC y puede continuar llegando a un consenso después de un único punto de falla; sin embargo,
3PC trae nuevos problemas. Después de que los participantes reciben el mensaje previo al compromiso, si la red está particionada, el coordinador no puede comunicarse posteriormente. se llevará a cabo con los participantes. En este caso, los participantes seguirán realizando el envío de la transacción después de esperar el tiempo de espera, lo que provocará inconsistencia en los datos.

La diferencia entre 2PC y 3PC:

El protocolo de confirmación de tres fases introduce un mecanismo de tiempo de espera tanto para el coordinador como para los participantes, y divide la primera fase del protocolo de confirmación de dos fases en dos pasos: consultar, luego bloquear el recurso y finalmente confirmar. Las tres fases del compromiso de tres fases son: can_commit, pre_commit, do_commit.

En la fase de doCommit, si el participante no puede recibir la solicitud de doCommit o de cancelación del coordinador a tiempo, continuará confirmando la transacción después de esperar el tiempo de espera. (De hecho, esto debe decidirse en función de la probabilidad. Al ingresar a la tercera etapa, significa que el participante ha recibido la solicitud de PreCommit en la segunda etapa. Entonces, el requisito previo para que el coordinador genere la solicitud de PreCommit es que reciba la solicitud de PreCommit solicitud antes de que comience la segunda etapa. La respuesta de CanCommit a todos los participantes es Sí. (Una vez que un participante recibe el PreCommit, significa que sabe que todos realmente están de acuerdo con la modificación). Por lo tanto, en una oración, al ingresar a la tercera etapa, debido debido al tiempo de espera de la red y otras razones, aunque el participante no recibe una respuesta de confirmación o cancelación, pero tiene motivos para creer que la probabilidad de un envío exitoso es alta).

​

El problema de punto único de falla que resuelve principalmente 3PC:

En comparación con 2PC, 3PC resuelve principalmente el problema del punto único de falla y reduce el bloqueo, porque una vez que un participante no puede recibir información del coordinador a tiempo, ejecutará la confirmación de forma predeterminada. En lugar de retener recursos de transacciones y estar bloqueado todo el tiempo.

Sin embargo, este mecanismo también puede causar problemas de coherencia de los datos porque, debido a razones de red, los participantes no reciben a tiempo la respuesta de aborto enviada por el coordinador y luego los participantes realizan la operación de confirmación después de esperar el tiempo de espera. De esta manera, existe una inconsistencia de datos entre otros participantes que recibieron el comando de cancelación y realizaron la reversión.

"¿Cuál es la optimización de 3PC en comparación con 2PC?"
En comparación con 2PC, 3PC tiene tiempos de espera establecidos tanto para el coordinador (Coordinador) como para los participantes (Participante), mientras que 2PC solo tiene un mecanismo de tiempo de espera para el coordinador. ¿Qué problema resuelve esto?

Este punto de optimización evita principalmente el problema de que los participantes no puedan liberar recursos cuando no pueden comunicarse con el nodo coordinador durante mucho tiempo (el coordinador cuelga), porque los propios participantes tienen un mecanismo de tiempo de espera que continuará automáticamente después del tiempo de espera. Compromiso local para liberar recursos. Este mecanismo también reduce el tiempo de bloqueo y el alcance de toda la transacción.

Además, a través del diseño de las tres etapas de CanCommit, PreCommit y DoCommit, en comparación con 2PC, se configura una etapa de búfer adicional para garantizar que el estado de cada nodo participante sea consistente antes de la etapa de envío final.

Lo anterior es una mejora de 3PC en comparación con 2PC (alivia relativamente los dos primeros problemas en 2PC), pero 3PC aún no resuelve completamente el problema de la inconsistencia de los datos. Si durante el proceso DoCommit, el participante A no puede recibir la comunicación del coordinador, entonces el participante A enviará automáticamente, pero el envío falla y otros participantes tienen éxito, y los datos serán inconsistentes en este momento.

6.6 Problemas con las especificaciones XA

Sin embargo, la especificación XA apareció en 1994 y no se ha vuelto popular a gran escala. Debe tener ciertos defectos:

• Bloqueo de datos: antes de que finalice la transacción, los datos se bloquean de acuerdo con el nivel de aislamiento de datos para garantizar la coherencia.

• Bloqueo de protocolo: las transacciones locales se bloquean y esperan hasta que la transacción global se confirme o vuelva a llamar.

• Pérdida de alto rendimiento: se refleja principalmente en el aumento del costo de RT de la coordinación de transacciones, y los datos de transacciones concurrentes utilizan bloqueos para competir y bloquear.

El protocolo XA es relativamente simple y una vez que la base de datos comercial implementa el protocolo XA, el costo de utilizar transacciones distribuidas es relativamente bajo. Sin embargo, XA también tiene un defecto fatal, es decir, su rendimiento no es ideal, especialmente en el enlace de orden de transacción, la cantidad de concurrencia suele ser muy alta y XA no puede cumplir con escenarios de alta concurrencia. Actualmente, XA se admite idealmente en bases de datos comerciales, pero no es ideal en bases de datos mysql. La implementación XA de MySQL no registra registros de la fase de preparación y el cambio entre las bases de datos activas y en espera genera inconsistencia de datos entre las bases de datos activas y en espera. Muchos nosql tampoco son compatibles con XA, lo que hace que los escenarios de aplicación de XA sean muy limitados.

De hecho, no es innecesario. Por ejemplo, muchos recursos cruzados basados ​​​​en CICS en mainframes IBM son transacciones distribuidas basadas en el protocolo XA. De hecho, XA también es un estándar para el procesamiento de transacciones distribuidas, pero rara vez se usa en el Internet La razón es que existen los siguientes:

• Rendimiento (protocolos de bloqueo, mayores tiempos de respuesta, tiempos de bloqueo, puntos muertos);
• Completitud del soporte de la base de datos (había defectos antes de MySQL 5.7);
• El coordinador se basa en middleware J2EE independiente (primero el peso pesado Weblogic, Jboss, luego el liviano Atomikos, Narayana y Bitronix);
• La operación y el mantenimiento son complejos y los DBA carecen de experiencia en esta área;
• No todos los recursos admiten el protocolo XA;

Para ser precisos, XA es una especificación y un protocolo. Simplemente define una serie de interfaces. Sin embargo, la mayoría de las implementaciones actuales de XA son bases de datos o MQ, por lo que cuando se menciona XA, a menudo se refiere a la solución de transacción distribuida subyacente basada en la capa de recursos. De hecho, algunos marcos de fragmentación de datos o middleware ahora también admiten el protocolo XA; después de todo, su compatibilidad y universalidad son mejores.

6.7 Clasificación de transacciones flexibles

En escenarios de Internet como el comercio electrónico, las transacciones rígidas han expuesto cuellos de botella en el rendimiento y las capacidades de procesamiento de las bases de datos.

Las transacciones flexibles tienen dos características: estado básicamente disponible y flexible.

• Disponibilidad básica significa que se permite perder una parte de la disponibilidad cuando falla el sistema distribuido.

• El estado flexible se refiere a permitir que el sistema exista en un estado intermedio, que no afectará la disponibilidad general del sistema, como el retraso en la sincronización maestro-esclavo de la separación de lectura y escritura de la base de datos, etc. La coherencia de las transacciones flexibles se refiere a la coherencia eventual.

Las transacciones flexibles se dividen principalmente en tipo de compensación y tipo de notificación.

Los asuntos compensatorios se dividen en: TCC, Saga;

La transacción de tipo de notificación se divide en: mensaje de transacción MQ, tipo de notificación de mejor esfuerzo.

Las transacciones de compensación son sincrónicas y las transacciones de notificación son asincrónicas.

6.8 Transacciones de notificación

La implementación principal de las transacciones de tipo notificación es notificar a otros participantes de la transacción sobre el estado de ejecución de sus propias transacciones a través de MQ (Cola de mensajes). Los componentes de MQ se introducen para desacoplar efectivamente a los participantes de la transacción. Cada participante puede ejecutar de forma asincrónica, por lo que las transacciones de tipo notificación Las transacciones también se denominan transacciones asincrónicas.

Las transacciones de tipo notificación son principalmente adecuadas para escenarios que requieren actualizaciones de datos asíncronas y tienen bajos requisitos de datos en tiempo real, que incluyen principalmente:

Hay dos tipos de transacciones garantizadas asincrónicas y transacciones de notificación de mejor esfuerzo.

• Transacciones garantizadas asincrónicas: Principalmente adecuadas para garantizar la coherencia final de los datos en los sistemas internos, porque los internos son relativamente controlables, como pedidos y carritos de compras, recepción y compensación, pago y liquidación, etc.;

• Notificación de mejor esfuerzo: se utiliza principalmente para sistemas externos, debido a que el entorno de la red externa es más complejo y poco confiable, por lo que solo podemos hacer nuestro mejor esfuerzo para notificar para lograr la coherencia de los datos finales, como plataformas y operadores de recarga, acoplamiento de pagos, etc. en toda la red. acoplamiento de niveles del sistema;

6.9 Transacciones garantizadas asíncronas

Se refiere a modificar una serie de operaciones de transacciones sincrónicas en operaciones asincrónicas basadas en colas de mensajes para evitar la degradación del rendimiento de las operaciones de datos causada por el bloqueo sincrónico en transacciones distribuidas.

6.9.1, esquema de mensajes de transacciones MQ

El esquema de mensajes de transacciones basado en MQ se basa principalmente en el mecanismo de semimensaje de MQ para garantizar la coherencia de los mensajes de entrega y las transacciones locales de los propios participantes. El principio de implementación del mecanismo de semimensaje en realidad se basa en la idea de 2PC, que es una amplia expansión del envío de dos fases.

Medio mensaje: la lógica después de que se ejecuta el mensaje de la cola original. Si la lógica local posterior comete un error, el mensaje no se enviará. Si se aprueba, se informará a MQ para que lo envíe;

proceso

• El iniciador de la transacción primero envía medio mensaje a MQ;
• MQ notifica al remitente que el mensaje se envió correctamente;
• Ejecute la transacción local después de enviar la mitad del mensaje con éxito;
• Devolver confirmación o reversión según el resultado de la ejecución de la transacción local;
• Si el mensaje se revierte, MQ lo descartará y no lo entregará; si se confirma, MQ enviará el mensaje al suscriptor del mensaje;
• El suscriptor realiza transacciones locales basadas en el mensaje;
• Después de que el suscriptor ejecute con éxito la transacción local, el mensaje se marcará como consumido desde MQ;
• Si el final de la ejecución cuelga o se agota el tiempo de espera durante la ejecución de una transacción local, el servidor MQ solicitará continuamente al productor que obtenga el estado de la transacción;
• El mecanismo de éxito del consumo por parte del Consumidor está garantizado por MQ;

6.9.2 Ejemplos de uso de transacciones garantizadas asíncronas

Por ejemplo, supongamos que hay una regla comercial: después de que un determinado pedido se realice correctamente, se agregará una cierta cantidad de puntos al usuario.

En esta regla, el servicio que gestiona la fuente de datos del pedido es el iniciador de la transacción y el servicio que gestiona la fuente de datos de los puntos es el seguidor de la transacción.

De este proceso, podemos ver que las transacciones implementadas en función de la cola de mensajes tienen las siguientes operaciones:

• El servicio de pedidos crea pedidos y envía transacciones locales.
• El servicio de pedidos publica un mensaje.
• El servicio de puntos suma puntos después de recibir el mensaje.

Podemos ver que su proceso general es relativamente simple y la carga de trabajo de desarrollo empresarial no es grande:

Escriba la lógica de creación de pedidos en el servicio de pedidos
Escriba la lógica de agregar puntos en el servicio de puntos,
puede ver que el proceso del formulario de transacción es simple, el consumo de rendimiento es pequeño, los picos y valles de tráfico entre el iniciador y el seguidor pueden estar lleno de colas y trabajo de desarrollo empresarial El volumen es básicamente el mismo que el de una transacción independiente y no es necesario escribir un proceso de lógica empresarial inversa.

Por lo tanto, las transacciones implementadas en función de colas de mensajes son nuestra principal prioridad, además de las transacciones independientes.

6.9.3 Implementar transacciones garantizadas asincrónicas MQ basadas en Alibaba RocketMQ

Algunos MQ de terceros admiten mensajes transaccionales y estas colas de mensajes admiten mecanismos de medio mensaje, como RocketMQ y ActiveMQ. Sin embargo, algunos MQ de uso común no admiten mensajes de transacciones, como RabbitMQ y Kafka.

Tomando el middleware RocketMQ de Alibaba como ejemplo, la idea es aproximadamente la siguiente:

1. El productor (sistema A en este ejemplo) envía un medio mensaje al intermediario. Este medio mensaje no significa que el contenido del mensaje esté incompleto. Contiene el contenido completo del mensaje. La lógica de envío del El lado del productor es consistente con el de los mensajes ordinarios.

2. El intermediario almacena medios mensajes. La lógica de almacenamiento de medios mensajes es la misma que la de los mensajes normales, pero los atributos son diferentes. El tema se fija en RMQ_SYS_TRANS_HALF_TOPIC y el queueId también se fija en 0. Los mensajes en esta foto son invisibles para los consumidores, por lo que los Mensajes nunca se consumen. Esto garantiza que los consumidores no podrán consumir el medio mensaje antes de que se envíe correctamente.

3. Una vez que el medio mensaje en el lado del corredor se almacena y devuelve con éxito, el sistema A ejecuta la transacción local y determina el estado de envío del medio mensaje como confirmación o reversión de acuerdo con el resultado de la ejecución de la transacción local.

4. El sistema A envía una solicitud para finalizar el medio mensaje y muestra el estado de envío (enviar o revertir)

5. Después de recibir la solicitud, el corredor primero verifica el mensaje de la cola de RMQ_SYS_TRANS_HALF_TOPIC y lo establece en el estado completado. Si se envía el estado del mensaje, copie la mitad del mensaje de la cola RMQ_SYS_TRANS_HALF_TOPIC a la cola del tema original del mensaje (entonces el mensaje se puede consumir normalmente); si el estado del mensaje es revertir, no haga nada.

6. La solicitud de finalización del medio mensaje enviada por el productor es unidireccional, es decir, se ignora después de ser enviada. Esto por sí solo no puede garantizar que se envíe el medio mensaje. RocketMq proporciona una solución de encubrimiento. Esta solución se llama el mecanismo de verificación inversa de mensajes. Broker Al inicio, se iniciará una tarea TransactionalMessageCheckService, que leerá periódicamente todos los semimensajes sin terminar con tiempo de espera de la cola de medio mensaje. Para cada mensaje sin terminar, el Broker enviará una solicitud de verificación de mensajes al Productor correspondiente De acuerdo con Utilice los resultados de la verificación inversa para decidir si este medio mensaje debe enviarse o revertirse, o continuar con la verificación inversa más tarde.

7. El consumidor (el sistema B en este ejemplo) consume mensajes y realiza cambios de datos locales (en cuanto a si B puede consumir con éxito y si debe volver a intentarlo si el consumo falla, este es un problema que debe considerarse para el consumo normal de mensajes).

En rocketMq, ya sea que el productor ejecute una transacción local después de recibir el medio mensaje almacenado por el corredor y regrese con éxito, o que el corredor verifique el estado del mensaje del productor, todo se hace a través del mecanismo de devolución de llamada.

Al enviar un semimensaje, se pasará una clase de devolución de llamada TransactionListener. Se deben implementar dos de los métodos al usarlo: el método ejecutarLocalTransaction se ejecutará después de que el corredor devuelva con éxito el almacenamiento del semimensaje y ejecutaremos transacciones locales. en él; el método checkLocalTransaction se ejecutará después de que el corredor devuelva el almacenamiento de semimensajes. Se ejecuta cuando el productor inicia una verificación inversa, en la que consultamos el estado de la tabla de la biblioteca. El valor de retorno de ambos métodos es el estado del mensaje, que le indica al intermediario que debe enviar o revertir la mitad del mensaje.

6.9.4 Esquema de la tabla de mensajes local

A veces, nuestro componente MQ actual no admite mensajes de transacciones o queremos inmiscuirnos lo menos posible en el lado comercial. En este momento necesitamos otra solución "basada en la tabla de mensajes local de la base de datos".

La tabla de mensajes locales fue propuesta originalmente por eBay para resolver el problema de las transacciones distribuidas. Es una de las soluciones más utilizadas en la industria y su idea central es dividir las transacciones distribuidas en transacciones locales para su procesamiento.

Proceso de tabla de mensajes local

Parte emisora:

• Se requiere una tabla de mensajes para registrar información relacionada con el estado del mensaje.
• Los datos comerciales y la tabla de mensajes están en la misma base de datos, así que asegúrese de que estén en la misma transacción local. Utilice directamente transacciones locales para escribir datos comerciales y mensajes de transacciones directamente en la base de datos.
• Después de procesar los datos comerciales y escribir la tabla de mensajes en la transacción local, escriba el mensaje en la cola de mensajes MQ. Utilice un hilo de trabajo de entrega dedicado para entregar mensajes de transacciones a MQ y eliminar registros de la tabla de mensajes de transacciones según el ACK de entrega.
• El mensaje se enviará al consumidor del mensaje. Si el envío falla, se volverá a intentar.

Consumidor de mensajes:

• Procese mensajes en la cola de mensajes y complete su propia lógica empresarial.
• Si la transacción local se procesa con éxito, indica que se ha procesado con éxito.
• Si falla el procesamiento de la transacción local, se vuelve a intentar la ejecución.
• Si se trata de una falla a nivel empresarial, se envía un mensaje de compensación empresarial al productor del mensaje para notificar la reversión y otras operaciones.

El productor y el consumidor escanean periódicamente la tabla de mensajes local y reenvían mensajes no procesados ​​o mensajes fallidos. Si existe una lógica confiable de conciliación y reabastecimiento automático, esta solución sigue siendo muy práctica.

Ventajas y desventajas de las tablas de mensajes locales:

Ventajas :

• El costo de construcción de las tablas de mensajes locales es relativamente bajo, lo que logra una entrega de mensajes confiable y garantiza la máxima coherencia de las transacciones distribuidas.
• No es necesario proporcionar un método de verificación, lo que reduce aún más la intrusión comercial.
• En algunos escenarios, las anotaciones y otras formas se pueden utilizar aún más para el desacoplamiento, y es posible lograr una implementación intrusiva sin código comercial.

defecto:

• La tabla de mensajes local está acoplada con el negocio, lo que dificulta su universalización y no puede ser escalable de forma independiente.
• La tabla de mensajes local se basa en una base de datos, y la base de datos requiere lectura y escritura de E/S del disco, por lo que existe un cuello de botella en el rendimiento en condiciones de alta concurrencia.

6.9.5, mensaje de transacción MQ VS tabla de mensajes local

Lo que tienen en común:

1. Todos los mensajes de transacción dependen de MQ para la notificación de transacciones, por lo que todos son asincrónicos.
2. Existe la posibilidad de que los mensajes de transacción se entreguen repetidamente en el lado de la entrega, y se necesita un mecanismo de soporte para reducir la tasa de entrega repetida y lograr una entrega de mensajes más amigable sin duplicaciones.
3. El consumidor del mensaje de transacción necesita llevar a cabo un diseño de deduplicación de consumo o un diseño idempotente de servicio debido a la inevitable duplicación de la entrega.

La diferencia entre los dos:

Mensaje de transacción MQ:

• MQ debe admitir el mecanismo de semimensaje o características similares y tener un mejor procesamiento de deduplicación para entregas repetidas;
• Es relativamente intrusivo para el negocio y requiere modificación por parte del negocio para proporcionar la función de revisión correspondiente para operaciones locales exitosas;

Tabla de mensajes locales de base de datos:

• Se utiliza una base de datos para almacenar mensajes de transacciones, lo que reduce los requisitos de MQ, pero aumenta los costos de almacenamiento;
• Los mensajes de transacción utilizan la entrega asincrónica, lo que aumenta la posibilidad de entrega repetida de mensajes;

6.10 Notificación de mejor esfuerzo

El objetivo del esquema de notificación de mejor esfuerzo es que la parte iniciadora utilice un determinado mecanismo para hacer sus mejores esfuerzos para notificar al destinatario los resultados del procesamiento comercial.

Coherencia eventual basada en el mejor esfuerzo:

La esencia es lograr la coherencia final mediante la introducción de un mecanismo de verificación periódica, que sea menos intrusivo para el negocio y adecuado para escenarios con baja sensibilidad a la coherencia final y vínculos comerciales cortos.

Las transacciones de notificación de mejor esfuerzo se utilizan principalmente en sistemas externos, debido a que el entorno de la red externa es más complejo y poco confiable, por lo que solo podemos usar nuestros mejores esfuerzos para notificar la consistencia final de los datos, como plataformas y operadores de recarga, acoplamiento de pagos, notificaciones comerciales. , etc. Escenarios de interacción empresarial entre plataformas y sistemas interempresariales;

Las transacciones asincrónicas garantizadas son principalmente adecuadas para garantizar la coherencia final de los datos en los sistemas internos, porque los internos son relativamente controlables, como pedidos y carritos de compras, recepción y compensación, pago y liquidación, etc.

Los mensajes ordinarios no pueden resolver el problema de coherencia entre la ejecución de transacciones locales y el envío de mensajes. Debido a que el envío de mensajes es un proceso de comunicación de red, el proceso de envío de mensajes puede fallar o expirar. Si se agota el tiempo de espera, el envío puede ser exitoso o el envío puede fallar. No se puede determinar el remitente del mensaje, por lo que en este momento, ya sea que el remitente del mensaje confirme la transacción o la revierta, puede haber inconsistencias.

Por tanto, la dificultad de las transacciones de tipo notificación radica en: Garantía de coherencia de los mensajes entregados y las transacciones locales de los participantes.

Debido a que los puntos centrales son los mismos, ambos son garantizar la entrega consistente de mensajes, por lo que el proceso de entrega de la transacción de notificación de mejor esfuerzo es el mismo que el del tipo de garantía asincrónica, por lo que también hay dos ramas:

• Solución de mensajes de transacciones basada en el propio MQ

• Solución de tabla de mensajes de transacciones locales basada en base de datos

6.10.1, esquema de mensajes de transacciones MQ

Para realizar la notificación de mejor esfuerzo, se puede utilizar el mecanismo ACK de MQ.

La transacción de notificación de mejor esfuerzo antes de la entrega es similar al proceso garantizado asincrónico: la clave está en el procesamiento después de la entrega.

Debido a que el tipo de garantía asincrónica se encuentra en el procesamiento de transacciones internas, MQ y el sistema están conectados directamente y no requieren permisos estrictos, seguridad y otros aspectos del diseño de pensamiento. La transacción de notificación de mejor esfuerzo radica en la conexión con el sistema de terceros, por lo que la transacción de notificación de mejor esfuerzo tiene varias características:

• Una vez que la parte comercial activa completa el procesamiento comercial, envía un mensaje de notificación a la parte comercial pasiva (sistema de terceros), lo que permite la pérdida del mensaje.

• El lado activo de la empresa proporciona intervalos de tiempo incrementales (5 min, 10 min, 30 min, 1 h, 24 h) para volver a intentar la interfaz de llamada al lado pasivo de la empresa; después de N veces de notificación, ya no notificará, alarma + registro + intervención manual.

• La parte pasiva empresarial proporciona una interfaz de servicio idempotente para evitar el consumo repetido de notificaciones.

• La parte activa del negocio debe tener un mecanismo de verificación regular para verificar los datos comerciales; evitar que la parte pasiva del negocio haga retroceder el negocio cuando no pueda cumplir con sus responsabilidades y garantizar la coherencia final de los datos.

• La parte activa de la actividad empresarial, después de completar el procesamiento empresarial, envía un mensaje a la parte pasiva de la actividad empresarial, permitiendo que el mensaje se pierda.
• La parte activa puede establecer una regla de notificación de escala de tiempo y repetir la notificación de acuerdo con la regla después de que falla la notificación, hasta que no haya ninguna notificación después de N veces.
• La parte activa proporciona una interfaz de consulta de intercalación para que la parte pasiva coteje y consulte bajo demanda para restaurar mensajes comerciales perdidos.
• Si la parte pasiva de la actividad empresarial recibe los datos con normalidad, devolverá la respuesta con normalidad y finalizará la transacción.
• Si la parte pasiva no los recibe normalmente, consultará a la parte activa de las actividades comerciales de acuerdo con la estrategia de sincronización para recuperar los mensajes comerciales perdidos.

Características

• Modos de servicio utilizados: operaciones consultables, operaciones idempotentes;
• Los resultados del procesamiento de la parte pasiva no afectan los resultados del procesamiento de la parte activa;
• Adecuado para sistemas con baja sensibilidad temporal a la eventual coherencia empresarial;
• Adecuado para operaciones entre sistemas entre empresas, u operaciones entre sistemas relativamente independientes dentro de una empresa, como notificaciones bancarias, notificaciones comerciales, etc.;

6.10.2 Solución de tabla de mensajes local

Para implementar la notificación de mejor esfuerzo, se puede emplear un mecanismo que verifique periódicamente la tabla de mensajes local.

Parte emisora:

• Se requiere una tabla de mensajes para registrar información relacionada con el estado del mensaje.
• Los datos comerciales y la tabla de mensajes están en la misma base de datos, así que asegúrese de que estén en la misma transacción local. Utilice directamente transacciones locales para escribir datos comerciales y mensajes de transacciones directamente en la base de datos.
• Después de procesar los datos comerciales y escribir la tabla de mensajes en la transacción local, escriba el mensaje en la cola de mensajes MQ. Utilice un hilo de trabajo de entrega dedicado para entregar mensajes de transacciones a MQ y eliminar registros de la tabla de mensajes de transacciones según el ACK de entrega.
• El mensaje se enviará al consumidor del mensaje. Si el envío falla, se volverá a intentar.
• El productor escanea periódicamente la tabla de mensajes local y reenvía mensajes no procesados ​​o mensajes fallidos. Si existe una lógica confiable de conciliación y reabastecimiento automático, esta solución sigue siendo muy práctica.

La transacción de notificación de mejor esfuerzo radica en la conexión con el sistema de terceros, por lo que la transacción de notificación de mejor esfuerzo tiene varias características:

• Una vez que la parte comercial activa completa el procesamiento comercial, envía un mensaje de notificación a la parte comercial pasiva (sistema de terceros), lo que permite la pérdida del mensaje.

• El lado activo de la empresa proporciona intervalos de tiempo incrementales (5 min, 10 min, 30 min, 1 h, 24 h) para volver a intentar la interfaz de llamada al lado pasivo de la empresa; después de N veces de notificación, ya no notificará, alarma + registro + intervención manual.

• La parte pasiva empresarial proporciona una interfaz de servicio idempotente para evitar el consumo repetido de notificaciones.

• La parte activa del negocio debe tener un mecanismo de verificación regular para verificar los datos comerciales; evitar que la parte pasiva del negocio haga retroceder el negocio cuando no pueda cumplir con sus responsabilidades y garantizar la coherencia final de los datos.

6.10.3 Transacción de notificación de mejor esfuerzo versus transacción asincrónica garantizada

Según tengo entendido, la transacción de notificación de mejor esfuerzo es en realidad una implementación comercial desarrollada en base a transacciones asincrónicas garantizadas y adecuada para acoplamiento externo. Principalmente tienen diferencias comerciales, así:

• Desde la perspectiva de los participantes: las transacciones de notificación de mejor esfuerzo son adecuadas para interacciones comerciales multiplataforma y entre empresas entre sistemas; las transacciones asincrónicas garantizadas son más adecuadas para la prestación de servicios internos en el mismo sistema de red.
• Desde el nivel del mensaje: las transacciones de notificación de mejor esfuerzo deben impulsarse activamente y proporcionar un mecanismo de reintento de varios niveles para garantizar la notificación de datos; las transacciones garantizadas asincrónicas solo requieren que los consumidores de mensajes consuman activamente.
• Desde el nivel de datos: las transacciones de notificación de mejor esfuerzo requieren mecanismos de verificación periódica adicionales para verificar los datos y garantizar la coherencia final de los datos; las transacciones asincrónicas garantizadas solo necesitan garantizar la entrega confiable de mensajes y no necesitan verificar los datos en sí. tratar con.

6.11 Problemas con las transacciones de notificación

Las transacciones de notificación no pueden resolver el problema de coherencia de la ejecución de transacciones locales y el envío de mensajes.

Debido a que el envío de mensajes es un proceso de comunicación de red, el proceso de envío de mensajes puede fallar o expirar. Si se agota el tiempo de espera, el envío puede ser exitoso o el envío puede fallar. No se puede determinar el remitente del mensaje, por lo que en este momento, ya sea que el remitente del mensaje confirme la transacción o la revierta, puede haber inconsistencias.

6.11.1 Coherencia en el envío de mensajes

La función principal del middleware de mensajes en los sistemas distribuidos es la comunicación asincrónica, el desacoplamiento de aplicaciones y el almacenamiento en búfer simultáneo (también llamado reducción de picos de tráfico). En un entorno distribuido, se requiere comunicación a través de la red, lo que introduce la incertidumbre en la transmisión de datos, que es la tolerancia a fallas de partición en la teoría CAP.

La coherencia en el envío de mensajes significa que la acción comercial que genera el mensaje es consistente con la acción de envío del mensaje, es decir, si la operación comercial tiene éxito, el mensaje generado por esta operación comercial debe enviarse, de lo contrario se perderá.

El proceso de procesamiento de colas MQ convencional no puede lograr la coherencia de los mensajes. Por lo tanto, es necesario utilizar tablas de mensajes locales y de semimensajes para garantizar la coherencia.

6.11.2 El problema del envío repetido de mensajes y el diseño idempotente de las interfaces empresariales

Los mensajes no confirmados serán reenviados según las reglas.

Para el proceso anterior, el envío repetido de mensajes provocará el problema de llamadas repetidas a la interfaz de procesamiento comercial. La razón principal del envío repetido de mensajes durante el proceso de consumo de mensajes es que el middleware de mensajes no actualizó el estado de entrega a tiempo después de que el consumidor recibió y procesó exitosamente el mensaje. Si se permite enviar mensajes repetidamente, el consumidor debe implementar el diseño idempotente de la interfaz empresarial.

6.12 Tipo de compensación

Sin embargo, las transacciones implementadas en función de mensajes no pueden resolver todos los escenarios comerciales, como el siguiente escenario: cuando se completa un pedido, el efectivo del usuario se deduce al mismo tiempo.

Aquí, el iniciador de la transacción es el servicio que administra la biblioteca de pedidos, pero el servicio de pedidos no puede determinar si enviar la transacción completa, porque es necesario asegurarse de que el usuario tenga suficiente dinero para completar la transacción, y esta información está en el servicio de gestión de efectivo. Aquí podemos introducir transacciones basadas en compensación, y el proceso es el siguiente:

• Cree datos de pedido, pero no envíe transacciones locales todavía
• El servicio de pedidos envía una llamada remota al servicio de caja para descontar el importe correspondiente.
• Envíe la transacción de la base de datos del pedido después de que los pasos anteriores sean exitosos.

Lo anterior es un proceso normal y exitoso, si es necesario revertir el proceso anormal, se enviará una llamada remota adicional al servicio de caja para agregar el monto previamente deducido.

El proceso anterior es más complicado que el proceso de transacción basado en la cola de mensajes, y la carga de trabajo de desarrollo también es mayor:

• Escriba la lógica para crear pedidos en el servicio de pedidos.
• Escribe la lógica para deducir dinero en el servicio de caja.
• Escriba la lógica de la devolución de compensación en el servicio de efectivo.

Se puede ver que este proceso de transacción es más complejo que la transacción distribuida implementada en función de mensajes, requiere un desarrollo adicional de métodos de reversión comercial relevantes y también pierde la función de reducir los picos y llenar los valles del tráfico entre servicios. Pero es solo un poco más complicado que las transacciones basadas en mensajes. Si no puede utilizar transacciones de coherencia eventual basadas en colas de mensajes, puede dar prioridad al uso de formularios de transacciones basadas en compensación.

¿Qué es el modelo de compensación?

El modo de compensación utiliza un servicio de coordinación adicional para coordinar varios servicios comerciales que necesitan garantizar la coherencia. El servicio de coordinación llama a cada microservicio comercial en secuencia. Si un servicio comercial llama de manera anormal (incluidas excepciones comerciales y excepciones técnicas), se cancelarán todas las llamadas anteriores. .Servicios empresariales exitosos.

El modo de compensación tiene aproximadamente dos esquemas subdivididos en TCC y Saga.

6.13 Modelo de transacción TCC

6.13.1 ¿Qué es el modelo de transacción TCC?

El concepto de TCC (Intentar-Confirmar-Cancelar) proviene de un artículo titulado "La vida más allá de las transacciones distribuidas: la opinión de un apóstata" publicado por Pat Helland.

El modelo de transacciones distribuidas de TCC consta de tres partes:

1. Servicio comercial principal: El servicio comercial principal es el iniciador de toda la actividad comercial y el orquestador del servicio, es responsable de iniciar y completar toda la actividad comercial.

2. Servicio comercial esclavo: El servicio comercial esclavo participa en toda la actividad comercial, es responsable de proporcionar las operaciones comerciales de TCC e implementar tres interfaces: operación preliminar (Try), operación de confirmación (Confirm) y operación de cancelación (Cancel) para el principal servicio empresarial al que llamar. .

3. Gerente de actividad comercial: el gerente de actividad comercial administra y controla toda la actividad comercial, incluido el registro y el mantenimiento del estado de la transacción global de TCC y el estado de las subtransacciones de cada servicio comercial esclavo, y llama a la Confirmación de todos los negocios esclavos. servicios cuando se envía la actividad comercial Operación, se llama a la operación Cancelar de todos los servicios comerciales esclavos cuando se cancela la actividad comercial.

TCC propone un nuevo modelo de transacción basado en definiciones de transacciones a nivel empresarial. La granularidad del bloqueo está completamente controlada por la propia empresa. El propósito es resolver el problema del bloqueo de recursos de gran granularidad en tablas y bases de datos en empresas complejas.

TCC divide el proceso de ejecución de transacciones en dos etapas: Probar y Confirmar/Cancelar. La lógica de cada etapa está controlada por el código de negocio, lo que evita transacciones largas y puede obtener un mayor rendimiento.

6.13.2 Flujo de trabajo del TCC

En comparación con modelos tradicionales como XA, el modelo de transacciones distribuidas TCC (Try-Confirm-Cancel) se caracteriza porque no depende del administrador de recursos (RM) para admitir transacciones distribuidas, sino que realiza transacciones distribuidas mediante la descomposición de la lógica empresarial. .asuntos.

El modelo TCC cree que para una lógica de negocios específica en un sistema de negocios, cuando proporciona servicios externos, debe aceptar cierta incertidumbre, es decir, la llamada a la operación preliminar de la lógica de negocios es solo una operación temporal, y el negocio principal El servicio que lo llama conserva el derecho de cancelación posterior. Si el servicio comercial principal cree que la transacción global debe revertirse, requerirá la cancelación de la operación temporal anterior, que corresponde a la operación de cancelación del servicio comercial esclavo. Cuando el servicio comercial principal considere que debe presentarse la transacción global, renunciará al derecho de cancelar la operación temporal anterior, que corresponde a la operación de confirmación del servicio comercial esclavo. Cada operación inicial eventualmente será confirmada o cancelada.

Por lo tanto, para un servicio comercial específico, el modelo de transacción distribuida de TCC requiere que el sistema comercial proporcione tres piezas de lógica comercial:
Operación preliminar Intente: completar todas las comprobaciones comerciales y reservar los recursos comerciales necesarios.

Confirmar operación Confirmar: la lógica empresarial se ejecuta realmente, sin ninguna verificación comercial y solo utiliza los recursos comerciales reservados en la etapa de prueba. Por lo tanto, siempre que la operación Try tenga éxito, Confirmar debe tener éxito. Además, la operación Confirmar debe satisfacer la idempotencia para garantizar que una transacción distribuida pueda y solo pueda tener éxito una vez.

Cancelar operación Cancelar: liberar los recursos comerciales reservados en la etapa Try. De manera similar, la operación Cancelar también debe satisfacer la idempotencia.

El modelo de transacciones distribuidas de TCC consta de tres partes:

Fase de prueba: llame a la interfaz de prueba, intente ejecutar el negocio, complete todas las verificaciones comerciales y reserve recursos comerciales.

Fase de confirmación o cancelación: las dos son mutuamente excluyentes, solo puede ingresar a una de ellas y ambas satisfacen la idempotencia, lo que permite reintentar después del fracaso.

Confirmar operación: confirme y envíe el sistema comercial, confirme la ejecución de las operaciones comerciales, no realice otras verificaciones comerciales y solo utilice los recursos comerciales reservados en la fase de prueba.

Cancelar operación: ejecute la cancelación comercial y libere los recursos reservados cuando los errores de ejecución comercial requieran reversión.

Si la fase de Prueba falla, puedes cancelarla ¿Qué pasa si fallan las fases de Confirmar y Cancelar?

Se agregará un registro de transacciones a TCC. Si ocurre un error en la fase de Confirmar o Cancelar, se realizará un reintento, por lo que estas dos fases deben admitir la idempotencia; si el reintento falla, se requiere intervención manual para la recuperación y el procesamiento.

6.13.3 Casos de asuntos de TCC

Sin embargo, el formulario de transacción basado en compensación no puede satisfacer todas las necesidades, como el siguiente escenario: cuando se completa un pedido, se deduce el efectivo del usuario, pero cuando la transacción no se completa o cancela, no se le puede permitir al cliente ver el dinero. disminuir.arriba.

En este momento podemos introducir TCC, el proceso es el siguiente:

• El servicio de pedidos crea pedidos.
• El servicio de pedidos envía una llamada remota al servicio de caja, congelando el efectivo del cliente.
• Enviar datos del servicio de pedido
• El servicio de pedidos envía una llamada remota al servicio de caja, debitando el efectivo congelado del cliente

Lo anterior es un proceso que normalmente se completa, si es un proceso anormal, es necesario enviar una solicitud de llamada remota al servicio de caja para cancelar el monto congelado.

El proceso anterior es más complicado que el proceso de transacción basado en la implementación de la compensación, y la carga de trabajo de desarrollo también es mayor:

• El servicio de pedidos escribe la lógica para crear pedidos.
• El servicio de caja escribe la lógica para congelar efectivo
• El servicio de caja escribe la lógica para deducir efectivo
• El servicio de caja escribe la lógica para descongelar efectivo

TCC es en realidad la situación más compleja y puede manejar todos los escenarios comerciales, pero independientemente de las consideraciones de rendimiento o de complejidad del desarrollo, este tipo de transacción debe evitarse tanto como sea posible.

6.13.4 Requisitos del modelo de transacción TCC

• Operaciones consultables: las operaciones de servicio tienen un identificador único global y la operación tiene un tiempo único y determinado.

• Operación idempotente: los resultados comerciales producidos por llamadas repetidas varias veces son los mismos que los resultados producidos al llamarlas una vez. La primera es lograr la idempotencia a través de operaciones comerciales, la segunda es que el sistema almacena en caché los resultados de todas las solicitudes y procesamientos y, finalmente, después de detectar solicitudes repetidas, devuelve automáticamente los resultados del procesamiento anterior.

• Operación de TCC: en la fase de prueba, intente ejecutar el negocio, completar todas las comprobaciones comerciales y lograr coherencia; reserve los recursos comerciales necesarios para lograr un cuasi aislamiento. Etapa de confirmación: para ejecutar realmente el negocio sin ninguna verificación, solo se aplican los recursos comerciales reservados en la etapa de prueba, y la operación de confirmación también debe satisfacer la idempotencia. Fase de cancelación: Cancelar la ejecución del negocio y liberar los recursos comerciales reservados en la fase de Prueba. La operación Cancelar debe satisfacer la idempotencia. La diferencia entre el protocolo TCC y 2PC (compromiso de dos fases): TCC se encuentra en la capa de servicios empresariales en lugar de en la capa de recursos. TCC no tiene una etapa de preparación separada. La operación Try tiene capacidades de operación y preparación de recursos. La operación Try en TCC puede seleccionar de manera flexible recursos comerciales y bloquear la granularidad. El costo de desarrollo de TCC es mayor que el de 2PC. De hecho, TCC también es una operación de dos etapas, pero TCC no es equivalente a una operación de 2PC.

• Operaciones compensables: Etapa de realización: el procesamiento comercial se ejecuta realmente y los resultados del procesamiento comercial son visibles externamente. Etapa de compensación: compensar o cancelar parcialmente los resultados comerciales de las operaciones comerciales a término, y las operaciones de compensación satisfacen la idempotencia. Restricciones: La operación de compensación es comercialmente viable y los riesgos y costos causados ​​por resultados de ejecución comercial no aislados o una compensación incompleta son controlables. De hecho, las operaciones de Confirmación y Cancelación de TCC pueden considerarse operaciones de compensación.

6.13.5 Modelo de transacción TCC VS modelo de transacción DTP

Compare el modelo de transacción TCC y el modelo de transacción DTP, de la siguiente manera:

Estas dos imágenes se ven muy diferentes, ¡pero en realidad son similares en muchos lugares!

• El servicio comercial principal en el modelo TCC es equivalente al AP en el modelo DTP, y el servicio comercial esclavo en el modelo TCC es equivalente al RM en el modelo DTP.

  • En el modelo DTP, la aplicación AP opera los recursos en múltiples administradores de recursos RM; mientras que en el modelo TCC, el servicio comercial principal opera los recursos en múltiples servicios comerciales esclavos. Por ejemplo, en el caso de la reserva de vuelos, la aplicación Meituan es el servicio comercial principal, mientras que Sichuan Airlines y China Eastern Airlines son los servicios comerciales esclavos. El servicio comercial principal necesita utilizar los recursos de boletos en el servicio comercial esclavo. La diferencia es que el proveedor de recursos en el modelo DTP es una base de datos relacional similar a Mysql, mientras que el proveedor de recursos en el modelo TCC son otros servicios comerciales.

• En el modelo TCC, las interfaces de prueba, confirmación y cancelación proporcionadas por el servicio empresarial son equivalentes a las interfaces de preparación, confirmación y reversión proporcionadas por RM en el modelo DTP.

  • El protocolo XA estipula que el RM en el modelo DTP debe proporcionar interfaces de preparación, confirmación y reversión para que TM llame para lograr el envío en dos fases.

  • En el modelo TCC, el servicio comercial esclavo es equivalente a RM y proporciona interfaces de prueba, confirmación y cancelación similares.

• administrador de transacciones

  • Existe un administrador de transacciones tanto en el modelo DTP como en el modelo TCC. la diferencia es:

  • En el modelo DTP, TM llama a la fase 1 (preparación) y a la fase 2 (confirmación, reversión).

  • En el modelo TCC, la interfaz de prueba en la fase 1 es la llamada de servicio comercial principal (flecha verde), y (confirmar, cancelar interfaz) en la fase 2 es la llamada TM del administrador de transacciones (flecha roja). Esta es la función asincrónica de dos fases del modelo de transacción distribuida de TCC. Si la primera fase del servicio comercial esclavo se ejecuta con éxito, el servicio comercial principal se puede enviar y completar, y luego el marco del administrador de transacciones ejecutará la segunda fase de forma asincrónica. de cada servicio de negocio esclavo. . Aquí se sacrifica algo de aislamiento y coherencia, pero se mejora la disponibilidad de transacciones largas.

6.13.6 Comparación de TCC y 2PC

De hecho, la esencia de TCC es similar a la de 2PC:

• T significa Intentar y las dos C significan Confirmar y Cancelar.

• Intentar significa intentar. Cada participante en el enlace de solicitud ejecuta la lógica de prueba por turno. Si tiene éxito, se ejecutará la lógica de confirmación. Si hay un error, se ejecutará la lógica de cancelación.

La presentación en dos etapas de TCC y XA tiene el mismo propósito. La siguiente figura enumera la comparación entre los dos.

En la fase 1:

• En XA, cada RM se está preparando para enviar su propia rama de transacciones, de hecho, se está preparando para enviar operaciones de actualización de recursos (insertar, eliminar, actualizar, etc.);

• En TCC, la actividad comercial principal solicita (prueba) recursos reservados por cada servicio comercial esclavo.

En la etapa 2:

• XA determina si confirmar o revertir en función de si cada RM se preparó correctamente en la primera etapa. Si la preparación es exitosa, confirme cada rama de transacción; de lo contrario, revierta cada rama de transacción.

• En TCC, si todos los recursos comerciales se reservan con éxito en la primera fase, confirme cada servicio comercial esclavo; de lo contrario, cancele (cancele) las solicitudes de reserva de recursos de todos los servicios comerciales esclavos.

La diferencia entre TCC y 2PC es:

• XA es una transacción distribuida a nivel de recursos con una gran coherencia. Durante todo el proceso de envío de dos fases, el bloqueo de recursos siempre se mantendrá. Según la implementación del bloqueo de la base de datos, la base de datos debe admitir el protocolo XA. Dado que los datos relevantes deben bloquearse durante todo el proceso de ejecución de la transacción, generalmente el rendimiento de alta concurrencia será relativamente pobre.

• TCC es una transacción distribuida a nivel empresarial, con coherencia eventual, no siempre mantiene bloqueos de recursos y tiene mejor rendimiento. Sin embargo, es muy intrusivo para los microservicios. Cada transacción de microservicios debe implementar tres métodos, como probar, confirmar y cancelar. El costo de desarrollo es alto y el costo de mantenimiento y transformación será alto en el futuro. 、La interfaz de cancelación debe implementar operaciones idempotentes. Debido a que el administrador de transacciones necesita registrar registros de transacciones, definitivamente consumirá una cierta cantidad de rendimiento y alargará todo el tiempo de transacción de TCC.

• TCC debilitará el bloqueo de recursos en cada paso para lograr un propósito que pueda soportar una alta concurrencia (basada en una eventual coherencia).

Las instrucciones específicas son las siguientes:

XA es una transacción distribuida a nivel de recursos con una gran coherencia. Durante todo el proceso de envío de dos fases, el bloqueo de recursos siempre se mantendrá.

El proceso interno de confirmación de dos fases en las transacciones XA está protegido de los desarrolladores y los desarrolladores no pueden percibir este proceso desde el nivel del código. En el proceso de confirmación de dos fases del administrador de transacciones, los recursos en realidad están bloqueados todo el tiempo desde la preparación hasta la confirmación/reversión. Si alguien más necesita actualizar estos dos registros, debe esperar a que se libere el bloqueo.

TCC es una transacción distribuida a nivel empresarial, con coherencia eventual y no siempre mantendrá bloqueos de recursos.

El compromiso de dos fases en TCC no protege completamente a los desarrolladores, es decir, desde el nivel del código, los desarrolladores pueden sentir la existencia del compromiso de dos fases. Durante la ejecución de intentar, confirmar/cancelar, sus respectivas transacciones locales generalmente se abren para garantizar las características ACID de la lógica empresarial interna del método. en:

1. La transacción local del proceso de prueba es garantizar la exactitud de la lógica empresarial de reserva de recursos.

2. La lógica de transacción local ejecutada por confirmar/cancelar confirma/cancela los recursos reservados para garantizar una eventual coherencia, que son las llamadas transacciones basadas en compensación. Dado que se trata de múltiples transacciones locales independientes, los recursos no estarán bloqueados todo el tiempo.

Además, aquí se menciona que la transacción local ejecutada mediante confirmación/cancelación es una transacción compensatoria:

La compensación es una transacción local independiente que admite funciones ACID y se utiliza para cancelar lógicamente el impacto de una transacción ACID en el proveedor de servicios. Para una transacción de larga duración, en lugar de implementar una gran transacción ACID distribuida, es mejor usar una solución basada en compensación, trate cada llamada de servicio como una breve transacción ACID local y envíela inmediatamente después de la ejecución.

6.13.7, escenarios de uso de TCC

TCC puede resolver transacciones distribuidas en algunos escenarios, pero uno de sus problemas es que cada participante necesita implementar las interfaces y la lógica de prueba, confirmación y cancelación por separado, lo cual es extremadamente intrusivo para el negocio.

El esquema TCC se basa en gran medida en códigos de reversión y compensación, y el resultado final es que la lógica del código de reversión es compleja y el código comercial es difícil de mantener. Por lo tanto, el esquema TCC tiene menos escenarios de uso, pero también hay escenarios de uso.

Por ejemplo, cuando se trata de escenarios relacionados con dinero, pagos y transacciones, todos utilizarán la solución TCC para garantizar estrictamente que todas las transacciones distribuidas sean exitosas o se reviertan automáticamente, garantizar estrictamente la exactitud de los fondos y garantizar que no habrá problemas con los fondos...

6.14 Modelo de transacción larga SAGA

SAGA puede considerarse como una transacción de compensación asincrónica implementada mediante colas.

6.14.1 Conceptos relacionados con la saga

En 1987, Héctor García-Molina y Kenneth Salem de la Universidad de Princeton publicaron 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. Cada una de estas subtransacciones es una transacción real que mantiene la coherencia de la base de datos.

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 cualquier transacción local en la transacción Saga sale mal, las transacciones anteriores se pueden restaurar mediante llamar a métodos de compensación relevantes para lograr una eventual coherencia en la transacción.

Un modelo de transacción SAGA de este tipo sacrifica cierto aislamiento y coherencia, pero mejora la disponibilidad de transacciones de larga duración.

El modelo Saga consta de tres partes:

• LLT (Transacción de larga duración): una cadena de transacciones que consta de transacciones locales.
• Transacción local: La cadena de transacciones consta de subtransacciones (transacciones locales), LLT = T1+T2+T3+...+Ti.
• Compensación: Cada transacción local Ti tiene una compensación Ci correspondiente.

Hay dos secuencias de ejecución de Saga:

• T1, T2, T3, …, Tn

• T1, T2,…, Tj, Cj,…, C2, C1, donde 0 < j < n

Saga tiene dos estrategias de recuperación:

• Recuperación hacia atrás: deshaga todas las subtransacciones anteriores exitosas. Si falla alguna subtransacción local, se compensa la transacción completada. Por ejemplo, la secuencia de ejecución de situaciones anormales es T1, T2, T3,…Ti,Ci,…C3,C2,C1.

• Recuperación hacia adelante: reintentar transacciones fallidas, adecuado para escenarios que deben tener éxito, en cuyo caso no se requiere Ci. Secuencia de ejecución: T1, T2,…,Tj (fallo), Tj (reintento),…,Ti.

Obviamente, no es necesario proporcionar transacciones de compensación para la recuperación a plazo. Si en su negocio las subtransacciones (eventualmente) siempre tendrán éxito, o las transacciones de compensación son difíciles o imposibles de definir, la recuperación a plazo es más adecuada para sus necesidades.

En teoría, las transacciones de compensación nunca pueden fallar; sin embargo, en un mundo distribuido, los servidores pueden fallar, las redes pueden fallar e incluso los centros de datos pueden experimentar cortes de energía. ¿Qué podemos hacer en esta situación? Un último recurso es proporcionar un recurso alternativo, como la intervención manual.

6.14.2 Condiciones de uso de Saga

Saga parece prometedora para nuestras necesidades. ¿Se puede hacer esto para todos los asuntos de larga duración? Hay algunas limitaciones aquí:

• Saga solo permite dos niveles de anidamiento, Saga de nivel superior y subtransacciones simples.
• En la capa exterior, no se puede satisfacer la atomicidad total. Es decir, las sagas podrán ver resultados parciales de otras sagas.
• Cada subtransacción debe tener un comportamiento atómico independiente.
• En nuestro escenario empresarial, cada entorno empresarial (como reserva de vuelos, alquiler de coches, reserva de hotel y pago) es un comportamiento naturalmente independiente, y cada transacción puede utilizar la base de datos del servicio correspondiente para garantizar operaciones atómicas.

También hay cosas a considerar con la compensación:

• La transacción de compensación deshace el comportamiento de la transacción Ti desde el punto de vista semántico, pero es posible que no pueda devolver la base de datos al estado en el que se ejecutó Ti. (Por ejemplo, si una transacción desencadena el lanzamiento de un misil, esto no se puede deshacer)

Pero eso no es un problema para nuestro negocio. De hecho, también se pueden compensar acciones que son difíciles de deshacer. Por ejemplo, una transacción que envía un correo electrónico se puede compensar enviando otro correo electrónico explicando el problema.

6.14.3 Garantía para ACID:

Las garantías de Saga para ACID son las mismas que las de TCC:

• Atomicidad: Garantizada en circunstancias normales.
• Consistencia (Consistencia): en un momento determinado, los datos en la base de datos A y la base de datos B violarán los requisitos de coherencia, pero al final serán consistentes.
• Aislamiento: en un momento determinado, la transacción A puede leer los resultados parcialmente enviados de la transacción B.
• Durabilidad (Durabilidad), al igual que las transacciones locales, los datos persisten mientras estén comprometidos.

Saga no ofrece garantías ACID porque no se pueden satisfacer la atomicidad y el aislamiento. El artículo original se describe a continuación:

full atomicity is not provided. That is, sagas may view the partial results of other sagas

A través del registro de saga, saga puede garantizar coherencia y durabilidad.

6.14.4 Solución del modelo SAGA

La idea central del modelo SAGA es convertir transacciones distribuidas en transacciones locales a través de una determinada solución, reduciendo así la complejidad del problema.

Por ejemplo, tomando como ejemplo el escenario de DB y MQ, la lógica empresarial es la siguiente:

• Inserte un dato en la base de datos.

• Enviar un mensaje a MQ.

Dado que la lógica anterior corresponde a dos extremos de almacenamiento, a saber, DB y MQ, no se puede resolver simplemente mediante transacciones locales. Entonces, según el modelo SAGA, existen dos soluciones.

Opción 1: Modo semimensaje.

En la nueva versión de RocketMQ, este modo es compatible.

Primero, entendemos qué es un medio mensaje. En pocas palabras, agrega un estado al mensaje. Cuando el remitente coloca el mensaje en MQ por primera vez, el mensaje está pendiente de confirmación. En este estado, los consumidores no pueden consumir el mensaje. El remitente debe interactuar con MQ por segunda vez y el consumidor solo puede consumir el mensaje después de cambiar el mensaje del estado de confirmación pendiente al estado confirmado. Los mensajes que están pendientes de confirmación se denominan semimensajes.

La lógica de transacción completa del medio mensaje es la siguiente:

• Envía medio mensaje a MQ.

• Insertar datos en la base de datos.

• Envíe un mensaje de confirmación a MQ.

Descubrimos que, en forma de semimensaje, la operación DB se intercala entre dos operaciones MQ. Suponiendo que el paso 2 falla, el mensaje en MQ siempre estará en un estado de semi-mensaje y los consumidores no lo consumirán.

Entonces, ¿siempre han existido medios mensajes en MQ? ¿O qué pasa si el paso 3 falla?

Para resolver el problema anterior, MQ introduce un mecanismo de escaneo. Es decir, MQ escaneará todos los semimensajes a intervalos regulares y preguntará al remitente sobre los semimensajes escaneados que han existido durante demasiado tiempo. Si la consulta recibe una respuesta de confirmación, el mensaje cambiará a un estado de confirmación, como Si Si se recibe una respuesta fallida, el mensaje se eliminará.

Como se mencionó anteriormente, un problema con el mecanismo de semimensaje es que requiere que el lado comercial proporcione una interfaz para consultar el estado del mensaje, lo que sigue siendo muy intrusivo para el lado comercial.

Solución 2: tabla de mensajes locales

En la base de datos, agregue una tabla de mensajes para almacenar mensajes. como sigue:

• Inserte datos en la tabla de negocios de la base de datos.

• Inserte datos en la tabla de mensajes de la base de datos.

• Envíe el mensaje en la tabla de mensajes a MQ de forma asíncrona y, después de recibir el acuse de recibo, elimine el mensaje en la tabla de mensajes.

Como se indicó anteriormente, mediante la lógica anterior, una transacción distribuida se divide en dos pasos principales. Los números 1 y 2 constituyen una transacción local, resolviendo así el problema de las transacciones distribuidas.

Esta solución no requiere que el extremo comercial proporcione una interfaz de consulta de mensajes, solo necesita modificar ligeramente la lógica comercial y es mínimamente intrusiva.

6.14.5 Caso SAGA

SAGA es adecuado para escenarios en los que no es necesario devolver el estado final del iniciador de negocios de inmediato, por ejemplo: su solicitud ha sido enviada, verifique más tarde o preste atención a las notificaciones.

Reescriba el escenario de transacción de compensación anterior usando SAGA, el proceso es el siguiente:

• El servicio de pedidos crea un registro de pedido con un estado final desconocido y confirma la transacción.
• El servicio de caja deduce el monto requerido y envía la transacción.
• El servicio de pedidos actualiza el estado del pedido para que sea exitoso y envía la transacción.

Lo anterior es un proceso exitoso: si el servicio de efectivo no deduce el monto, el último paso del servicio de pedido actualizará el estado del pedido como error.

Su carga de trabajo de codificación empresarial es un poco más que transacciones de compensación e incluye lo siguiente:

• El servicio de pedidos crea la lógica para el pedido inicial.
• El servicio de pedidos confirma la lógica del éxito del pedido.
• Lógica de la falla del servicio de pedidos al confirmar el pedido
• La lógica de deducir efectivo de los servicios de caja.
• Lógica de efectivo de retorno de compensación de servicio de efectivo

Sin embargo, tiene ventajas de rendimiento sobre el formulario de transacción de compensación. Durante la ejecución de todas las subtransacciones locales, no hay necesidad de esperar la ejecución de las subtransacciones que llama, lo que reduce el tiempo de bloqueo. Esto es en empresas con Muchos y largos procesos de transacción, las ventajas de rendimiento son aún más obvias. Al mismo tiempo, utiliza colas para la comunicación, lo que tiene el efecto de reducir los picos y llenar los valles.

Por lo tanto, este formulario es adecuado para escenarios comerciales que no necesitan devolver sincrónicamente el resultado final de la ejecución del iniciador, pueden compensarse, tienen requisitos de alto rendimiento y no les importa la codificación adicional.

Pero, por supuesto, SAGA también se puede transformar ligeramente en una forma similar a TCC que pueda reservar recursos.

6.14.6 Comparación entre Saga y TCC

La desventaja de Saga en comparación con TCC es la falta de acciones reservadas, lo que hace que la implementación de acciones de compensación sea más problemática: Ti es un compromiso. Por ejemplo, una empresa debe enviar correos electrónicos. En el modo TCC, primero guarde el borrador (Probar) y luego envíe (Confirmar) Si cancela, simplemente elimine el borrador (Cancelar). Sin embargo, Saga simplemente envía un correo electrónico (Ti) directamente. Si desea cancelar, debe enviar otro correo electrónico para explicar la cancelación (Ci), lo cual es un poco complicado de implementar.

Si el ejemplo anterior de envío de un correo electrónico se cambia a: El Servicio A envía un Evento a ESB (Enterprise Service Bus, que puede considerarse como un middleware de mensajes) inmediatamente después de completar Ti. El servicio descendente escucha este Evento y realiza parte de su propio trabajo antes de enviarlo Evento a ESB, si el servicio A realiza la acción de compensación Ci, entonces el nivel de toda la acción de compensación es muy profundo.

Sin embargo, la falta de acciones reservadas también puede considerarse una ventaja:

• Algunos negocios son muy simples: aplicar TCC requiere modificar la lógica comercial original, mientras que Saga solo necesita agregar una acción de compensación.

• El número mínimo de comunicaciones para TCC es 2n, mientras que para Saga es n (n=número de subtransacciones).

• Algunos servicios de terceros no tienen una interfaz Try y el modo TCC es complicado de implementar, mientras que Saga es muy simple.

• Sin acción de reserva significa que no tiene que preocuparse por liberar recursos y el manejo de excepciones es más sencillo.

Saga contra TCC

Tanto Saga como TCC son transacciones compensatorias y sus diferencias son:

Desventajas:

• El aislamiento no está garantizado;

Ventaja:

• Envíe transacciones locales en una fase, sin bloqueos y de alto rendimiento;
• Modo controlado por eventos, los participantes pueden ejecutar de forma asincrónica y lograr un alto rendimiento;
• Saga tiene menos intrusión en el negocio y solo necesita proporcionar una operación inversa Cancelar, mientras que TCC requiere un proceso global de transformación del negocio;

6.15 Comparación general del esquema

Atributos	2 piezas	TCC	Saga	Transacciones garantizadas asincrónicas	notificación de mejor esfuerzo
Consistencia transaccional	poderoso	débil	débil	débil	débil
Complejidad	medio	alto	medio	Bajo	Bajo
intrusión empresarial	Pequeño	grande	Pequeño	medio	medio
Limitaciones de uso	grande	grande	medio	Pequeño	medio
actuación	Bajo	medio	alto	alto	alto
Costo de mantenimiento	Bajo	alto	medio	Bajo	medio

七、conjunto

Seata es una solución de transacciones distribuidas de código abierto dedicada a proporcionar servicios de transacciones distribuidas de alto rendimiento y fáciles de usar. Seata proporcionará a los usuarios modos de transacción AT, TCC, SAGA y XA para crear una solución distribuida integral para los usuarios.

7.1 Introducción a Seata

Seata es una solución de transacciones distribuidas de código abierto dedicada a proporcionar servicios de transacciones distribuidas de alto rendimiento y fáciles de usar bajo una arquitectura de microservicio. Seata proporcionará a los usuarios modos de transacción AT, TCC, SAGA y XA.
Antes de que Seata fuera de código abierto, la versión interna correspondiente de Seata desempeñaba el papel de middleware de coherencia distribuida en la economía de Ali, ayudando a la economía a atravesar los años. El evento Double 11 brindó un fuerte apoyo a cada negocio de BU. El producto comercial GTS se ha vendido en Alibaba Cloud y Financial Cloud
. Enlaces relacionados:

Qué es seata: https://seata.io/zh-cn/docs/overview/what-is-seata.html

Descargar https://seata.io/zh-cn/blog/download.html

Ejemplo oficial https://seata.io/zh-cn/docs/user/quickstart.html

7.1.1 Los tres módulos principales de Seata

Seata AT utiliza una implementación mejorada de envío en dos fases.

Seata se divide en tres módulos:

• TC: Coordinador de Transacciones. Responsable de la generación de nuestro ID de transacción, registro de transacciones, envío, reversión, etc.

• TM: iniciador de la transacción. Define los límites de las transacciones y es responsable de informar a TC sobre el inicio, envío y reversión de las transacciones distribuidas.

• RM: Gestor de recursos. Para administrar los recursos de cada transacción de sucursal, cada RM se registrará en TC como una transacción de sucursal.

En el modo AT de Seata, TM y RM son parte del SDK y de los servicios comerciales, y podemos considerarlos como Clientes. TC es un servicio independiente que se expone a los Clientes a través del registro y descubrimiento del servicio.

Hay tres módulos principales en Seata: TM y RM están integrados con el sistema empresarial como clientes de Seata, y TC se implementa de forma independiente como servidor de Seata.

7.1.2 Proceso de ejecución de transacciones distribuidas de Seata

En Seata, el proceso de ejecución de transacciones distribuidas:

• TM inicia transacciones distribuidas (TM registra registros de transacciones globales con TC);

• Organizar recursos de transacciones, como bases de datos y servicios, de acuerdo con escenarios comerciales (RM informa el estado de preparación de los recursos a TC);

• TM finaliza la transacción distribuida y finaliza la primera fase de la transacción (TM notifica a TC que confirme/revierta la transacción distribuida);

• TC resume la información de la transacción y decide si confirmar o revertir una transacción distribuida;

• TC notifica a todos los RM que confirmen/reviertan recursos y finaliza la segunda fase de la transacción;

Los roles TC, TM y RM de Seata son similares al modelo XA. La siguiente figura muestra el flujo de transacciones general del modelo XA.

En el modelo X/Open DTP (Proceso de transacciones distribuidas), existen tres roles:

• AP: Aplicación, aplicación. Esa es la capa empresarial. AP define qué operaciones pertenecen a una transacción.

​ - TM: Transaction Manager, gestor de transacciones. Reciba solicitudes de transacciones AP, administre transacciones globales, administre el estado de las sucursales de transacciones, coordine el procesamiento de RM, notifique a RM qué operaciones pertenecen a qué transacciones globales y sucursales de transacciones, etc. Esta es también la parte central de todo el modelo de programación de transacciones.

​ - RM: Gestor de recursos, gestor de recursos. Por lo general, es una base de datos, pero también pueden ser otros administradores de recursos, como colas de mensajes (como fuentes de datos JMS), sistemas de archivos, etc.

7.1.3, 4 soluciones de transacciones distribuidas

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

7.2 Modo Seata AT

El modo Seata AT es el primer modo admitido. El modo AT se refiere a las transacciones de sucursales automatizadas en modo de transacción automática (sucursal).

El modelo Seata AT es un modelo mejorado de 2 piezas o un modelo XA mejorado.

En términos generales, el modo AT es una evolución del protocolo de confirmación de dos fases de 2 piezas. La diferencia es que el modo AT de Seata no siempre bloqueará la mesa.

7.2.1 Requisitos previos para utilizar el modo Eata AT

• Basado en una base de datos relacional que admite transacciones ACID nativas.

  • Por ejemplo, en versiones anteriores a MySQL 5.1, el motor de búsqueda predeterminado es MyISAM. A partir de versiones posteriores a MySQL 5.5, el motor de búsqueda predeterminado cambia a InnoDB. Las características del motor de almacenamiento MyISAM son: no se admiten bloqueos a nivel de tabla, transacciones ni índices de texto completo. Por lo tanto, las tablas basadas en MyISAM no son compatibles con el modo Seata AT.

• Aplicación Java, accediendo a la base de datos mediante JDBC.

7.2.2, diagrama del modelo Seata AT

Evolución del protocolo de compromiso de dos fases:

• Fase uno: los datos comerciales y los registros de reversión se envían en la misma transacción local y se liberan los bloqueos locales y los recursos de conexión.

• Segunda etapa:

  • Las confirmaciones se realizan de forma asincrónica y muy rápidamente.
  • O revertir la compensación inversa mediante el registro de reversión de una etapa

El diagrama del modelo completo de AT en el modo de transacción formulado por Seata:

7.2.3 Ejemplo de modo Seata AT

Utilicemos un escenario empresarial relativamente simple para describir el proceso de trabajo del modo Seata AT.

Existe un negocio de recarga, actualmente existen dos servicios, uno se encarga de administrar el saldo del usuario y el otro se encarga de administrar los puntos del usuario.

Cuando el usuario recarga, primero se aumenta el saldo de la cuenta del usuario y luego se aumentan los puntos del usuario.

Seata AT se divide en dos fases: la lógica principal está en la primera fase y la segunda fase se realiza principalmente para revertir o limpiar registros.

Proceso de primera etapa:

El proceso de la primera etapa es el siguiente:

1) TM en el servicio de saldo se aplica a TC para iniciar una transacción global, y TC devolverá una ID de transacción global.

2) Antes de que el servicio de saldo ejecute negocios locales, RM primero registrará las transacciones de la sucursal con TC.

3) El servicio de saldo genera secuencialmente un registro de deshacer, ejecuta transacciones locales, genera un registro de rehacer y finalmente envía transacciones locales directamente.

4) El RM del servicio de saldo informa a TC que el estado de la transacción es exitoso.

5) El servicio de saldo inicia una llamada remota y pasa el ID de la transacción al servicio de puntos.

6) El servicio de puntos también registrará las transacciones de sucursales con TC antes de realizar negocios locales.

7) El servicio de puntos genera un registro de deshacer, ejecuta transacciones locales, genera un registro de rehacer y finalmente envía transacciones locales directamente.

8) El RM del servicio de puntos informa al TC que el estado de la transacción es exitoso.

9) El servicio de puntos devuelve una llamada remota exitosa al servicio de saldo.

10) La TM del servicio de saldo se aplica al TC para el envío/reversión de transacciones globales.

También existe TM en el servicio de puntos, pero como no se utiliza, se puede ignorar.

Si utilizamos la transacción anotada del marco Spring, la llamada remota se producirá antes de que se confirme la transacción local. Sin embargo, en realidad no tiene ningún efecto si se inicia primero la llamada remota o si se envía primero la transacción local.

El proceso de la segunda etapa es el siguiente:

La lógica de la segunda etapa es relativamente simple.

Existe una conexión larga entre el Cliente y TC. Si se trata de un envío global normal, TC notificará a varios RM para que limpien de forma asincrónica los registros locales de rehacer y deshacer. Si se trata de una reversión, el TC puede notificar a cada RM que revierta los datos.

Esto generará una pregunta: dado que las transacciones locales las enviamos nosotros mismos directamente, ¿cómo revertirlas más tarde? Dado que registramos los registros de deshacer y rehacer antes y después de las operaciones comerciales locales, podemos revertirlas a través del registro de deshacer.

Dado que deshacer y rehacer el registro y las operaciones comerciales están en la misma transacción, definitivamente tendrán éxito o fracasarán al mismo tiempo.

Pero todavía hay un problema, porque durante el período desde el envío local de cada transacción hasta la notificación de la reversión, estos datos pueden haber sido modificados por otras transacciones. Si utiliza directamente el registro de deshacer para revertir, se producirán inconsistencias en los datos.

En este momento, RM utilizará el registro de rehacer para verificar si los datos son los mismos, a fin de saber si han sido modificados por otras transacciones. Nota: el registro de deshacer son los datos antes de la modificación y se pueden usar para la reversión; el registro de rehacer son los datos después de la modificación y se usan para la verificación de la reversión.

Si los datos no han sido modificados por otras transacciones, se pueden revertir directamente; si son datos sucios, se pueden procesar de acuerdo con diferentes estrategias.

7.2.4 Uso del modo Seata AT en escenarios de pedidos de comercio electrónico

A continuación se describe el principio de funcionamiento del modo Seata AT y su uso en escenarios de pedidos de comercio electrónico.

Como se muestra abajo:

En la figura anterior, el servicio de compras coordinador primero llama al servicio de repositorio participante para deducir el inventario y luego llama al servicio de pedidos participante para generar un pedido. El flujo de transacciones global después de que este flujo de negocios utilice Seata en modo XA se muestra en la siguiente figura:

El proceso de ejecución de transacciones globales descrito en la figura anterior es:

1) el servicio de compras registra una transacción global con Seata y genera un identificador de transacción global XID

2) Ejecute las transacciones locales de repo-service.repo_db y order-service.order_db hasta la etapa de envío. El contenido de la transacción incluye operaciones de consulta en repo-service.repo_db y order-service.order_db y escriba registros undo_log para cada biblioteca.

3) repo-service.repo_db, order-service.order_db registran las transacciones de sucursales con Seata e las incluyen en el alcance de transacción global correspondiente al XID

4) Envíe las transacciones locales de repo-service.repo_db y order-service.order_db

5) repo-service.repo_db y order-service.order_db informan el estado de envío de las transacciones de la sucursal a Seata

6) Seata resume el estado de envío de todas las transacciones de la sucursal de DB y decide si la transacción global debe enviarse o revertirse.

7) Seata notifica a repo-service.repo_db y order-service.order_db que confirmen/reviertan las transacciones locales. Si se requiere la reversión, se adopta un método compensatorio.

Entre ellos, 1) 2) 3) 4) 5) pertenecen a la primera etapa, y 6) 7) pertenecen a la segunda etapa.

7.2.5 Aislamiento de datos de Seata

La lógica de implementación principal del modo at de seata es el agente de fuente de datos, y el agente de fuente de datos se implementará en base a bases de datos de transacciones relacionales como MySQL y Oracle, y el nivel de aislamiento basado en la base de datos es lectura confirmada. En otras palabras, el soporte para transacciones locales es una condición necesaria para que seata implemente el modo at, lo que también limitará los escenarios de uso del modo at de seata.

Aislamiento de escritura
Del flujo de trabajo anterior, podemos saber fácilmente que el nivel de aislamiento de escritura de Seata es global y exclusivo.

Primero, comprendamos el proceso de aislamiento de escritura.

分支事务1-开始
| 
V 获取 本地锁
| 
V 获取 全局锁    分支事务2-开始
|               |
V 释放 本地锁     V 获取 本地锁
|               |
V 释放 全局锁     V 获取 全局锁
                |
                V 释放 本地锁
                |
                V 释放 全局锁

Como se muestra arriba, el proceso de adquisición de bloqueo de una transacción distribuida es el siguiente:
1) Primero obtenga el bloqueo local, de modo que pueda modificar los datos locales, pero aún no puede enviar la transacción local,
2) Luego, si puede enviar depende de si puede obtenerlo Bloqueo global
3) Obtener el bloqueo global significa que se puede modificar, luego enviar la transacción local y liberar el bloqueo local
4) Cuando se envía la transacción distribuida, libere el bloqueo global. Esto permite que otras transacciones adquieran bloqueos globales y envíen sus modificaciones a datos locales.

Como puede ver, hay dos puntos clave aquí:
1) Antes de adquirir el bloqueo local, no se competirá con el bloqueo global.
2) Antes de adquirir el bloqueo global, no se enviará el bloqueo local.

Esto significa que las modificaciones de datos serán mutuamente excluyentes. Esto evitará que se escriban datos sucios. Los bloqueos globales pueden aislar datos de escritura en modificación distribuida.

Principios del aislamiento de la escritura:

• Antes de confirmar una transacción local de fase uno, es necesario asegurarse de que primero se obtenga el bloqueo global.

• Si no se puede obtener el bloqueo global, no se puede enviar la transacción local.

• Los intentos de obtener bloqueos globales están limitados a un cierto rango. Si exceden el rango, se abandonarán, la transacción local se revertirá y el bloqueo local se liberará.

Ilustremos con un ejemplo:

• Dos transacciones globales, tx1 y tx2, actualizan respectivamente el campo m de la tabla a, y el valor inicial de m es 1000.

tx1 comienza primero, inicia la transacción local, obtiene el bloqueo local y actualiza la operación m = 1000 - 100 = 900. Antes de confirmar la transacción local, se obtiene el bloqueo global del registro y la confirmación local libera el bloqueo local.

A partir de tx2, se inicia la transacción local, se obtiene el bloqueo local y la operación de actualización es m = 900 - 100 = 800. Antes de confirmar la transacción local, intente obtener el bloqueo global del registro. Antes de que tx1 se confirme globalmente, tx1 mantiene el bloqueo global del registro. tx2 necesita volver a intentarlo y esperar el bloqueo global.

tx1 confirmación global de dos fases, liberando el bloqueo global. tx2 obtiene el bloqueo global y confirma la transacción local.

Si se produce la reversión global de dos etapas de tx1, tx1 necesita volver a adquirir el bloqueo local de los datos y realizar una operación de actualización de compensación inversa para implementar la reversión de rama.

En este momento, si tx2 todavía está esperando el bloqueo global de los datos mientras mantiene el bloqueo local, la reversión de rama de tx1 fallará. Se volverá a intentar la reversión de la rama hasta que se agote el tiempo de espera del bloqueo global de tx2 y otros bloqueos, se abandone el bloqueo global y se revierta la transacción local para liberar el bloqueo local.La reversión de la rama de tx1 finalmente es exitosa.

Debido a que tx1 mantiene el bloqueo global de todo el proceso hasta el final de tx1, no ocurrirá el problema de escritura sucia.

leer nivel de aislamiento

Según el nivel de aislamiento de transacciones locales de la base de datos de Lectura confirmada o superior, el nivel de aislamiento global predeterminado de Seata (modo AT) es Lectura no confirmada.

Si la aplicación se encuentra en un escenario específico, se debe requerir que se confirme la lectura global. Actualmente, el método de Seata es a través del proxy de la instrucción SELECT FOR UPDATE.

La ejecución de la instrucción SELECT FOR UPDATE solicitará un bloqueo global. Si otras transacciones mantienen el bloqueo global, libere el bloqueo local (revierta la ejecución local de la instrucción SELECT FOR UPDATE) e inténtelo nuevamente. Durante este proceso, la consulta se bloquea y no se devolverá hasta que se obtenga el bloqueo global, es decir, se hayan enviado los datos relevantes leídos.

Por consideraciones generales de rendimiento, la solución actual de Seata no representa todas las declaraciones SELECT, solo las declaraciones FOR UPDATE SELECT.

7.2.6 Spring Cloud integra el modo Seata AT

El modo AT se refiere al modo de transacción automática (sucursal). El requisito previo para usar el modo AT es

• Basado en una base de datos relacional que admite transacciones ACID nativas.

• Aplicación Java, accediendo a la base de datos mediante JDBC.

Cómo utilizar Seata-at

1. Presente el marco de seata, configure la configuración básica de seata y establezca la tabla undo_log

2. Los consumidores introducen la anotación de transacción global @GlobalTransactional

3. El productor introduce la anotación de transacción global @GlobalTransactional

7.3 Modo Seata TCC

7.3.1 Introducción

TCC es una transacción de dos etapas como la transacción AT de Seata. Sus principales diferencias con respecto a la transacción AT son:

TCC tiene una grave intrusión en el código comercial

• Las operaciones de datos en cada etapa deben codificarse por sí mismas y el marco de transacciones no puede manejarlas automáticamente.

TCC funciona mejor

• No es necesario agregar bloqueos globales a los datos, lo que permite que se realicen múltiples transacciones con los datos al mismo tiempo.

eata TCC es un modelo de presentación de dos etapas en su conjunto. Una transacción global distribuida. La transacción global se compone de varias transacciones de sucursal. Las transacciones de sucursal deben cumplir con los requisitos del modelo de compromiso de dos etapas, es decir, cada transacción de sucursal debe tener la suya propia:

• Comportamiento de preparación en una etapa
• Comportamiento de confirmación o reversión de dos fases
  

Con base en las diferencias en los modos de comportamiento de dos etapas, dividimos las transacciones de sucursales en modo de transacción automática (sucursal) y modo de transacción TCC (sucursal).

El modo AT ( consulte el enlace TBD ) se basa en una base de datos relacional que admite transacciones ACID locales:

• Comportamiento de preparación en una etapa: en las transacciones locales, las actualizaciones de datos comerciales y los registros de reversión correspondientes se envían juntos.

• Comportamiento de confirmación de la segunda etapa: finaliza con éxito de inmediato y el registro de reversión se limpia de forma automática y asincrónica en lotes.

• Comportamiento de reversión de la segunda etapa: al revertir los registros, se generan automáticamente operaciones de compensación para completar la reversión de datos.

En consecuencia, el modo TCC no depende del soporte de transacciones de los recursos de datos subyacentes:

• Comportamiento de preparación en una etapa: llame a la lógica de preparación personalizada.

• Comportamiento de confirmación de dos etapas: llamar a la lógica de confirmación personalizada.

• Comportamiento de reversión de dos etapas: llamar a la lógica de reversión personalizada.

El llamado modo TCC se refiere a apoyar la integración de transacciones de sucursales personalizadas en la gestión de transacciones globales.

Prueba de primera etapa

Tomando el servicio de cuenta como ejemplo, el monto de la cuenta del usuario debe deducirse al realizar un pedido:

Si un usuario compra un producto por valor de 100 yuanes, se deducirán 100 yuanes.

La transacción TCC primero reserva el monto de la deducción de 100 yuanes, o congela los 100 yuanes primero:

Segunda etapa Confirmar

Si la primera etapa se puede completar con éxito, significa que el negocio del "monto de deducción" (transacción de sucursal) definitivamente tendrá éxito al final. Cuando se confirma la transacción global, TC controlará la transacción de sucursal actual para confirmar. Si la confirmación falla, TC lo intentará una y otra vez hasta que la confirmación sea exitosa.

Cuando se confirma la transacción global, el monto congelado se puede utilizar para finalmente implementar operaciones de datos comerciales:

Fase 2Cancelar

Si la transacción global se revierte, el monto congelado se descongelará y se restaurará al estado anterior. TC controlará la reversión de la transacción de la sucursal actual. Si la reversión falla, TC lo intentará una y otra vez hasta que se complete la reversión.

Múltiples transacciones simultáneas

Se permite que varias transacciones globales de TCC sean simultáneas. Cuando ejecutan el monto de la deducción, solo necesitan congelar sus respectivos montos:

8. Preguntas de la entrevista

8.1 ¿Entiendes las transacciones distribuidas? ¿Cómo resolviste el problema de las transacciones distribuidas?

Los modelos Seata AT y Seata TCC son los más utilizados en producción.

• Modelo de consistencia fuerte, el modelo de solución de consistencia fuerte de Seata AT se utiliza para una consistencia fuerte principalmente en módulos principales, como transacciones/órdenes, etc.

• Modelo de consistencia débil. El esquema de coherencia débil de Seata TCC se utiliza generalmente en módulos de borde como el inventario. A través de la coordinación de TC, se puede garantizar la coherencia final y también se puede lograr el desacoplamiento empresarial.

Escenario de fuerte coherencia

Para esos escenarios particularmente estrictos, el modo Seata AT se utiliza para garantizar una gran coherencia;

Prepare ejemplos: si encuentra un escenario que requiere estrictamente que los datos sean absolutamente correctos (como inventario, pedidos y cupones en transacciones de comercio electrónico), puede responder la pregunta utilizando middleware maduro como el modelo Seata AT.

 阿里开源了分布式事务框架seata经历过阿里生产环境大量考验的框架。  seata支持Dubbo，Spring Cloud。 

Es el modo Seata AT, que garantiza una gran coherencia y admite la modificación de datos en múltiples bibliotecas;

• Biblioteca de pedidos: agregar pedidos

• Biblioteca de productos básicos: deducir inventario

• Biblioteca de cupones: retener cupones

Escenario de consistencia débil

Para escenarios donde los requisitos de coherencia de los datos no son particularmente estrictos, o donde las subtransacciones se ejecutan mediante diferentes sistemas, puede responder la pregunta sobre el uso de Seata TCC para garantizar una coherencia débil.

Prepare un ejemplo: un escenario donde la coherencia de los datos no es estrictamente necesaria, o donde las subtransacciones se ejecutan mediante diferentes sistemas, como un servicio de pago de pedidos de comercio electrónico que actualiza el estado del pedido y envía un mensaje de pago exitoso. Sólo se necesita una coherencia débil. para ser asegurado.

El modo Seata TCC garantiza una coherencia débil y admite la modificación de datos en múltiples servicios y sistemas. En el escenario anterior, se utilizan transacciones en modo Seata TCC.

• Servicio de pedidos: modificar el estado del pedido

• Servicio de notificación: enviar estado de pago

escenario de coherencia eventual

Según la eventual coherencia de los mensajes confiables, cada subtransacción puede ser asíncrona durante mucho tiempo, pero los datos no deben perderse. Puede utilizar transacciones garantizadas asincrónicas.

Se pueden utilizar transacciones garantizadas asincrónicas basadas en MQ, como notificaciones de resultados de pago de plataformas de comercio electrónico:

• Servicio de puntos: aumentar puntos

• Servicios Contables: Generar Registros Contables