Prefacio
Este artículo aprende principalmente el algoritmo de consenso de Zookeeper Paxos y el protocolo Zab de coordinación distribuida
Algoritmo de Paxos
El algoritmo Paxos es un algoritmo de consenso basado en el paso de mensajes y altamente tolerante a fallas propuesto por Leslie Lambert en 1990. Actualmente es reconocido como uno de los algoritmos más efectivos para resolver problemas distribuidos.
Problema bizantino
En 1982, Lamport y los otros dos publicaron conjuntamente un artículo y propusieron una teoría de tolerancia a fallas informáticas.Para describir el problema en esta teoría, se asumió una historia relacionada con el problema, de la siguiente manera:
Había muchos ejércitos en el Imperio Bizantino. Los generales de diferentes ejércitos deben formular un plan de acción unificado para tomar la decisión de atacar o retirarse. Al mismo tiempo, los generales estaban separados geográficamente y solo podían depender del ejército. De los corresponsales para comunicarse . Sin embargo, puede haber traidores entre todos los corresponsales, y estos traidores pueden manipular la noticia a voluntad para lograr el propósito de engañar al general.
Este es el conocido problema bizantino, y este problema es similar a lograr consistencia en sistemas asíncronos y protocolos poco confiables en escenarios distribuidos. Más tarde, Lamport propuso una solución de consistencia teórica en 1990, y Chen Shi le dio una prueba matemática estricta, nació el algoritmo de Paxos de esto.
Algoritmo de Paxos
Primero veamos qué puntos deberíamos satisfacer para un algoritmo de consenso:
1. Al final, solo se seleccionó una de las propuestas propuestas
2. Si no hay ninguna propuesta, no hay ninguna propuesta seleccionada al final.
3. Cuando se selecciona la propuesta, todos los clientes deben poder obtener la información de la propuesta.
En el algoritmo de Paxos, hay tres roles: Proponente, Aceptador y Aprendiz, que se comunican entre sí mediante el envío y la recepción de mensajes. En un escenario distribuido, es imposible que exista una sola instancia de Aceptador para evitar una falla en una sola máquina. Por lo tanto, debemos asegurarnos de que la operación de elección se complete en el caso de múltiples Aceptadores. Por lo tanto, podemos especificar que el Proponente envía propuestas a un conjunto de Aceptadores, y Todos los Aceptadores de este conjunto pueden aprobar la propuesta. Cuando hay suficientes Aceptadores para aprobar la propuesta, pensamos que la propuesta está seleccionada, y los llamados suficientes, solo necesitan satisfacer a la mayoría de los Aceptadores propuestas de aprobación en el conjunto de Aceptadores actual Sí, y estipulamos que cada Aceptador solo puede aprobar una propuesta durante un proceso de elección.
Proceso de algoritmo
Todo el proceso del algoritmo de Paxos se puede resumir como un proceso de ejecución del algoritmo de envío de dos etapas, que se divide en una fase de preparación de solicitud y una fase de aceptación de solicitud . El proceso general es el siguiente:
Preparar etapa:
El proponente elegirá una propuesta, y se numerará M0 , luego el Aceptador enviará el conjunto M0 numerado Solicitud de preparación , si esta vez el Aceptador configuró un Aceptador recibió esta solicitud, y el número M0 todo apropiado que la propuesta actual tiene el Si el número máximo es par mayor, entonces el Aceptador necesita retroalimentar el número máximo procesado por sí mismo y no responderá a ninguna solicitud menor que el número M0 . Si no ha respondido a la solicitud, responderá directamente a la solicitud del número M0 actual .
Aceptar etapa:
De manera similar, cuando una solicitud de propuesta enviada por el Proponente recibe una respuesta de más de la mitad del Aceptador en todo el conjunto de Aceptadores , significa que la propuesta se puede generar. En este momento, si más de la mitad de la respuesta no contiene ninguna propuesta información, significa que la propuesta actual está seleccionada. El valor puede ser cualquier valor. Si más de la mitad de la respuesta es otra información de la propuesta, busque el valor de la propuesta con el número más alto, aquí llamado V0 , que forma el Aceptador solicitud de [M0, V0] y la envía de nuevo a todo el conjunto de aceptadores . En este momento, si el Aceptador no aprueba una propuesta con un número superior a v4sp , se considerará que automáticamente acepta la propuesta, y si se obtiene más de la mitad del consentimiento, la propuesta actual se considerará aprobada.
Por supuesto, durante todo el proceso, cada Proponente tiene su propio ciclo para generar diferentes propuestas a intervalos regulares, y se ejecuta estrictamente de acuerdo con el proceso anterior, y al final se garantizará la corrección del algoritmo. Del mismo modo, si el Proponente ha Para generar una propuesta con un número mayor, Aceptar informa al Proponente de la última propuesta más grande acordada de la información recibida con el mayor número , y le pide que abandone su propia propuesta y seleccione la última propuesta con el mayor número.
Acuerdo Zab
Al observar el algoritmo Paxos anterior, podríamos pensar que Zookeeper se basa en la implementación del algoritmo Paxos, pero de hecho, Zookeeper no es un Paxos totalmente adoptado, sino una especie de soporte llamado Zookeeper Atomic Broadcast , abreviado como protocolo ZAB. El protocolo recuperado sirve como algoritmo central para la coherencia de los datos. El protocolo ZAB define el flujo de procesamiento de los mensajes de transacción en todo el Zookeeper, que es aproximadamente el siguiente:
Todas las solicitudes de transacción procesadas por Zookeeper deben tener solo una máquina para coordinar el procesamiento. Dicha máquina se llama servidor Leader, y el resto de los Zookeepers se llaman Seguidores, y el servidor Leader envía las solicitudes de transacción del cliente. A todos los servidores de Follwer, Espere los comentarios de todos los servidores de Follwer. Una vez que reciba los comentarios de más de la mitad de los servidores de Follwer de que el procesamiento de la transacción se completa normalmente, el servidor Leader enviará un mensaje de confirmación a todos los servidores de Follwer nuevamente, solicitando que el Solicitud de transacción para enviar
El protocolo ZAB tiene dos modos básicos, a saber , recuperación de fallos y transmisión de mensajes . Cuando se está ejecutando todo el marco, o cuando el líder tiene una interrupción de la red, falla o reinicia, etc., el protocolo ZAB ingresará al modo de recuperación para reelegir un nuevo servidor líder para procesar las solicitudes de transacciones. Después de seleccionar el servidor líder y la sincronización de estado se logra con más de la mitad de las máquinas, finaliza el modo de recuperación de ZAB. En este momento, se puede ejecutar el modo de transmisión de mensajes de ZAB. Si un nuevo Zookeeper se une al clúster actual durante este proceso, el modo de recuperación se iniciará hasta que se logre la sincronización de estado con el líder.
Al igual que el proceso de procesamiento de transacciones anterior, solo el líder de Zookeeper puede coordinar y procesar las solicitudes de transacción, por lo que ¿son inútiles otros servidores de seguidores? Por supuesto que no. En todo el clúster de Zookeeper, todos los servidores pueden proporcionar procesamiento de solicitudes externas. La única diferencia es que cuando el servidor Seguidor recibe la solicitud de transacción, la reenvía al Líder, lo que permite al Líder realizar un procesamiento y coordinación unificados . Por supuesto, habrá muchos accidentes durante la operación de todo el clúster. Por ejemplo, si más de la mitad de los servidores seguidores no pueden comunicarse con el líder, ingresarán al modo de recuperación de fallas desde el modo de transmisión de mensajes y un nuevo líder serán elegidos de otras máquinas., La misma elección de líder debe ser apoyada por más de la mitad de las máquinas, por lo que cuando todo el grupo tiene más de la mitad de las máquinas que están en servicio normal, el modo se puede cambiar continuamente para garantizar la estabilidad del servicio de clúster Una vez que se excede el número de máquinas con problemas Después de la mitad del clúster, todo el clúster ya no proporciona procesamiento externo de solicitudes de transacciones, ingresa al modo de protección y solo es legible.
Emisión de noticias
La transmisión de mensajes en el protocolo ZAB utiliza un protocolo de transmisión atómico, y el proceso general puede verse como un proceso de confirmación de dos fases. Una vez que llega la solicitud de transacción del cliente, el servidor Leader generará la Propuesta de transacción correspondiente y la enviará a todas las máquinas restantes dentro del clúster actual, y recopilará la información de voto de respuesta de todas las máquinas Follower, y el proceso de segunda etapa es específico. refleja que se ha eliminado el procesamiento lógico de interrupción tradicional de dos etapas. Por lo tanto, en el proceso de recopilar las respuestas de todas las máquinas seguidoras, el líder no necesita esperar a que todas las máquinas respondan antes de ejecutar la segunda etapa, sino que solo necesita esperar a que más de la mitad de las máquinas regresen a la respuesta correspondiente para iniciar la segunda etapa. Por supuesto, en este proceso simplificado de dos etapas, es posible que el líder se bloquee repentinamente, lo que resultará en datos inconsistentes. Por supuesto, cuando esto sucede, debe iniciar el mecanismo de recuperación de fallas para manejarlo, y todos los mensajes tienen características FIFO El protocolo TCP se utiliza para la comunicación en red, a fin de garantizar la secuencia en el proceso de transmisión de mensajes.
En la primera etapa, la máquina Leader generará la Propuesta correspondiente para que se transmita el mensaje de transacción y generará un ID que aumenta monótonamente como el ID de transacción (ZXID) . Dado que el protocolo ZAB debe garantizar el estricto orden ascendente y descendente de las cosas , procesará los mensajes correspondientes en estricta conformidad con la secuencia ZXID. Después de que se inicia la transmisión del mensaje, el Líder asignará una cola separada para cada servidor seguidor y luego almacenará la propuesta de lo que debe transmitirse en la cola FIFO por turno. Después de que cada máquina seguidora reciba el mensaje de transacción, seguir la transacción Se escribe el registro y, después del éxito, se retroalimentará a la respuesta de reconocimiento de la máquina líder. Cuando se reciba más de la mitad de las respuestas de reconocimiento, el líder iniciará la segunda fase del mensaje de confirmación para todas las máquinas seguidoras. , y en este momento, el líder será el mismo que la máquina seguidora Realice la operación de envío de cosas locales, complete la entrega y envío de todo el mensaje .
Recuperación de accidentes
Como mencionamos anteriormente, el mecanismo de recuperación de fallas asegura que la máquina Leader aún pueda garantizar que si algo se procesa con éxito en una máquina, todas las máquinas deberían procesarlo correctamente. Por lo tanto, el mecanismo de recuperación de fallos del protocolo ZAB en su conjunto debe garantizar los dos puntos siguientes:
1. Todas las cosas que se hayan enviado con éxito en el servidor de Leader eventualmente serán enviadas por todos los servidores.
2. Si el líder propuso un mensaje en la primera etapa de la transmisión del mensaje, pero no lo envió, ZAB debe asegurarse de que esta parte del mensaje de transacción se descarte.
Por lo tanto, el protocolo ZAB debe diseñar un algoritmo de elección para asegurar que la propuesta que ha sido enviada por el líder sea enviada, mientras se salta solo la propuesta iniciada por el líder que no ha sido enviada y necesita ser saltada. Por lo tanto, para diseñar el líder electo para que tenga el mayor número de máquinas en el clúster (el ZXID es el más grande), entonces se puede considerar que el líder electo tiene todas las propuestas que se han presentado.
Una vez completada la elección, el proceso de recuperación de fallos no ha finalizado. En este momento, se ingresa el proceso de sincronización de datos. El líder debe confirmar que todas las propuestas en el registro de transacciones han sido enviadas por más de la mitad de los seguidores antes de la se completa la sincronización de datos. Anteriormente, sabemos que el servidor Leader preparará una cola FIFO para todos los seguidores, almacenará todas las cosas que deben enviarse y notificará a los seguidores que cuando todos los registros de la cola hayan sido enviados y borrados por el seguidor, esto significa que la sincronización de datos se completa. El seguidor se agregará a la lista de máquinas disponibles, hasta que la cantidad de máquinas disponibles en la lista sea más de la mitad, comenzará directamente a completar el proceso de recuperación de fallas, cambiará el modo a transmisión de mensajes, y proporcionar servicios de Zookeeper al exterior.
De manera similar, las cosas enviadas en el Líder están sincronizadas, entonces, ¿cómo eliminar las cosas obsoletas no comprometidas? En el diseño ZXID del protocolo ZAB, es un número de 64 bits, que se divide en 32 bits bajos y 32 bits altos. Los 32 bits bajos se pueden considerar como un contador que aumenta monótonamente. Antes de que cada mensaje de transacción genere un ID, los 32 Bits bajos realizarán operaciones atómicas +1. Los 32 bits altos de ZXID representan el número de la época, y la época es el proceso de cada elección de un nuevo líder, obtendrá el mayor de todas las cosas ZXID, y luego analizará el valor de la época alta correspondiente de 32, Entonces es +1, que representa el número de elecciones, es decir, el ciclo de vida del Líder, y después de cada elección, después de la época + 1, el valor de los 32 bits inferiores se borrará como el nuevo valor ZXID . Por lo tanto, cuando el valor de época representado por el ZXID de algunas máquinas es bajo durante el proceso de activación de la elección, estas máquinas se convertirán directamente en Seguidores, y solo las mismas máquinas con la época más grande elegirán al Líder , y cuando el Líder sea elegido en el En el futuro, después de que todos los Seguidores estén conectados al Líder, compararán la propuesta más grande actual con el Líder. En este momento, el líder requiere la reversión o sincronización de la propuesta con la propuesta de transacción más grande enviada por más de la mitad de las máquinas en el clúster actual de acuerdo con la comparación. En este punto, la operación de sincronización de datos está completa. El modo de recuperación de fallos finaliza.