Solución de transacciones distribuidas TCC
Intento de preprocesamiento: inspección comercial y reserva de recursos.
Confirmar: Confirmar el negocio.
Deshacer cancelación: realiza la operación de reversión.
TM primero iniciará la operación de prueba de todas las transacciones de la sucursal. Si falla la operación de prueba de cualquier transacción de sucursal, TM iniciará la operación de Cancelación de todas las transacciones de sucursal. Si todos los intentos tienen éxito, TM iniciará operaciones de confirmación para todas las transacciones de la sucursal. Entre ellos, si las operaciones de confirmación y cancelación fallan, TM volverá a intentarlo.
1) La fase de prueba es para la verificación del negocio (consistencia) y la reserva de recursos (aislamiento).
2)2) La fase de confirmación es una confirmación y todas las transacciones de sucursal en la fase de prueba se ejecutan con éxito para iniciar la confirmación.
Generalmente, cuando se utiliza TCC, se cree que no se producirán errores durante la fase de confirmación. Mientras el intento tenga éxito, la confirmación tendrá éxito. Si hay un error al confirmar, inténtelo nuevamente o hágalo manualmente.
3) La fase de cancelación consiste en cancelar otras transacciones de sucursales no fallidas cuando un error de ejecución comercial requiere reversión, es decir, liberar recursos reservados.
En general, la fase de cancelación de TCC también se considera exitosa, y si hay un error, se introduce un reintento o procesamiento manual.
Todos los siguientes marcos admiten transacciones globales de TCC. En la actualidad, Alibaba seata tiene una enorme base de usuarios y la cantidad de estrellas en github también está muy por delante. El código fuente real de seata aumentará gradualmente.
En la fase de prueba, supongamos que se envía una solicitud de prueba al servicio A y que la red se agota por motivos de red. En este momento, el coordinador recibe una respuesta de tiempo de espera de la red y debe cancelarla en el segundo paso. Sin embargo, el Servicio A no tuvo ningún éxito durante la fase de prueba, lo que provocó una inconsistencia en los datos.
La clave para resolver el problema es cómo identificar si el servicio A se ejecuta con éxito durante la fase de prueba. Si tiene éxito, se ejecutará la confirmación. Si falla, se ejecutará una reversión vacía. Puede agregar una tabla de registro de transacciones de sucursales para registrar las transacciones de sucursales y los ID de transacciones globales. Cuando se agota el tiempo de espera de una solicitud, puede ver la transacción de la sucursal a través de esta tabla y, si ejecuta un intento, la registrará. Si no lo haces quedará en blanco.
Principalmente en etapa de juicio. Consulta antes de la confirmación o cancelación agregando una tabla de estado de transacción.
Un requisito más estricto es agregar bloqueos distribuidos.
Debido al tiempo de espera y otras razones, cancelar se ejecuta antes de intentarlo, lo cual es un problema de bloqueo.
La solución es agregar una tabla de registro de transacciones de sucursales y consultarla primero. Si se ha ejecutado cancelar, no se ejecutará try.