En redes informáticas y bases de datos , el protocolo de confirmación de tres fases ( 3PC ) [1] es un algoritmo distribuido que permite que todos los nodos de un sistema distribuido acepten realizar una transacción . Es un refinamiento más resistente a fallas del protocolo de compromiso de dos fases (2PC).
Motivación
Una confirmación de dos fases protocolo no puede recuperarse de forma fiable a partir de un fallo tanto del coordinador y un miembro de cohorte durante la fase de confirmación . Si solo el coordinador había fallado y ningún miembro de la cohorte había recibido un mensaje de confirmación, se podría inferir con seguridad que no se había producido ninguna confirmación. Sin embargo, si tanto el coordinador como un miembro de la cohorte fallaron, es posible que el miembro de la cohorte fallado haya sido el primero en ser notificado y haya realizado la confirmación. Incluso si se selecciona un nuevo coordinador, no puede continuar con la operación con confianza hasta que haya recibido un acuerdo de todos los miembros de la cohorte y, por lo tanto, debe bloquear hasta que todos los miembros de la cohorte respondan.
El protocolo de confirmación de tres fases elimina este problema al introducir el estado Preparado para confirmar. Si el coordinador falla antes de enviar mensajes preCommit, la cohorte aceptará unánimemente que la operación fue abortada. El coordinador no enviará un mensaje doCommit hasta que todos los miembros de la cohorte hayan ACK ed que están preparados para comprometerse . Esto elimina la posibilidad de que cualquier miembro de la cohorte haya completado la transacción antes de que todos los miembros de la cohorte se dieran cuenta de la decisión de hacerlo (una ambigüedad que requería un bloqueo indefinido en el protocolo de confirmación de dos fases ).
Solución
La fase de confirmación previa introducida anteriormente ayuda al sistema a recuperarse del caso en el que se produce una falla de un participante o una falla tanto del coordinador como del nodo participante durante la fase de confirmación. Cuando el coordinador de recuperación asume el control después de la falla del coordinador durante la fase de confirmación de la confirmación de dos fases , la nueva confirmación previa es útil de la siguiente manera: al consultar a los participantes, si se entera de que algunos nodos están en la fase de confirmación, entonces asume que el coordinador anterior antes de fallar ha tomado la decisión de comprometerse. Por lo tanto, puede guiar el protocolo para comprometerse. De manera similar, si un participante dice que no recibe el mensaje PrepareToCommit, el nuevo coordinador puede asumir que el coordinador anterior falló incluso antes de completar la fase PrepareToCommit. Por lo tanto, puede asumir con seguridad que ningún otro participante habría cometido los cambios y, por lo tanto, abortaría la transacción de manera segura.
Extensiones
Usando el protocolo de confirmación de tres fases original de Skeen, es posible que un quórum se conecte sin poder avanzar (esta no es una situación de punto muerto; el sistema seguirá progresando si se resuelve la partición de la red). E3PC [2] de Keidar y Dolev refina el protocolo de confirmación de tres fases de Skeen y resuelve este problema de una manera que * siempre * permite que el quórum progrese.
Desventajas
La confirmación trifásica asume una red con retardo limitado y nodos con tiempos de respuesta limitados; En la mayoría de los sistemas prácticos con retrasos de red ilimitados y pausas de proceso, no puede garantizar la atomicidad. El otro inconveniente del protocolo es que requiere al menos tres viajes de ida y vuelta para completar, necesitando un mínimo de tres tiempos de viaje de ida y vuelta (RTT). Esta es potencialmente una latencia larga para completar cada transacción.
Referencias
- ^ Skeen, Dale (febrero de 1982). Un protocolo de compromiso basado en quórum (informe técnico). Departamento de Ciencias de la Computación, Universidad de Cornell.
- ^ Keidar, Idit; Danny Dolev (diciembre de 1998). "Aumento de la resiliencia de los sistemas de bases de datos distribuidos y replicados" . Revista de Ciencias de la Computación y Sistemas . 57 (3): 309–324. doi : 10.1006 / jcss.1998.1566 .