Especificación XA
XA es la especificación de interfaz (es decir, función de interfaz) entre el middleware de transacciones y la base de datos definida por X/Open DTP, que es utilizada por el middleware de transacciones para notificar a la base de datos el inicio, fin, commit, rollback, etc. de las transacciones. Las funciones de interfaz XA son proporcionadas por proveedores de bases de datos.
El acuerdo de presentación de segundo orden y el acuerdo de presentación de tercer orden derivaron de esta idea. Se puede decir que los commits de dos etapas son en realidad la clave para implementar transacciones distribuidas XA (para ser precisos: los commits de dos etapas aseguran principalmente la atomicidad de las transacciones distribuidas: es decir, todos los nodos hacen todo o nada)
2PC
El Compromiso Bifásico se refiere a un algoritmo diseñado para mantener la consistencia en los commits de transacciones para todos los nodos basado en la arquitectura de sistemas distribuidos en el ámbito de redes informáticas y bases de datos. A menudo, un commit de dos etapas también se denomina protocolo. En un sistema distribuido, cada nodo puede conocer el éxito o fracaso de su propia operación, pero no puede conocer el éxito o fracaso de las operaciones de otros nodos. Cuando una transacción abarca varios nodos, para mantener las características ACID de la transacción, debe introducirse un componente que actúe como coordinador para controlar los resultados de todos los nodos (llamados participantes) y, en última instancia, instruir a estos nodos para que realmente envíen los resultados (como escribir datos actualizados en el disco, etc.). Por lo tanto, la idea del algoritmo para la presentación en dos etapas puede resumirse de la siguiente manera: los participantes notificarán al coordinador el éxito o fracaso de la operación, y luego el coordinador decidirá si presenta la operación o la aborta basándose en la información de retroalimentación de todos los participantes.
Las llamadas dos etapas son: la primera: la fase de preparación (fase de votación) y la segunda etapa: la fase de presentación (etapa de ejecución).
Etapa de preparación
El coordinador de transacciones (gestor de transacciones) envía un mensaje de Prepare a cada participante (gestor de recursos), y cada participante o bien devuelve un fallo directamente (como una verificación fallida de permisos), o ejecuta la transacción localmente, escribe registros de rehacer y deshacer localmente, pero no lo compromete, y alcanza un estado de "todo está listo, solo se debe el viento del este".
La etapa de preparación puede dividirse a su vez en los siguientes tres pasos:
1) El nodo coordinador pregunta a todos los nodos participantes si pueden realizar una votación y comienza a esperar una respuesta de cada nodo participante.
2) El nodo participante realiza todas las operaciones de transacción hasta que se inicia la consulta y escribe la información de Deshacer y Rehacer en el registro. (Nota: Si tiene éxito, cada participante ya ha realizado la operación de transacción)
3) Cada nodo participante responde a la consulta iniciada por el nodo coordinador. Si la operación de transacción del nodo participante se ejecuta con éxito, devuelve un mensaje de "Aceptar"; Si la operación de transacción del nodo participante realmente falla, devuelve un mensaje de "abortado".
Fase de envío
Si el coordinador recibe un mensaje de fallo o un tiempo de espera de un participante, enviará un mensaje de retroceso directamente a cada participante. De lo contrario, envía un mensaje de Confirmación; Los participantes realizan operaciones de commit o rollback según las instrucciones del coordinador para liberar todos los recursos de bloqueo utilizados en el proceso de transacción. (Nota: Los recursos de bloqueo deben liberarse en la fase final)
A continuación, el proceso de la fase de presentación se discute por separado en dos casos.
Cuando el mensaje correspondiente recibido por el nodo coordinador de todos los nodos participantes es De acuerdo:
Fase de envío
Si el coordinador recibe un mensaje de fallo o un tiempo de espera de un participante, enviará un mensaje de retroceso directamente a cada participante. De lo contrario, envía un mensaje de Confirmación; Los participantes realizan operaciones de commit o rollback según las instrucciones del coordinador para liberar todos los recursos de bloqueo utilizados en el proceso de transacción. (Nota: Los recursos de bloqueo deben liberarse en la fase final)
A continuación, el proceso de la fase de presentación se discute por separado en dos casos.
Cuando el mensaje correspondiente recibido por el nodo coordinador de todos los nodos participantes es De acuerdo:
1) El nodo coordinador emite una solicitud de "commit" a todos los nodos participantes.
2) El nodo participante completa oficialmente la operación y libera los recursos ocupados durante todo el periodo de la transacción.
3) El nodo participante envía un mensaje de "Hecho" al nodo coordinador.
4) El nodo coordinador completa la transacción tras recibir el mensaje de retroalimentación "Hecho" de todos los nodos participantes.
1) El nodo coordinador emite una solicitud de "rollback" a todos los nodos participantes.
2) El nodo participante utiliza la información de Deshacer previamente escrita para realizar un rollback y liberar los recursos ocupados durante todo el periodo de la transacción.
3) El nodo participante envía un mensaje de "rollback completado" al nodo coordinador.
4) El nodo coordinador cancela la transacción tras recibir el mensaje de retroalimentación "Rollback Complete" de todos los nodos participantes.
Los commits de la fase 2 parecen proporcionar operaciones atómicas, pero desafortunadamente, los commits de la fase 2 aún presentan algunos inconvenientes:
1. Problema de bloqueo síncrono. Durante la ejecución, todos los nodos participantes bloquean transacciones. Cuando un participante ocupa un recurso público, otros nodos de terceros deben ser bloqueados para acceder al recurso público.
2. Punto único de fallo. Debido a la importancia del coordinador, una vez que el coordinador falla. Los participantes seguirán bloqueando el bloqueo. Especialmente en la segunda etapa, si el coordinador falla, todos los participantes siguen en un estado de bloqueo de recursos de transacción y no pueden continuar completando operaciones de transacción. (Si el coordinador cuelga, puedes reelegir a un coordinador, pero no se puede resolver el problema de que el participante esté bloqueado porque el coordinador está caído)
3. Inconsistencia de datos. En la segunda etapa de la segunda etapa del commit, cuando el coordinador envía una solicitud de commit al participante, se produce una excepción de red local o el coordinador falla durante el proceso de solicitud de commit, lo que provoca que solo algunos participantes acepten la solicitud de commit. Tras recibir la solicitud de compromiso, estos participantes realizarán la operación de confirmación. Sin embargo, otras máquinas que no reciben una solicitud de commit no pueden ejecutar el commit de la transacción. Como resultado, la consistencia del departamento de datos ocurre en todo el sistema distribuido.
4. Problemas que no pueden resolverse en la segunda etapa: El coordinador cae tras enviar un mensaje de commit, y el único participante que recibe dicho mensaje también cae. Así que, incluso si el facilitador elige a un nuevo facilitador a través del acuerdo electoral, el estado de la transacción es incierto y nadie sabe si la transacción ha sido presentada.
3PC
El compromiso en tres fases, también conocido como protocolo de compromiso en tres fases, es una versión mejorada del compromiso en dos fases (2PC).
A diferencia de los commits de dos etapas, hay dos cambios en los commits de tres etapas.
1. Introducir un mecanismo de tiempo fuera. Al mismo tiempo, se introduce un mecanismo de tiempo muerto tanto en el facilitador como en los participantes.
2. Insertar una etapa preparatoria en la primera y segunda etapa. Esto garantiza que el estado de todos los nodos participantes sea consistente hasta la etapa final de confirmación.
En otras palabras, además de introducir un mecanismo de tiempo fuera, 3PC vuelve a dividir la etapa de preparación de 2PC en dos, de modo que hay tres etapas de CanCommit, PreCommit y DoCommit en las tres etapas de commit.
Fase CanCommit
La etapa de CanCommit de 3PC es en realidad muy similar a la fase de preparación de 2PC. El coordinador envía una solicitud de compromiso al participante, quien responde Sí si puede comprometerse, o No responde.
1. Consulta de transacción El facilitador envía una solicitud CanCommit al participante. Pregunta si puedes realizar una operación de commit de transacción. Luego empieza a esperar una respuesta de los participantes.
2. Retroalimentación de respuesta Tras recibir la solicitud CanCommit, el participante responderá con Sí y entrará en estado listo si considera que la transacción puede ejecutarse sin interrupciones. Por lo demás, comentarios: No.
Fase de PreCommit
El facilitador decide si memorizar o no la operación de PreCommit de la transacción en función de la respuesta del participante. Dependiendo de la respuesta, hay dos posibilidades.
Si la retroalimentación que recibe el facilitador de todos los participantes es una respuesta de Sí, entonces se realiza la preejecución de la transacción.
1. Enviar una solicitud de PreCommit El facilitador envía una solicitud de PreCommit al participante y pasa a la etapa de Preparación.
2. Pre-Compromiso de Transacción Tras recibir la solicitud de PreCompromiso, realiza la operación de transacción y registra la información de deshacer y rehacer en el registro de transacciones.
3. Retroalimentación de respuesta Si el participante ejecuta con éxito la operación de transacción, se devuelve una respuesta ACK mientras se empieza a esperar la instrucción final.
1. Enviar una solicitud de interrupción El facilitador envía una solicitud de aborto a todos los participantes.
2. Interrumpir la transacción Después de que el participante reciba la solicitud de ABORT del coordinador (o tras el tiempo de espera, si la solicitud del coordinador no ha sido recibida), se ejecuta la interrupción de la transacción.
Esta etapa del compromiso real de transacción también puede dividirse en las siguientes dos situaciones.
Realizar un commit
1. Enviar una solicitud de compromiso Coordinating recibe la respuesta ACK enviada por el participante, luego pasará del estado de pre-commit al estado de compromiso. y enviar una solicitud de doCommit a todos los participantes.
2. Envío de transacciones Tras recibir la solicitud doCommitte, el participante ejecuta el commit formal de la transacción. y liberar todos los recursos de la transacción tras completar el commit de la transacción.
3. Responder a la retroalimentación Después de enviar la transacción, enviar una respuesta Ack al coordinador.
4. Completar la transacción Una vez que el coordinador recibe la respuesta ACK de todos los participantes, la transacción se completa.
Si el coordinador no recibe una respuesta ACK del participante (puede que no sea una respuesta ACK del receptor, o la respuesta puede haber expirado), entonces se ejecuta la transacción de interrupción.
1. Enviar una solicitud de interrupción El facilitador envía una solicitud de aborto a todos los participantes
2. Retroceso de transacciones Tras recibir la solicitud de ABORT, el participante utiliza la información de deshacer registrada en la Fase 2 para realizar la operación de reversión de transacciones y libera todos los recursos de la transacción tras completar el rollback.
3. Resultados de retroalimentación Tras completar la reversión de la transacción, envía un mensaje ACK al coordinador
4. Interrumpir la transacción Después de que el coordinador reciba el mensaje ACK del participante, la transacción se interrumpe.
La diferencia entre 2PC y 3PC
En comparación con 2PC, 3PC resuelve principalmente el problema del punto único de fallo y reduce el bloqueo, porque una vez que el participante no recibe un mensaje del coordinador a tiempo, ejecuta el commit por defecto. En lugar de mantener los recursos de las transacciones todo el tiempo y estar en estado de bloqueo. Pero este mecanismo también causa problemas de consistencia de datos, porque la respuesta de aborto enviada por el coordinador no es recibida en tiempo por el participante debido a razones de red, y luego el participante ejecuta la operación de compromiso tras esperar el tiempo de espera. Esto crea inconsistencias en los datos con otros participantes que reciben la orden de abortar y realizan una retrocesión.
|
Publicado en 17/3/2021 10:15:10
|
|
|
