Principios detallados de Zookeeper (3): protocolo Zab
1. El protocolo Zab es un protocolo de transmisión atómica especialmente diseñado que admite la recuperación tras fallos y es el algoritmo central de Zookeeper para garantizar la coherencia de los datos.
2. En el proceso en el que Zookeeper confía en el protocolo Zab para garantizar la coherencia de los datos, según este protocolo, Zookeeper implementa una arquitectura de modelo maestro-en espera (líder + seguidor) en el clúster para garantizar la coherencia entre cada uno. copia de la coherencia de los datos. El líder es responsable de procesar las solicitudes de transacciones de escritura y luego sincroniza los datos con los nodos seguidores.
3. El cliente zookeeper se conectará aleatoriamente a un nodo en el clúster. Si es una solicitud de lectura, leerá datos del nodo actual. Si es una solicitud de escritura, los enviará. la solicitud de transacción del nodo líder, después de que el nodo líder reciba el envío de la transacción, transmitirá la transacción. Si más de la mitad de los nodos escriben correctamente, la transacción se enviará.
1.El protocolo Zab debe garantizar que las transacciones enviadas en el servidor líder eventualmente serán enviadas por todos los servidores.
2. El protocolo Zab debe garantizar que las transacciones propuestas en el servidor líder no se confirmen.
1. Utilice el proceso principal (líder) para aceptar y procesar la solicitud de transacción del cliente, y utilice el protocolo de transmisión atómica de Zab para transmitir el estado de cambio de datos del servidor a todas las copias de los seguidores en forma de propuestas de transacción.
2. Cuando ocurre una excepción en el proceso principal, todo el clúster zk aún puede ejecutarse normalmente.
El protocolo Zab requiere que cada líder pase por tres etapas: descubrimiento, sincronización y transmisión.
Descubrimiento: el clúster Zookeeper necesita seleccionar un proceso líder y, al mismo tiempo, el El líder necesita mantener una lista de clientes esclavos para futuras comunicaciones con estos clientes esclavos.
Sincronización: el líder necesita sincronizar sus datos con los esclavos para lograr un almacenamiento de múltiples copias, lo que también refleja la alta disponibilidad y la tolerancia a fallas de partición en CAP. Después de que el esclavo consume los mensajes no procesados en la cola, los guarda en el registro local.
Difusión: el líder acepta solicitudes de transacciones de los clientes y transmite nuevas solicitudes de transacciones a los nodos seguidores.
Núcleo del protocolo Zab: define cómo manejar las solicitudes de transacciones.
1. Todas las solicitudes de transacciones deben ser coordinadas por un servidor único global (servidor líder), y los servidores restantes son servidores seguidores.
2. El servidor líder es responsable de convertir la solicitud de transacción del cliente en una propuesta de transacción y distribuir la propuesta de transacción a los servidores seguidores en el clúster, es decir, enviar solicitudes de transmisión de datos a todos los nodos seguidores.
3. Después de la distribución, el servidor líder debe esperar los comentarios del servidor seguidor. En el protocolo Zab, siempre que más de la mitad de los servidores seguidores confirmen, el líder enviará un mensaje de confirmación a todos los nodos seguidores nuevamente, solicitando el envío de la transacción anterior.
El protocolo Zab incluye dos modos: modo de recuperación de fallos y modo de transmisión de mensajes.
Proceso de protocolo
Cuando se inicia todo el clúster, el servidor líder se cae o el terminal de red se cae, el protocolo Zab entrará en modo de recuperación de fallas y elegirá un nuevo líder.
Cuando se elige al líder y más de la mitad de los servidores seguidores en el clúster lo confirman, el líder enviará otro mensaje de confirmación a todos los servidores seguidores solicitando el envío de la transacción anterior.
Cuando se elige un nuevo líder y más de la mitad de los servidores en el clúster han completado la sincronización de estado (sincronización de datos) con el servidor líder, el protocolo Zab saldrá del modo de recuperación de fallos y entrará en el modo de transmisión de mensajes.
Si se agrega un nuevo servidor al clúster y se ha elegido un líder, el servidor agregado ingresará automáticamente al modo de recuperación, buscará el servidor líder para la sincronización del estado, completará la sincronización y se comunicará con otros seguidores. Participen juntos en el proceso de transmisión.
La estrategia de entrega de replicación de datos en el clúster Zookeeper adopta el modo de transmisión de mensajes. El líder del protocolo zab espera los mensajes de respuesta ACK de los seguidores. Cuando más de la mitad de los comentarios de los seguidores son exitosos, no es necesario esperar a que todos los seguidores respondan.
Cuando el servidor líder cae o la red se paraliza y el líder no puede contactar con más de la mitad de los servidores seguidores, entrará automáticamente en modo de recuperación de fallos.
En el protocolo Zab, para garantizar el funcionamiento normal del programa, todo el proceso de recuperación necesita reelegir al líder después del servidor líder. Por lo tanto, el protocolo Zab requiere un algoritmo eficiente y confiable. para garantizar que el líder sea elegido rápidamente.
El algoritmo del líder requiere algo más que saber que se ha elegido un líder; El algoritmo de líder no solo le permite saber al líder que ha sido elegido líder, sino que también permite que todos los servidores del clúster reconozcan rápidamente que se ha elegido un nuevo líder.
La recuperación tras fallos incluye dos partes: elección de líder y recuperación de datos
Cómo garantiza el protocolo Zab la coherencia de los datos
Supongamos que hay dos situaciones anormales:
p>
1. Se ha confirmado una transacción en el líder y más de la mitad de los seguidores respondieron al Ack, pero el líder se cuelga antes de que se envíe el mensaje de confirmación.
2. Supongamos que se inicia una transacción en el líder y luego el líder se cuelga.
Para garantizar la coherencia de los datos cuando se produce cualquiera de las situaciones anteriores, el algoritmo de elección del protocolo Zab debe cumplir los siguientes requisitos:
La recuperación de fallos del protocolo Zab debe cumplir los dos requisitos siguientes:
1) Asegúrese de que la propuesta enviada por el líder eventualmente sea enviada por todos los servidores seguidores.
1) Asegúrese de que las sugerencias enviadas por el líder eventualmente sean enviadas por todos los servidores seguidores.
2) Asegurarse de que las sugerencias hechas por el líder pero no enviadas sean descartadas.
Basado en los requisitos anteriores
El protocolo Zab debe garantizar que el líder electo cumpla con las siguientes condiciones:
1) El líder recién elegido no puede contener personas no comprometidas propuestas.
En otras palabras, el líder recién elegido debe ser un nodo servidor seguidor que haya enviado una propuesta.
2) El nodo líder recién elegido tiene el zxid más grande.
Esto tiene la ventaja de evitar que el servidor líder verifique y descarte las propuestas enviadas.
Cómo sincroniza Zab los datos
1) Después de que se completa la elección del líder (el nuevo líder tiene el zxid más grande) y antes de comenzar a trabajar (recibir solicitudes de transacción y luego hacer nuevas propuestas), El servidor líder primero verifica que todas las recomendaciones en el registro de transacciones hayan sido enviadas por más de la mitad de los servidores del clúster.
2) El servidor líder debe garantizar que todos los servidores seguidores puedan recibir cada propuesta de transacción y aplicar todas las propuestas de transacción enviadas a los datos de la memoria. Después de que el seguidor haya sincronizado todas las propuestas de transacciones no sincronizadas del servidor líder y las haya aplicado a los datos en la memoria, el líder agregará al seguidor a la lista de seguidores verdaderamente disponibles.
Cómo manejar las propuestas que deben descartarse durante la sincronización de datos de Zab
En el diseño zxid del número de transacción de Zab, zxid es un número de 64 bits.
Los 32 bits inferiores pueden verse como un contador simple de un solo incremento. Cuando el líder genera una nueva transacción propuesta, cada solicitud de transacción del cliente incrementará el contador en 1, mientras que los 32 bits superiores lo harán. incrementa el contador en 1. Los 32 bits representan el número de época del ciclo líder.
El número de época puede entenderse como la edad o período del clúster actual. Cada vez que el líder cambia, agrega 1 a la época, de modo que cuando el antiguo líder falla y regresa, otros seguidores no lo obedecerán porque los seguidores solo obedecen al líder con la época más alta.
Cada vez que se elige un nuevo Líder, el zxid de la Propuesta con el número más alto en el registro de transacciones local se recuperará del servidor Líder, y el número de época correspondiente se analizará a partir del zxid, y luego agregado por 1 para tomarlo como el nuevo valor de época y restablecer los 32 bits inferiores a cero, regenerando el zxid desde cero.
El protocolo Zab utiliza números de época para distinguir los ciclos de reemplazo de líderes, lo que puede evitar eficazmente la situación anormal en la que diferentes líderes usan por error el mismo número zxid para hacer diferentes sugerencias.
Basado en la estrategia anterior
Cuando se inicia un servidor que contiene propuestas de transacciones que no se han enviado en el ciclo líder anterior, y la máquina se une al clúster y se conecta al líder en el papel de un seguidor Cuando el servidor se está ejecutando, el servidor líder compara la propuesta del servidor seguidor con la propuesta del servidor seguidor en función de la última propuesta enviada por el servidor líder. Como resultado de la comparación, el Líder le pide al Seguidor que realice una reversión a la última propuesta enviada por más de la mitad de las máquinas del clúster.
Este artículo está basado en /p/2bceacd60b8a.