distributed-transactions - two phase commit
¿Cómo se evita el bloqueo trifásico? (3)
El compromiso de tres fases no es magia; es más resistente que la confirmación en dos fases. En particular, 3PC es resistente frente a fallas de punto único, pero no a todos los tipos de fallas de puntos múltiples. Ambos escenarios en la pregunta plantean fallas de dos puntos. En otras palabras, la premisa de la pregunta es errónea; Está pidiendo más de 3PC de lo que es capaz de hacer.
Para leer más, aquí hay una oración del resumen de un documento sobre el tema, Análisis y verificación de protocolos de confirmación en dos fases y de confirmación en tres fases , por Muhammad Atif , para despertar su apetito:
También aplicamos nuestro método a su variante "modificada", el Protocolo de Compromiso de Tres Fases (3PC) y probamos que es erróneo por fallas simultáneas en el sitio
Encontré este documento para proporcionar un punto de apoyo en la literatura. No hay una pequeña cantidad de esto en este tema, si quieres profundizar.
Estoy tratando de entender cómo el compromiso de tres fases evita el bloqueo
Considere los siguientes dos escenarios de falla:
Escenario 1: en la fase 2, el coordinador envía mensajes de pre-envío a todas las cohortes y ha recibido un acuse de recibo de todos, excepto la cohorte A. Los problemas de red impiden que la cohorte A reciba el mensaje de pre-envío del coordinador. La cohorte A agota el tiempo de espera para recibir el mensaje de confirmación previa y decide abortar. Luego, tanto el coordinador como la cohorte A se estrellan.
Escenario 2: el protocolo llega a la fase 3. El coordinador envía un mensaje doCommit a la cohorte A. Pero antes de que pueda enviar más mensajes doCommit, el coordinador falla. La cohorte A confirma su parte de la transacción y se bloquea.
Por lo que puedo decir, las cohortes restantes tienen exactamente el mismo estado al final del escenario 1 y del escenario 2. Entonces, cuando un coordinador de recuperación se acerca a cómo puede averiguar a partir de las cohortes restantes si estamos en el escenario 1 y abortamos o ¿Están en el escenario 2 y se comprometen y así evitan el bloqueo?
En el escenario 1:
Durante la recuperación: todas las cohortes, excepto A, estarán en estado PRECOMMIT. Esto le dice al nodo de recuperación que todas las cohortes habían votado por el compromiso y habían avanzado. Así que A y el coordinador deben estar en estado PRECOMMIT. Dado que este es un estado no final, la transacción es abortada.
En el escenario 2:
Durante la recuperación: todas las cohortes, excepto A, estarán en estado PRECOMMIT. Esto le dice al nodo de recuperación que todas las cohortes votaron a favor del compromiso y avanzaron. Pero desde que A recibió el mensaje DoCommit, está en el estado COMPROMETIDO. . Como se produjo un bloqueo (A estrellado), el nodo de recuperación no ve una cohorte en vivo con el estado comprometido y, por lo tanto, deduce que ninguna cohorte recibió el mensaje doCommit. Por lo tanto, la transacción se cancelará y se solicitará a todos los cohortes que liberen recursos.
cuando A regresa de la falla y comienza la recuperación, encontrará que todas las otras cohortes abortaron la transacción y también abortarán la transacción.
En la confirmación de dos fases, el coordinador envía un mensaje de preparación a todos los participantes (nodos) y espera sus respuestas. El coordinador luego envía sus respuestas a todos los otros sitios. Cada participante espera estas respuestas del coordinador antes de comprometerse o abortar la transacción.
El protocolo de confirmación de dos fases también tiene limitaciones porque es un blocking protocol . Por ejemplo, los participantes bloquearán los procesos de recursos mientras esperan un mensaje del coordinador. Si por alguna razón esto falla, el participante continuará esperando y nunca podrá resolver su transacción. Por lo tanto el recurso podría ser bloqueado indefinidamente. Por otro lado, un coordinador también bloqueará los recursos mientras espera las respuestas de los participantes. En este caso, un coordinador también puede bloquear definitivamente si no se recibe un reconocimiento del participante.
Sin embargo, el protocolo de tres fases introduce una tercera fase llamada pre-commit . El objetivo de esto es ''eliminar el período de incertidumbre para los participantes que se han comprometido y están esperando el mensaje global de cancelación o confirmación del coordinador.
When receiving a pre-commit message, participants know that all others have voted to commit.
If a pre-commit message has not been received the participant will abort and release any blocked resources.