Dos soluciones de transacciones distribuidas.

## 1. 2PC
2PC es un protocolo de confirmación de dos fases, que divide el proceso completo de la transacción en dos fases: fase de preparación y fase de confirmación, 2 se refiere a dos fases, P se refiere a la fase de preparación, C Se refiere a la fase de presentación.

Algunas bases de datos relacionales como Oracle y MySQL en la computadora admiten un acuerdo de envío de dos fases, como se muestra a continuación:

  1. Fase de preparación: el administrador de transacciones envía un mensaje de preparación a cada participante. Cada participante de la base de datos ejecuta la transacción localmente y escribe un registro local de Deshacer / Rehacer. En este momento, la transacción no se confirma. (Deshacer registro registra los datos antes de la modificación, que se utiliza para la reversión de la base de datos, y Rehacer registro registra los datos modificados, que se utilizan para escribir archivos de datos después de confirmar las transacciones)

  2. Fase de confirmación: 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 confirmación; el participante se basa en la transacción La instrucción del gerente realiza una operación de confirmación o reversión
    y libera los recursos de bloqueo utilizados durante el procesamiento de la transacción. Nota: Los recursos de bloqueo deben liberarse en la etapa final.

La siguiente figura muestra las dos fases de 2PC, con dos casos de éxito y fracaso:

Éxito:image.png

Fracaso:image.png

## 2. Mecanismo de compensación de
TCC TCC es en realidad el mecanismo de compensación utilizado. La idea central es que para cada operación, se debe registrar una operación de confirmación y compensación (cancelación) correspondiente. Se divide en tres etapas:

  • La etapa de prueba es principalmente hacer la detección del sistema comercial y la reserva de recursos
  • La fase de Confirmación es principalmente para confirmar y enviar el sistema empresarial. Cuando la fase de Prueba se ejecuta con éxito y se inicia la fase de Confirmación, la fase de Confirmación predeterminada está libre de errores. Es decir: mientras Try sea exitoso, Confirm debe ser exitoso.
  • La fase de cancelación es principalmente para cancelar el negocio ejecutado en el estado de error de ejecución del negocio y necesita retroceder y liberar los recursos reservados.image.png

Por ejemplo: A quiere transferir dinero a B, la idea es probablemente:

我们有一个本地方法,里面依次调用 
1、首先在 Try 阶段,要先调用远程接口把 B和 A的钱给冻结起来。 
2、在 Confirm 阶段,执行远程调用的转账的操作,转账成功进行解冻。 
3、如果第2步执行成功,那么转账成功,如果第二步执行失败,则调用远程冻结接口对应的解冻方法 (Cancel)。 

Ventajas: en comparación con la presentación en dos fases, la usabilidad es más fuerte

Desventajas: la consistencia de los datos es peor. TCC pertenece a un método de compensación en la capa de aplicación, por lo que los programadores necesitan escribir una gran cantidad de código de compensación durante la implementación. En algunos escenarios, algunos procesos comerciales pueden no estar bien definidos y manejados por TCC.

## 3. Consistencia final del mensaje La consistencia final del
mensaje debería ser la más utilizada en la industria, y su idea central es dividir las transacciones distribuidas en transacciones locales para su procesamiento. Esta idea proviene de eBay. Podemos ver algunos de estos detalles en el siguiente diagrama de flujo:image.png

La idea básica es:

El productor del mensaje debe crear una tabla de mensajes adicional y registrar el estado de envío del mensaje. Las tablas de mensajes y los datos comerciales deben enviarse en una transacción, lo que significa que deben estar en una base de datos. Luego, el mensaje se enviará al consumidor del mensaje a través de MQ. Si el mensaje no se puede enviar, se volverá a intentar.

El consumidor de mensajes necesita procesar este mensaje y completar su propia lógica de negocios. En este momento, si el procesamiento de la transacción local es exitoso, indica que el procesamiento fue exitoso. Si el procesamiento falla, volverá a intentar la ejecución. Si se trata de una falla comercial, puede enviar un mensaje de compensación comercial al productor para notificarle que realice operaciones de reversión y otras operaciones.

El productor y el consumidor escanean regularmente la tabla de mensajes local y envían nuevamente los mensajes no procesados ​​o fallidos. Si existe una lógica de reconciliación automática confiable, esta solución sigue siendo muy práctica.

Ventajas: Una implementación muy clásica, que evita las transacciones distribuidas y logra una consistencia eventual.

Desventajas: la tabla de mensajes se unirá al sistema de negocios. Si no hay una solución empaquetada, habrá muchas tareas que resolver.

Publicado 15 artículos originales · elogiado 0 · visitas 77

Supongo que te gusta

Origin blog.csdn.net/xrzi2015/article/details/105518978
Recomendado
Clasificación