————— Al día siguiente —————
————————————
Si no hay una transacción distribuida:
En una serie de sistemas de microservicios, ¿qué pasaría si no hubiera transacciones distribuidas? Tomemos como ejemplo el negocio de transacciones de uso común en Internet:
La figura anterior contiene dos microservicios independientes para inventario y pedido, y cada microservicio mantiene su propia base de datos.
En la lógica de negocios del sistema de comercio, una mercancía necesita llamar al servicio de inventario para deducir el inventario antes de realizar un pedido, y luego llamar al servicio de pedido para crear un registro de pedido.
En circunstancias normales, las dos bases de datos se actualizan correctamente y los datos en ambos lados mantienen la coherencia.
Sin embargo, en circunstancias anormales, es posible que se complete la deducción de inventario y que el registro de pedido posterior no se inserte por alguna razón. En este momento, los datos en ambos lados han perdido su debida consistencia.
¿Qué es una transacción distribuida?
Las transacciones distribuidas se utilizan para garantizar la coherencia de los datos entre diferentes nodos en un sistema distribuido.
Existen muchas implementaciones de transacciones distribuidas, la más representativa de las cuales es el protocolo de transacciones distribuidas XA propuesto por el sistema Oracle Tuxedo.
El protocolo XA incluye dos implementaciones: presentación en dos fases (2PC) y presentación en tres fases (3PC). Aquí nos centramos en el proceso específico de presentación en dos fases.
En el juego de World of Warcraft, cuando el grupo de copia juega el BOSS, para facilitar la colaboración entre el capitán y los miembros del equipo, el capitán puede iniciar una operación de "confirmación in situ":
Cuando el miembro del equipo recibe el mensaje para confirmar la posición, si ya está en su lugar, elija "Sí", si aún no está en su lugar, elija "No".
Cuando el capitán recibe la confirmación del lugar de todas las personas, publicará un mensaje para todos los jugadores, diciéndoles que comiencen a jugar BOSS.
En consecuencia, cuando el capitán inicia la confirmación del asiento, es posible que algunos jugadores no se hayan sentado:
Lo anterior es el proceso de confirmación de grupo jugando BOSS en World of Warcraft. Este proceso es muy similar al compromiso de dos fases del protocolo de transacción distribuido XA.
Entonces, ¿cómo se ve el protocolo XA? Hay dos roles en el protocolo XA: coordinador de transacciones y participante de la transacción.
Echemos un vistazo al proceso de interacción entre ellos:
La primera etapa:
En la primera fase de las transacciones distribuidas XA, el nodo que actúa como coordinador de la transacción enviará primero las solicitudes de preparación a todos los nodos participantes.
Después de recibir la solicitud de preparación, cada nodo participante realizará una actualización de datos relacionada con la transacción y la escribirá en Deshacer registro y Rehacer registro.
Si el participante se ejecuta con éxito, no envía la transacción temporalmente, sino que devuelve un mensaje "completo" al nodo de coordinación de la transacción.
Cuando el coordinador de transacciones recibe los mensajes de devolución de todos los participantes, toda la transacción distribuida entrará en la segunda etapa.
La segunda etapa:
En la segunda fase de las transacciones distribuidas XA, si el nodo coordinador de la transacción ha recibido un retorno positivo antes, emitirá una solicitud de confirmación a todos los participantes de la transacción.
Después de recibir la solicitud de confirmación, los nodos participantes de la transacción confirmarán cada transacción local y liberarán los recursos de bloqueo.
Cuando la transacción local completa la confirmación, devolverá un mensaje "completo" al coordinador de la transacción.
Cuando el coordinador de transacciones recibe comentarios de "finalización" de todos los participantes de la transacción, se completa toda la transacción distribuida.
La primera etapa:
La segunda etapa:
En la primera etapa de XA, si un participante de la transacción informa un mensaje de falla, significa que la transacción local del nodo no fue exitosa y debe revertirse.
Entonces, en la segunda fase, el nodo de coordinación de transacciones envía solicitudes de cancelación a todos los participantes de la transacción.
Después de recibir la solicitud de cancelación, cada nodo participante de la transacción debe realizar la operación de reversión de la transacción localmente, y la operación de reversión se realiza de acuerdo con el registro de deshacer.
Lo anterior es el proceso detallado de la presentación del acuerdo de dos fases XA.
¿Cuáles son las deficiencias de la presentación en dos fases de XA?
1. Problemas de rendimiento
El protocolo XA sigue una fuerte consistencia.
En el proceso de ejecución de la transacción, cada nodo ocupa los recursos de la base de datos. Solo cuando todos los nodos estén listos, el coordinador de la transacción notificará el envío y los participantes liberarán los recursos después del envío.
Tal proceso tiene problemas de rendimiento muy obvios.
2. El único punto de falla del coordinador
El coordinador de transacciones es el núcleo de todo el modelo XA. Una vez que el nodo del coordinador de transacciones cuelga, el participante no recibirá una notificación de confirmación o reversión, y el participante siempre estará en un estado intermedio y no podrá completar la transacción.
3. Inconsistencias causadas por mensajes faltantes.
En la segunda etapa del protocolo XA, si ocurre un problema de red local, algunos participantes de la transacción reciben un mensaje de confirmación, y otra parte de los participantes de la transacción no recibe un mensaje de confirmación, lo que resulta en datos inconsistentes entre los nodos.
¿Cómo evitar los diversos problemas presentados por XA en dos etapas? Hay muchas otras opciones de transacciones distribuidas para elegir:
1. Presentación trifásica XA
La presentación trifásica XA agrega la fase CanCommit sobre la base de la presentación en dos fases e introduce un mecanismo de tiempo de espera.
Una vez que el participante no ha recibido la solicitud de confirmación del coordinador, se comprometerá automáticamente a nivel local.
Esto resuelve efectivamente el problema del único punto de falla del coordinador. Pero los problemas de rendimiento y las inconsistencias aún no se resuelven fundamentalmente.
2. transacción MQ
Use el middleware de mensajes para completar asincrónicamente la segunda mitad de la actualización de la transacción para lograr la consistencia final del sistema.
Este enfoque evita problemas de rendimiento como el protocolo XA.
3. Asuntos de TCC
La transacción TCC es una abreviatura de Try, Commit y Cancel. El modo lógico es similar al XA commit de dos fases, pero el método de implementación se implementa artificialmente a nivel de código.
Aprendizaje interesante de estilo cómico, preste atención al pequeño número público gris del programador para que su aprendizaje ya no sea aburrido.
El último libro publicado del programador Xiaohui: Algoritmo cómico-Algorithm Journey de Xiaohui