Commit de dos fases

De Wikipedia, la enciclopedia libre
Saltar a: navegación, búsqueda

El protocolo commit de dos fases, también conocido por las siglas 2PC (del inglés 2-Phase Commit), es un protocolo de consenso distribuido que permite a todos los nodos de un sistema distribuido ponerse de acuerdo para hacer commit a una transacción. Típicamente es usado en Bases de datos distribuidas. El objetivo del protocolo es que todos los nodos realicen commit de la transacción o la aborten.

Las dos fases del algoritmo son la fase de petición de commit, en el cual el coordinador intenta preparar a todos los demás, y la fase commit, en la cual el coordinador completa las transacciones a todos los demás participantes.

Descripción general[editar]

El algoritmo está basado en la existencia de un coordinador (al resto de nodos de la red se les llama participantes) y se divide en dos fases:[1]

  • Fase de preparación de commit, en la cual el coordinador intenta preparar a todos para el commit contactando con todas las réplicas que participan, las cuales contestan si aceptan o abortan la transacción.
  • Fase commit. Cuando todas las réplicas han respondido el coordinador busca los conflictos si los hay.
    • Si se detecta un conflicto en los mensaje enviados por las réplicas o una réplica indica que la transacción tiene que ser abortada, el acuerdo será abortado y el coordinador enviará un mensaje a todas las réplicas para que aborten la transacción.
    • Si no se detectan conflictos entonces el coordinador indica a todos realizar el commit. Después de que todas las réplicas realizan el commit envían un mensaje de confirmación al coordinador.

El protocolo asume que:

  • Hay almacenamiento estable en cada nodo con un sistema de log write-ahead (implica que aunque el nodo se caiga estos datos nunca se pierden o corrompen)
  • Los nodos no están siempre caídos. Si alguna réplica o el coordinador falla siempre el sistema falla.
  • Dos nodos cualquiera pueden comunicarse unos con los otros. Esto no es muy restrictivo, ya que la comunicación de redes puede ser re-enrutada normalmente.

Las primeras dos suposiciones son fuertes ya que si un nodo está totalmente destruido se pone en riesgo estas suposiciones.

Algoritmo básico[editar]

Fase de petición del Commit[editar]

  1. El coordinador envía un mensaje consulta para commit a todos los participantes.
  2. Los participantes ejecutan la transacción hasta el punto donde ellos serán preguntados para realizar commit. Ellos pueden escribir una entrada a su log undo(log de deshacer) y una entrada a su log redo(log de rehacer).
  3. Cada participante responde con un mensaje acuerdo si la transacción tuvo éxito, o un mensaje abortar si falló la transacción.
  4. El Coordinador espera hasta que tenga un mensaje de cada participante.

Fase Commit[editar]

Éxito[editar]

Si el coordinador de esta página recibió un mensaje acuerdo de todos los participantes durante la fase de petición de commit:

  1. El coordinador envía un mensaje commit a todos los participantes.
  2. Cada participante completa la operación, y libera todos los bloqueos y recursos mantenidos durante la transacción.
  3. Cada participante envía un reconocimiento(ack) al coordinador.
  4. El coordinador completa la transacción cuando ha recibido todos los reconocimientos.

Fracaso[editar]

Si algún participante envió un mensaje abortar durante la fase de petición de commit:

  1. El coordinador envía un mensaje rollback a todos los participantes.
  2. Cada participante deshace la transacción usando el log undo(log de deshacer), y libera los recursos y bloqueos mantenidos durante la transacción.
  3. Cada participante envía un reconocimiento(ack) al coordinador.
  4. El Coordinador completa la transacción cuando han sido recibidos los reconocimientos.

Desventajas[editar]

La mayor desventaja del protocolo commit en dos fases es el hecho de que es un protocolo bloqueante. Un nodo estará bloqueado mientras esté esperando un mensaje. Esto significa que otros procesos compiten por los bloqueos de recursos mantenidos por los procesos bloqueados tendrán que esperar a que los bloqueos sean liberados. Un nodo individual continuará incluso si otros sites han fallado. Si el coordinador falla permanentemente, algunos participantes nunca resolverán sus transacciones. Esto tiene el efecto de que los recursos están siempre comprometidos. El algoritmo puede bloquear indefinidamente de la siguiente forma: si un participante ha enviado un mensaje acuerdo al coordinador, se bloqueará hasta que un commit o rollback sea recibido. Si el coordinador está permanentemente caído, el participante bloqueará indefinidamente, a menos que pueda obtener la decisión global commit/abort desde uno de los participantes. Cuando el coordinador ha enviado "consulta para commit" a los participantes, esto bloqueará hasta que todos los participantes hayan enviado su decisión local. Más aún, si un participante está permanentemente caído, el coordinador no bloqueará indefinidamente: Dado que el coordinador es el único en decidir si la decisión es 'commit' o 'abort' el bloqueado permanente puede evitarse introduciendo un timeout: Si el coordinador no ha recibido todos los mensajes esperados cuando ha pasado el timeout decidirá 'abortar'. Este comportamiento conservador del protocolo es otra desventaja: Se predispone al caso de aborto en lugar del caso completo.

Además el protocolo descansa sobre el funcionamiento correcto del coordinador. Otra versión de este protocolo no necesita coordinador y permite que los clientes envíen los mensajes de preparación a todas las réplicas. Quitando al coordinador el rendimiento del sistema debería mejorar. La desventaja e un incremento en la probabilidad de conflicto ya que múltiples clientes pueden segerir distintos valores.[1]

Protocolo commit de dos fases en árbol[editar]

Una variante común del 2PC es el Protocolo Tree 2PC(en árbol). En esta variante el coordinador es la raíz ("top") de un árbol de comunicaciones, mientras los participantes son los otros nodos. Los mensajes desde el coordinador son propagados "hacia abajo" en el árbol, mientras los mensajes al coordinador son "recolectados" por un participante desde todos los participantes que hay debajo, antes de que esto envie el mensaje apropiado "hacia arriba" por el árbol (excepto con un mensaje "abortar", el cual es propagado "hacia arriba" inmediatamente hasta que se reciba, o si este participante decide abortar).

El protocolo commit de dos fases dinámico (Dynamic two-phase commitment, D2PC) es una variante del Tree 2PC sin coordinador predeterminado. Los mensajes Acuerdo comienzan propagándose a todas las hojas, cada hoja cuando completa sus tareas a favor(¿behalf?) de la transacción, y el coordinador es determinado dinámicamente por los mensajes de acuerdo en carrera, en los lugares donde se concentran/colisionan. Ellos se concentran/colisionan en un nodo árbol de la transacción, o en un cable. En el último caso uno de los nodos que están al extremo del cable es elegido como un coordinador (cualquier nodo). D2PC es óptimo respecto al tiempo (entre todas las instancias de un árbol de transacción específico, y cualquier implementación de protocolo específica Tree 2PC; todas las instancias tienen el mismo árbol; cada instancia tiene un nodo diferente como coordinador): esto realiza commit al coordinador y cada participante en el tiempo mínimo posible, permitiendo la liberación temprana de los recursos bloqueados.

Véase también[editar]