El protocolo de consenso es permitir que varios nodos decidan algo juntos. Esto puede ser un número, una decisión (sí o no) o una instrucción (representación de cadena).
En un sistema distribuido, los modelos de errores comunes se dividen en dos categorías, una es errores no bizantinos, este modelo significa que los nodos no pueden responder (apagado inesperado), pero no pueden enviar errores (enviar mensajes de error deliberadamente, inducir a otros nodos a hacer una error), de acuerdo con el comportamiento después de no responder, se puede dividir en dos categorías. Una es que nunca volverá después de que ocurra un error. Esto se llama fail-stop, y la otra es que se recupera más tarde. Esto es llamado recuperación ante fallas. El segundo tipo es el modelo de error bizantino, los nodos no solo pueden no responder, sino también fabricar información falsa para inducir a otros nodos a tomar decisiones equivocadas.
Los sistemas distribuidos se basan en el entorno de red, y los errores en el entorno de red son errores comunes en los sistemas distribuidos.Específicamente, abstraemos el modelo del entorno de red en tres tipos de errores.
-
Red síncrona Red
síncrona significa que el tiempo de transmisión de la red tiene un límite superior. ¿Qué significa eso? Significa enviar un mensaje, podemos estar seguros de que la otra parte lo recibirá, y dentro de un tiempo fijo. Este tiempo puede ser muy largo, un día, un año, o hasta 100 millones de años, no importa, pero tiene un término previo fijo. -
Redes asíncronas
Redes asíncronas significa que la red envía tiempo sin la última sesión. En otras palabras, no sabemos si la otra parte ha recibido el mensaje que enviamos. Según este modelo, siempre que haya un error de nodo, ya sea un error bizantino o no bizantino, no se puede llegar a un consenso. -
Red semisíncrona
Esto significa que la transmisión de la red tiene un límite de tiempo, pero no sabemos cuánto es el tiempo. Es decir, no podemos utilizar el mecanismo de tiempo de espera en el protocolo de consenso. Generalmente, los protocolos de consenso que discutimos están bajo el modelo sincrónico o semisincrónico.
cual es el protocolo correcto
Hay dos criterios característicos.
el primero es:
- acuerdo
- validez
- La terminación
segunda es: - exactitud
- vivacidad
其中，el acuerdo y la validez corresponden a la corrección y la terminación corresponde a la propiedad viva.
Protocolo de consenso no bizantino
El problema no bizantino se puede resumir (simplificar) como llamar a 10 (sin incluirte) compañeros de clase para cenar juntos.¿Cómo deberías hacerlo? Lo que debe garantizarse es: 1. Los 11 estudiantes llegarán o no. Ningún estudiante irá y algunos estudiantes no irán. 2. Al final, todos deben llegar a una conclusión. Es mejor no ir.
2pc
En nuestra vida diaria, la forma más común que usamos es llamar a todos primero y preguntar: "¿Estás libre para cenar mañana a las 6 en punto?" Cuando todos responden: "Disponible", llamas a todos Personal: "Está confirmado , cenamos mañana a las 6 en punto, y las 11 personas estarán allí "; Hora para ti".
Correspondiente al acuerdo, es un acuerdo típico de dos etapas: en la primera etapa, proponer primero, recopilar las opiniones de todos y dejar que todos reserven un tiempo (bloquear recursos), en la segunda etapa, en base a la retroalimentación de todos, decidir “reunir O "no juntos". Una vez que el coordinador (usted) toma esta decisión, es la decisión final y debe sincronizarse con la otra parte. Incluso si la otra parte no responde a sus llamadas, debe mantenerse en contacto con la otra parte para informar la decisión. De lo contrario, la otra parte siempre bloqueará el recurso (hora de reserva mañana a las 6 en punto). Así que 2pc es un protocolo de bloqueo, y no puedo programar nada mañana a las 6 sin que el coordinador me diga la decisión final. Este es también el mayor problema de este acuerdo, por ejemplo, en la segunda etapa, el coordinador está ocupado con otras cosas, y los 10 estudiantes no pueden comunicarse con él, y todos tienen que esperar.
3pc
2pc se propuso en 1970. Para superar el mayor problema mencionado anteriormente, en la década de 1980, alguien propuso el protocolo 3pc. El propósito es pensar que en la segunda etapa, después de que el coordinador cuelga, otros participantes pueden volver a seleccionar al coordinador y adivinar la decisión del coordinador original preguntándose entre sí sobre el estado de otros nodos. 3pc divide la segunda fase (commit) en pequeñas fases: pre-commit, commit. Al introducir el compromiso previo, es equivalente a agregar un estado entre la propuesta y el envío: compromiso previo. Este envío previo es un estado intermedio. Después de estar en este estado, todas las migraciones normales solo pueden pasar al estado de envío. En el protocolo de dos fases, el estado de preparación puede pasar al estado de confirmación o al estado de cancelación. Esto es el bloqueo causado por el protocolo de dos fases La razón fundamental es que cuando todos los nodos participantes están en este estado listo, si el coordinador cuelga, los participantes no sabrán a qué rama migrar. Por lo tanto, necesitamos aumentar la comunicación en el protocolo de dos fases o registrar más información para ayudar al proceso posterior a obtener más información para adivinar el estado global cuando ocurre el error. En el protocolo de tres fases, el estado de compromiso previo indica que todos los nodos han aceptado enviar la transacción. Para mantener más pistas, el nodo coordinador envía esta conclusión a todos los nodos participantes a través del compromiso previo. Después de recibir el mensaje, los nodos participantes envían el estado. También se cambia a confirmación previa y, al mismo tiempo, se devuelve un mensaje de confirmación al nodo coordinador. Una vez en el estado previo a la confirmación, la migración normal solo puede pasar al estado de confirmación.
Cuando el coordinador cuelga después de la confirmación previa y antes de la confirmación, se puede seleccionar cualquier nodo como el nuevo coordinador (la forma simple es seleccionar el número de nodo más grande o más pequeño). El nuevo coordinador pregunta el estado de todos los demás nodos que están activos:
- Si alguno está presentando, se puede determinar que el antiguo coordinador debe estar en la etapa de pre-presentación, por lo que la decisión final es presentar, porque todas las etapas están listas para presentar;
- Si alguno está en el estado de envío previo, continúe con el proceso de 3 piezas.
- De lo contrario, cancela la transacción.
Lo único que se debe tener en cuenta es que cuando un nodo fallido se recupera, si se encuentra en la etapa previa a la confirmación, primero debe solicitar el estado a otros nodos, o esperar a que el nuevo coordinador envíe instrucciones, y no puede migrar directamente para confirmar por sí mismo. . Porque: es posible que sea el único nodo que recibe la confirmación previa, y luego tanto él como el coordinador cuelgan, el coordinador recién elegido contacta a otros nodos y descubre que ningún nodo tiene un estado más alto que la confirmación previa, y luego Transacción cancelada.
Ninguna base de datos comercial o producto de software actualmente usa 3pc, principalmente porque es más complicado terminar el protocolo y no puede manejar los problemas causados por las particiones de la red.