a llama al sistema b c d, b c tiene éxito, d falla, ¿cómo revertir b c?

El método A llama al método B y luego llama al método C. Mientras se agregue una transacción al método A, B y C no iniciarán una nueva transacción. Si se utiliza la transacción de A, no importa. ya sea A, B o C Las excepciones locales harán que la transacción se revierta y los cambios de datos de A, B y C se confirmarán juntos. Los datos enviados por ACB son mutuamente visibles.

Las transacciones distribuidas siguen siendo los ejemplos anteriores de A, B y C

Pero A, B y C son tres programas independientes. A, B y C no son llamadas locales. , pero una llamada RPC (no importa qué tipo de RPC sea, pasa por la red, no una llamada local (refiriéndose a este programa, no necesita pasar por la red, pero sí por la IP). dirección)),

En este momento, las transacciones locales obviamente ya no funcionan.

En el método A para simular el servicio, se llama al método B del servicio B y luego se llama al método C del servicio C.

Entonces,

1 Si A llama a B y C informa un error antes, la transacción revierte A y B y C no son llamados, esto no es un problema.

2 Si A llama a B y C y luego A genera una excepción, A retrocede y B y C se ejecutan y envían. Los datos son inconsistentes

3 Si A llama a B y luego llama a C, C informa un error y C retrocede. A detecta la excepción de llamada de C y A también retrocederá. después de ejecutarlo se revertirá y los datos serán inconsistentes.

Algunas personas dirán que evito que 3 servicios se llamen entre sí. Solo tengo 2 servicios contactándose entre sí a la vez.

Solo llamaré de A a B y luego de B a. llamar a C

1 A llama a B. Al final del método, si se informa un error antes de A, no se llamará a B. Si no hay ningún error antes, se llamará a B. B se revierte. La excepción se pasa a A, y A también se revierte. Los datos entre A y B serán consistentes, y lo mismo se aplica a B y C. ​​

Lo anterior es correcto. En un entorno ideal, si solo se mantienen dos capas de llamadas y la siguiente llamada de servicio se ejecuta justo antes de enviar la transacción, entonces no hay ningún problema. Sin embargo, existe una situación extrema en el entorno de la red.

A inicia una llamada a B, que se puede dividir en varias partes. A solicita a B ---> B recibe la solicitud y hace lo suyo ---> y luego B responde a A --. > A recibe la respuesta de B.

En este momento, si B lo hace, se envía y luego se agota el tiempo de respuesta a B, A generará un tiempo de espera de respuesta que no sabe si B lo hizo o. no, y A recibirá la excepción de tiempo de espera. Revertir y los datos serán inconsistentes.

Alguien volvió a decir que somos una red interna con ancho de banda ilimitado y casi sin anomalías en la red, por lo que no nos importa. La red no se considera, pero si B confirma la transacción y luego B cuelga, A aún no recibe una respuesta y aún necesita revertir, y aún se producirán inconsistencias de datos. Incluso si se trata de probabilidades pequeñas, el servicio solo puede mantener llamadas de 2 capas, lo que obviamente todavía no es aplicable en sistemas grandes, porque la cadena será muy larga y la llamada será muy inconveniente, y la cadena debe ejecutarse sincrónicamente. Poca eficiencia.

Explique por qué ocurren problemas de coherencia en entornos distribuidos, por lo que las transacciones distribuidas están aquí para resolver estos problemas.

En mi opinión, hay 4 tipos de transacciones distribuidas

El primer tipo son transacciones de 2 piezas y transacciones de 3 piezas, incluido el modo LCN de TX-LCN, que se puede llamar de larga duración. bloqueo de transacciones distribuidas de múltiples segmentos

La transacción de compensación de TCC en la Parte 2 se puede llamar una transacción distribuida de múltiples segmentos de bloqueo corto. Específicamente, la fase de prueba se enviará de forma independiente y no se enviarán varios nodos. esperarse el uno al otro. La fase de comunicación también es independiente entre sí. Es más eficiente que el primer método, pero escribir un método tres veces y escribir una lógica en tres direcciones hace que la codificación sea problemática.

Parte 3, basada en mensajes: la eficiencia no es tan baja como el bloqueo de transacciones distribuidas de múltiples segmentos, y la codificación no es tan problemática como TCC. Pero hay muchos detalles de programación a los que se debe prestar atención. En términos generales, es una solución relativamente completa. El mecanismo de mensajería tiene un defecto obvio: enfatiza garantizar la coherencia final y no puede retroceder al mismo tiempo. El mensaje enviado por el servicio A al servicio B, o el mensaje de confirmación enviado, solo se puede completar. Si B falla, solo puede intentarlo nuevamente (y permanecer idempotente) y A no se puede revertir. Solo el iniciador activo puede terminar y revertir esta transacción distribuida. Una vez enviada la inversión en A, solo puede llegar al final.