Programa de resolución común
- La solución de transacciones distribuidas puede utilizar transacciones globales 2pc (protocolo de envío de dos etapas), 3pc (protocolo de envío de tres etapas), mecanismo de compensación tcc, proporcionar interfaz de reversión, base de datos distribuida
- El núcleo LCN utiliza un mecanismo de compensación 3PC + TCC
¿Qué es la interfaz XA?
XA-eXtended Architecture significa que la transacción distribuida
XA en la transacción es completada por el coordinador (coordinador, generalmente administrador de transacciones) y el participante (participantes, generalmente cada recurso tiene su propio administrador de recursos). En MySQL, hay dos tipos de transacciones XA.
Que es 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 se basa en la arquitectura XA. En JTA, el administrador de transacciones se abstrae como la interfaz javax.transaction.TransactionManager Y a través del servicio de transacciones subyacente (es decir, JTS) para lograrlo. Como muchas otras especificaciones de Java, JTA solo define interfaces, y la implementación específica la proporcionan los proveedores (como los proveedores de J2EE). La implementación actual de JTA se compone principalmente de lo siguiente:
1. Implementación de JTA proporcionada por el contenedor J2EE (JBoss)
2. Implementación de JTA independiente: como JOTM, Atomikos Estas implementaciones se pueden utilizar en entornos que no utilizan servidores de aplicaciones J2EE para proporcionar garantías de transacciones distribuidas. Como Tomcat, Jetty y aplicaciones Java ordinarias.
2PC de dos etapas presentación
Las denominadas dos fases se refieren a: la primera fase: fase de preparación (fase de votación) y la segunda fase: fase de presentación (fase de ejecución) .
XA generalmente se completa en dos fases, llamadas compromiso de dos fases (2PC).
La fase uno es la fase de preparación, es decir, todos los participantes se preparan para ejecutar la transacción y bloquear los recursos necesarios. Cuando los participantes están listos, informan al administrador de transacciones que están listos.
La segunda fase es la fase de presentación. Cuando el administrador de transacciones confirma que todos los participantes están listos, envía un comando de confirmación a todos los participantes.
Como se muestra abajo:
Problema de rendimiento de XA El rendimiento de
XA es muy bajo. Una comparación del rendimiento de una transacción de base de datos y el rendimiento de la transacción XA entre varias bases de datos muestra que el rendimiento es aproximadamente 10 veces peor. Por lo tanto, las transacciones XA deben evitarse tanto como sea posible, por ejemplo, los datos se pueden escribir en el local y los datos se pueden distribuir con un sistema de mensajería de alto rendimiento. O utilice técnicas como la replicación de bases de datos.
XA solo debe usarse cuando no se puede lograr ninguno de estos y el rendimiento no es un cuello de botella.
De tres etapas 3PC presentación
La confirmación de tres fases, también llamada protocolo de confirmación de tres fases, es una versión mejorada de la confirmación de dos fases (2PC).
A diferencia de la confirmación de dos fases, la confirmación de tres fases tiene dos cambios.
1. Introduzca un mecanismo de tiempo de espera. Al mismo tiempo, se introduce un mecanismo de timeout tanto en el coordinador como en los participantes.
2. Inserte una fase de preparación en la primera y segunda fase. Se garantiza que el estado de cada nodo participante sea coherente antes de la etapa de envío final.
En otras palabras, además de introducir un mecanismo de tiempo de espera, 3PC divide la fase de preparación de 2PC en dos nuevamente, de modo que el envío de tres fases tiene tres fases: CanCommit, PreCommit y DoCommit.
Etapa CanCommit
La fase CanCommit de 3PC es en realidad muy similar a la fase de preparación de 2PC. El coordinador envía una solicitud de confirmación al participante, y el participante devuelve una respuesta Sí si puede enviar; de lo contrario, devuelve una respuesta No.
1. Consulta de transacción El coordinador envía una solicitud de CanCommit al participante. Pregunte si se puede realizar la operación de confirmación de la transacción. Luego comience a esperar la respuesta del participante.
2. Comentarios de respuesta Una vez que el participante recibe la solicitud de CanCommit, en circunstancias normales, si cree que puede ejecutar la transacción sin problemas, devolverá una respuesta Sí y entrará en el estado listo. De lo contrario, retroalimentación No
Etapa de compromiso previo
El coordinador decide si la operación PreCommit de la transacción memorable se puede determinar de acuerdo con la reacción de los participantes. Según la respuesta, existen las siguientes dos posibilidades.
Si la retroalimentación del coordinador de todos los participantes es una respuesta Sí, entonces se ejecutará la ejecución previa de la transacción.
1. Envíe una solicitud de compromiso previo El coordinador envía una solicitud de compromiso previo al participante y entra en la fase Preparada.
2. Después de que el participante de la transacción previa a la confirmación reciba la solicitud de la transacción previa, ejecutará la operación de transacción y registrará la información de deshacer y rehacer en el registro de transacciones.
3. Comentarios de respuesta Si el participante ejecuta con éxito la operación de transacción, devolverá una respuesta ACK y comenzará a esperar la instrucción final.
Si algún participante envía una respuesta No al coordinador, o después de esperar un tiempo de espera, el coordinador no recibe una respuesta del participante, entonces la transacción se interrumpe.
1. Enviar una solicitud de interrupción El coordinador envía una solicitud de interrupción a todos los participantes.
2. Después de que el participante de la transacción de interrupción recibe la solicitud de cancelación del coordinador (o después del tiempo de espera, la solicitud del coordinador aún no se ha recibido), la transacción se interrumpe.
etapa doCommit
El compromiso de transacción real en esta etapa también se puede dividir en las dos situaciones siguientes.
Ejecutar compromiso
1. Envíe la solicitud de envío para coordinar la recepción de la respuesta ACK enviada por el participante, luego ingresará al estado de envío desde el estado de compromiso previo. Y envíe una solicitud doCommit a todos los participantes.
2. Después de que el participante del envío de la transacción recibe la solicitud doCommit, ejecuta el envío formal de la transacción. Y libere todos los recursos de la transacción después de completar la confirmación de la transacción.
3. Después de que se envía la transacción de retroalimentación de respuesta , se envía una respuesta Ack al coordinador.
4. Después de la finalización de la transacción, el coordinador completa la transacción después de recibir la respuesta de confirmación de todos los participantes.
El coordinador de la transacción de interrupción no recibe la respuesta ACK enviada por el participante (tal vez el receptor no envió una respuesta ACK o la respuesta agotó el tiempo de espera), entonces se ejecutará la transacción de interrupción.
1. Enviar una solicitud de interrupción El coordinador envía una solicitud de interrupción a todos los participantes
2. Una vez que el participante de reversión de la transacción recibe la solicitud de cancelación, utiliza la información de deshacer registrada en la fase 2 para realizar la operación de reversión de la transacción y libera todos los recursos de la transacción después de que se completa la reversión.
3. Una vez que el participante con el resultado de la retroalimentación completa la reversión de la transacción, envía un mensaje ACK al coordinador.
4. Después de que el coordinador de transacción de interrupción recibe el mensaje ACK retroalimentado por el participante, ejecuta la interrupción de la transacción.
En la fase doCommit, si el participante no puede recibir la solicitud doCommit o rebort del coordinador a tiempo, la transacción continuará enviándose después del tiempo de espera. (En realidad, esto debe determinarse con base en la probabilidad. Al ingresar a la tercera etapa, significa que el participante ha recibido la solicitud de PreCommit en la segunda etapa, por lo que la condición previa para que el coordinador genere la solicitud de PreCommit es que reciba antes de la segunda comienza la etapa. La respuesta de CanCommit a todos los participantes es Sí. (Una vez que el participante recibe el PreCommit, significa que sabe que todos han acordado modificarlo) Entonces, en una oración, al ingresar a la tercera etapa, debido al tiempo de espera de la red y otras razones, aunque el participante no recibió una respuesta de confirmación o aborto, pero tiene razones para creer que la probabilidad de una presentación exitosa es muy alta).
La diferencia entre 2PC y 3PC
En comparación con 2PC, 3PC resuelve principalmente el problema del punto único de falla y reduce la congestión, porque una vez que el participante no puede recibir la información del coordinador a tiempo, ejecutará el compromiso de forma predeterminada. No siempre contendrá recursos de transacción y estará en un estado de bloqueo. Sin embargo, este mecanismo también puede causar problemas de coherencia de datos, ya que, por motivos de red, el participante no recibe a tiempo la respuesta de aborto enviada por el coordinador, por lo que el participante realiza la operación de compromiso después del tiempo de espera. De esta manera, existe una inconsistencia de datos con otros participantes que recibieron el comando de cancelación y realizaron la reversión.
TCC
La etapa de PRUEBA es principalmente para verificar el sistema comercial y reservar recursos.
La fase de CONFIRMACIÓN es principalmente para confirmar y enviar el sistema de negocios, cuando la fase de PRUEBA se ejecuta con éxito y comienza la fase de CONFIRMACIÓN, la fase de CONFIRMACIÓN predeterminada no cometerá errores. Es decir: siempre que INTENTAR tenga éxito, CONFIRMAR debe tener éxito.
La fase de CANCELACIÓN es principalmente para cancelar el negocio ejecutado en el estado de error de ejecución del negocio y necesita ser revertido, y se liberan los recursos reservados.
Idempotence significa que los resultados de la ejecución de una llamada a un método empresarial una vez y varias veces son los mismos.
Dé un ejemplo de elementos de pago:
Una vez que el sistema de pago recibe la solicitud de pago del miembro, debe deducir el saldo de la cuenta del miembro y aumentar los puntos del miembro (por el momento, se supone que se requiere sincronización) para aumentar el saldo de la cuenta del comerciante.
Supongamos nuevamente: el sistema de membresía, el sistema de comerciantes y el sistema de puntos son tres subsistemas independientes, que no pueden ser procesados por métodos comerciales tradicionales.
Etapa de PRUEBA: Lo que tenemos que hacer es reservar los fondos de la cuenta de fondos del miembro, es decir: congelar el monto de la cuenta del miembro (monto del pedido)
Fase de CONFIRMACIÓN: Lo que tenemos que hacer es aumentar el saldo de puntos de la cuenta de puntos del miembro y aumentar el saldo de la cuenta de comerciante.
Etapa de CANCELACIÓN: lo que debe ejecutarse en esta etapa es descongelar y liberar nuestro saldo de miembro deducido
MQ distribuyó cosas
Al usar MQ con alta puntualidad, la otra parte se suscribe a los mensajes y los monitorea, y automáticamente activa eventos cuando hay mensajes.
Se utilizan sondeos y escaneos regulares para verificar los datos en la tabla de mensajes.
Otra compensación
Los estudiantes que han realizado la interfaz de transacción de Alipay saben que generalmente desciframos los parámetros en la página de devolución de llamada y la interfaz de Alipay, y luego llamamos al servicio relacionado para actualizar el estado de la transacción en el sistema para actualizar el pedido al éxito del pago. Al mismo tiempo, Alipay detendrá la solicitud de devolución de llamada solo cuando aparezca la palabra "éxito" en nuestra página de devolución de llamada o el código de estado correspondiente que indique que la empresa se ha procesado correctamente. De lo contrario, Alipay iniciará una solicitud de devolución de llamada al cliente después de un período de tiempo hasta que se emita la identificación exitosa.
De hecho, este es un ejemplo de compensación muy típico, similar a algunos mecanismos de compensación de reintento MQ.
En un sistema generalmente maduro, la disponibilidad general de servicios e interfaces de nivel superior suele ser muy alta. Si algunos servicios se deben a fallas transitorias de la red o tiempos de espera de llamadas, este mecanismo de reintento es realmente muy efectivo.
Por supuesto, considere un escenario más extremo: si el sistema en sí tiene un error o hay un problema con la lógica del programa, no ayudará reintentar 1W veces. ¿No sería una tragedia como "Obviamente pagado, pero demuestra que el pago no se entrega"?
De hecho, para que el sistema comercial sea más confiable, generalmente agregamos registros de registro detallados a los códigos de servicio de alto nivel, como las transacciones. Una vez que ocurre una excepción fatal en el sistema, habrá notificaciones por correo electrónico. Al mismo tiempo, habrá tareas regulares en segundo plano para escanear y analizar dichos registros, verificar esta situación especial, intentar compensar a través del programa y notificar al personal relevante por correo electrónico.
En algunas circunstancias especiales, habrá una "compensación artificial", que también es la última barrera.