¡Las explicaciones gráficas lo llevarán a comprender a fondo los escenarios y las soluciones de las transacciones distribuidas! !

Asuntos locales

Proceso de transacción local

Antes de presentar las transacciones distribuidas, echemos un vistazo a las transacciones locales. Primero, tomemos una foto.

En la figura anterior, podemos ver que las transacciones locales son administradas localmente por administradores de recursos (como DBMS, sistemas de administración de bases de datos).

Pros y contras de los asuntos locales

Los asuntos locales tienen ventajas y desventajas correspondientes.

ventaja:

1. Admite atributos ACID estrictos.
2. Implementación de transacciones confiable y de alta eficiencia (solo operación local).
3. Solo puede operar transacciones en RM (administrador de recursos).
4. El modelo de programación es sencillo.

Desventajas:

1. Falta de capacidades de procesamiento de transacciones distribuidas.
2. El RM (administrador de recursos) determina la unidad más pequeña de aislamiento de datos, y los desarrolladores no pueden decidir la unidad más pequeña de aislamiento de datos. Por ejemplo: un registro en la base de datos, etc.

Atributos ACID

Hablando de transacciones, tenemos que mencionar las propiedades ACID de las transacciones.

• A (Atómico): Atomicidad, todas las operaciones que constituyen una transacción se ejecutan o no se ejecutan en absoluto, es imposible tener un éxito parcial y un fracaso parcial.
• C (consistencia): consistencia, antes y después de que se ejecute la transacción, las restricciones de consistencia de la base de datos no se destruyen. Por ejemplo: Zhang San transfiere 100 yuanes a Li Si. El estado correcto de los datos antes y después de la transferencia se llama consistencia. Si Zhang San transfiere 100 yuanes y la cuenta de Li Si no aumenta en 100 yuanes, hay un error de datos. No se alcanza la coherencia.
• I (Aislamiento): Aislamiento. Las transacciones en la base de datos son generalmente concurrentes. Aislamiento significa que la ejecución de dos transacciones concurrentes no interfiere entre sí, y una transacción no puede ver el estado intermedio de las otras transacciones. Al configurar el nivel de aislamiento de transacciones, se pueden evitar problemas como lecturas sucias y lecturas repetidas.
• D (Durabilidad): Durabilidad, una vez que se completa la transacción, los cambios de datos realizados por la transacción se conservarán en la base de datos y no se revertirán.

Transacción distribuida

Con el rápido desarrollo de los negocios, los sistemas de sitios web a menudo evolucionan gradualmente de una arquitectura única a una arquitectura de microservicio distribuida, mientras que para las bases de datos, una arquitectura de base de datos de una sola máquina se transforma en una arquitectura de base de datos distribuida. En este punto, dividiremos un gran sistema de aplicaciones en múltiples servicios de aplicaciones que se pueden implementar de forma independiente, y se requiere la colaboración remota entre cada servicio para completar las operaciones de transacción.

Podemos utilizar la siguiente figura para representar la arquitectura monolítica de nuestro sistema al principio.

En la figura anterior, organizamos diferentes módulos en el mismo proyecto en diferentes paquetes para su gestión, y todos los códigos de programa todavía se colocan en el mismo proyecto.

En el futuro, debido al desarrollo del negocio, lo expandiremos a una arquitectura distribuida de microservicios. En este punto, dividimos un proyecto grande en microservicios pequeños que se pueden implementar de forma independiente. Cada microservicio tiene su propia base de datos, como se muestra a continuación: Para

otro ejemplo, en nuestro programa, a menudo se encuentra en el mismo Se ejecuta una transacción similar al siguiente código para completar nuestros requisitos.

@Transactional(rollbackFor = Exception.class)
public void submitOrder() {
    
    
    orderDao.update(); // 更新订单信息
    accountService.update(); // 修改资金账户的金额
    pointService.update(); //  修改积分
    accountingService.insert(); // 插入交易流水
    merchantNotifyService.notify(); // 通知支付结果
}

La empresa en el código anterior solo agrega una anotación @Transactional al método submitOrder (). ¿Puede esto evitar el problema de las transacciones distribuidas en un escenario distribuido? Obviamente no funcionará.

Si los códigos anteriores corresponden a: la información del pedido, la información de la cuenta de capital, la información de los puntos, el flujo de transacciones y otra información se almacenan en diferentes datos, y después de que se completa el pago, los datos del sistema de destino notificado también se almacenan en diferentes bases de datos. En este momento surgirán problemas de transacciones distribuidas.

Escenarios generados por transacciones distribuidas

Proceso de JVM cruzado

Cuando dividimos el proyecto monolítico en proyectos distribuidos y de microservicio, cada servicio utiliza llamadas REST o RPC remotas para coordinar las operaciones comerciales. El escenario típico es: microservicios de pedidos y microservicios de inventario en el sistema del centro comercial, los usuarios accederán a los microservicios de pedidos al realizar pedidos y los microservicios de pedidos llamarán a los microservicios de inventario para deducir el inventario cuando generen registros de pedidos. Cada microservicio se implementa en diferentes procesos de JVM. En este momento, se producirán problemas de transacciones distribuidas causados ​​por procesos de JVM cruzados.

Instancia de base de datos cruzada

Un solo sistema accede a múltiples instancias de bases de datos, es decir, se producirán transacciones distribuidas al acceder a través de fuentes de datos. Por ejemplo, la base de datos de pedidos y la base de datos de transacciones de nuestro sistema se colocan en diferentes instancias de la base de datos. Cuando un usuario inicia un reembolso, la base de datos de pedidos del usuario y la base de datos de transacciones se operarán al mismo tiempo, y la operación de reembolso se realizará en la base de datos de transacciones. Cambie el estado del pedido a reembolsado en la base de datos. Dado que los datos se distribuyen en diferentes instancias de la base de datos, es necesario utilizar diferentes sesiones de conexión de la base de datos para manipular los datos en la base de datos.En este momento, se generan transacciones distribuidas.

Base de datos de pedidos de servicios múltiples

Varios microservicios acceden a la misma base de datos. Por ejemplo, el acceso a la misma base de datos mediante microservicios de pedido y microservicios de inventario también generará transacciones distribuidas. La razón es: múltiples microservicios que acceden a la misma base de datos, esencialmente operando la base de datos a través de diferentes sesiones de base de datos, generarán distribución Asuntos de estilo.

Nota: El escenario de instancia de base de datos cruzada y el escenario de base de datos única multiservicio se deben esencialmente a que se generarán diferentes sesiones de base de datos para manipular los datos en la base de datos, generando así transacciones distribuidas. Estos dos escenarios son relativamente fáciles de pasar por alto.

Solución de transacciones distribuidas

Luego de conocer los escenarios de transacciones distribuidas, hablemos de soluciones específicas para transacciones distribuidas.

Plan 2PC

2PC es el protocolo de compromiso de dos fases, que divide todo el proceso de transacción en dos fases,
la fase de preparación y la fase de compromiso , 2 se refiere a dos fases, P se refiere a la fase de preparación y C se refiere a la fase de compromiso .

Aquí, usamos la base de datos MySQL como ejemplo La base de datos MySQL admite un protocolo de confirmación de dos fases, que se puede dividir en dos situaciones: éxito y fracaso.

Éxito:

Fracaso:

El proceso específico es el siguiente:

• Fase de preparación: el administrador de transacciones envía mensajes de preparación a cada participante. Cada participante de la base de datos ejecuta la transacción
  localmente y escribe el registro local Deshacer / Rehacer. En este momento, la transacción no está confirmada. (El registro de deshacer es para registrar los datos antes de la modificación, se usa para la reversión de la base de datos, el registro de rehacer es para registrar los datos modificados, se usa para escribir el archivo de datos después de confirmar la transacción)
• Fase de compromiso: si el administrador de transacciones recibe un mensaje de error o tiempo de espera de ejecución de un participante, envía directamente un mensaje de reversión a cada participante; de ​​lo contrario, envía un mensaje de compromiso; los participantes siguen la transacción Las instrucciones del administrador realizan operaciones de compromiso o reversión y liberan los recursos de bloqueo utilizados durante el procesamiento de transacciones.

Al utilizar la solución 2PC, debe tenerse en cuenta que los recursos de bloqueo deben liberarse en la etapa final.

Esquema de coherencia eventual del mensaje confiable:

El esquema de coherencia eventual de mensajes confiable significa que cuando el iniciador de la transacción completa la transacción local y envía un mensaje, el participante de la transacción (consumidor del mensaje) debe poder recibir el mensaje y procesar la transacción con éxito. Este esquema enfatiza que siempre que el mensaje se envíe al participante de la transacción Los asuntos finales de las partes deben ser coherentes.

El iniciador de la transacción (productor del mensaje) envía el mensaje al middleware del mensaje, el participante de la transacción recibe el mensaje del middleware del mensaje, entre el iniciador de la transacción y el middleware del mensaje, y entre el participante de la transacción (consumidor del mensaje) y el middleware del mensaje. Toda la comunicación se realiza a través de la red y la incertidumbre de la comunicación de la red provocará problemas de transacciones distribuidas. Por lo tanto, introduciremos el servicio de confirmación de mensajes y el servicio de recuperación de mensajes en el plan específico.

Hay varios problemas a tener en cuenta cuando se utilizan esquemas de coherencia eventual de mensajes confiables:

1. La atomicidad de los asuntos locales y el envío de mensajes.
2. La confiabilidad del mensaje recibido por los participantes de la transacción.
3. El problema del consumo repetido de mensajes (necesidad de lograr la idempotencia).

Esquema de TCC

TCC se divide en tres etapas:

1. La etapa de prueba consiste en realizar la inspección comercial (consistencia) y la reserva de recursos (aislamiento), esta etapa es solo una operación preliminar y realmente puede constituir una lógica comercial completa junto con la confirmación posterior.
2. La fase Confirmar es para confirmar el envío. Después de que todas las transacciones de la sucursal se ejecuten con éxito en la fase Probar, se ejecutará Confirmar. En circunstancias normales, al utilizar TCC, se considera que no hay error en la fase Confirmar. Es decir: siempre que el intento sea satisfactorio, la confirmación debe realizarse correctamente. Si algo sale mal en la fase Confirmar, se debe introducir un mecanismo de reintento o procesamiento manual.
3. La fase de cancelación consiste en ejecutar la cancelación comercial de la transacción de la sucursal cuando es necesario revertir el error de ejecución comercial y se liberan los recursos reservados. En circunstancias normales, el uso de TCC se considera un cierto éxito en la fase de cancelación. Si ocurre un error en la fase de cancelación, se debe introducir un mecanismo de reintento o procesamiento manual.

Al utilizar las soluciones distribuidas de TCC, debe prestar atención a cuestiones como la reversión en vacío, la idempotencia y la suspensión.

Notificación de mejor esfuerzo

Este esquema se utiliza principalmente para asegurar la consistencia final de los datos ante múltiples sistemas diferentes, como se muestra en la siguiente figura.

El uso del esquema de notificación de mejor esfuerzo requiere atención a la idempotencia y las operaciones de verificación de datos.

Conclusión:

Ahora que quieres ganar dinero, necesitas tener habilidades reales, de lo contrario, ¡hay mucha suerte! Si necesita materiales de aprendizaje de Java y materiales para entrevistas, puede hacer clic para ingresar el código secreto: csqq , ¡consígalo gratis!

Finalmente, ¡te deseo todo lo mejor en tu trabajo!