protocolo de confirmación de 3 fases

Question

Estaba leyendo el protocolo de confirmación de 3 fases en wikipedia (http://en.wikipedia.org/wiki/Three-phase_commit_protocol) y aquí hay un escenario que me vino a la mente en el que 3PC fallará:

supongamos que hay dos participantes a y B y un Coordinador de C:

1) C envió el mensaje precommit a a y antes de que envía comprometerse de antemano mensaje a B tanto a como C condiciones simultáneamente fallar. 2) La transacción ahora se reinicia y B termina abortándola porque no hay respuesta de A. 3) A confirma la transacción porque ya tiene el mensaje de precomisión.

¿No era este también el problema original en 2PC que se suponía que 3PC debía abordar? ¿Cómo está 3PC resolviendo el problema? Qué me estoy perdiendo. Gracias.

Answer 1

Actualización:

¿Los participantes se comprometen a continuación, hasta que reciban el mensaje doCommit del coordinador?

Después de recibir el mensaje preCommit, los participantes esperarán primero, y si se produce un tiempo de espera, simplemente continuarán para confirmar.

si el coordinador falla después de enviar el mensaje de precomisión y al menos uno de los participantes tiene un mensaje de precomisión, el resto en el sistema puede continuar y confirmar porque ya conocen el estado en el sistema.

Sí, una vez que el nuevo coordinador vea que es un participante que ya recibió el mensaje precompromiso, reenviará mensajes precommitidos a otros participantes.

Answer 2

Si el coordinador se cuelga en algún punto, un nodo de recuperación puede hacerse cargo de la transacción y consultar el estado de las réplicas restantes. Si una réplica que ha comprometido la transacción se ha bloqueado, sabemos que cada otra réplica ha recibido un mensaje de "preparación para la confirmación" (de lo contrario, el coordinador no se habría movido a la fase de confirmación) y, por lo tanto, el nodo de recuperación será capaz de determinar que la transacción pudo ser comprometida, y guiar de manera segura el protocolo hasta su conclusión. Si cualquier de réplicas de informes al nodo de recuperación que no ha recibido 'preparar a cometer', el nodo de recuperación sabrán que la transacción no se ha cometido en cualquier réplica, y por lo tanto serán capaces, ya sea para abortar pesimista o vuelva a ejecutar el protocolo desde el principio.

--cited de http://the-paper-trail.org/blog/consensus-protocols-three-phase-commit/

Así que creo que el nuevo coordinador consultará el estado de las cohortes, sólo cuando todas las cohortes en vivo han recibido pre-entrega de mensajes, a continuación, el nuevo coordinador enviará el do-commit mensaje; de lo contrario, la transacción se cancelará.

Answer 3

3PC solo tolera la falla de un solo punto, no falla en varios puntos. En realidad, para asegurarse de que 3PC funciona, se deben cumplir las tres condiciones siguientes:

1. falta de red (es decir,no hay partición de red, cada mensaje llegará a su destino antes de que se agote el tiempo de espera si la máquina de destino está funcionando (no se bloquea)

2. un máximo de un participante puede fallar (bloqueo). Para hacerlo más preciso, si el coordinador falla (falla), todas las cohortes no deben fallar

3. la máquina participante puede distinguir entre tiempo de espera y falla (esto no es trivial, considere cuándo falla (es decir, se corta la electricidad) justo después del tiempo de espera , donde no podía escribir nada en el almacenamiento persistente para recordar a sí mismo que era un tiempo de espera en lugar de un accidente cuando recupere)

Ninguna de estas condiciones es práctico. Así que no creo que 3PC pueda implementarse en el mundo real.