Zookeeper: explicación detallada del algoritmo zab

El protocolo zab es un protocolo de consenso distribuido diseñado para Zookeeper .

1. ¿Qué es el acuerdo ZAB? Introducción al acuerdo ZAB

1. El nombre completo del protocolo ZAB: Zookeeper Atomic Broadcast ( Zookeeper Atomic Broadcast ).

2. Zookeeper es un servicio de coordinación distribuida eficiente y confiable para aplicaciones distribuidas. En términos de resolver la consistencia distribuida, Zookeeper no usó Paxos, pero adoptó el protocolo ZAB.

3. Definición del protocolo ZAB: El protocolo ZAB es un protocolo de soporte especialmente diseñado para el servicio de coordinación distribuida Zookeeper 原子广播 和 崩溃恢复  . A continuación, nos centraremos en estas dos cosas.

4. Basado en este protocolo, Zookeeper implementa una  主备模式 arquitectura de sistema para mantener las réplicas en el clúster 数据一致性. Los detalles se muestran en la siguiente figura:

La figura anterior muestra cómo Zookeeper procesa los datos en el clúster:

Todos los datos de escritura del cliente se escriben en el proceso principal (llamado Líder) y luego el Líder los copia al proceso de respaldo (llamado Seguidor). Para garantizar la coherencia de los datos . Desde el punto de vista del diseño, es similar a Raft.

5. Entonces, ¿qué pasa con el proceso de copia? El proceso de replicación es similar a 2PC , ZAB solo necesita más de la mitad de los Seguidores para devolver la información de Ack para realizar el envío, lo que reduce en gran medida el bloqueo de sincronización. También mejora la usabilidad .

Después de la breve introducción, comience a concentrarse en  消息广播 y  崩溃恢复. Todo el Zookeeper cambia entre estos dos modos .  En resumen, cuando el servicio Leader se puede usar normalmente, ingresa al modo de transmisión de mensajes, y cuando el Leader no está disponible, ingresa al modo de recuperación por accidente .

2. Transmisión de noticias

El proceso de transmisión de mensajes del protocolo ZAB utiliza un protocolo de transmisión atómico , similar a un  proceso de confirmación de dos fases .

Todas las solicitudes de escritura enviadas por el cliente son recibidas por el Líder. El Líder encapsula la solicitud en una propuesta de transacción y la envía a todos los Follwers. Luego, de acuerdo con los comentarios de todos los Follwers, si más de la mitad de los Follwers responden con éxito, la operación de confirmación se ejecuta (envíe primero) usted mismo, envíe una confirmación a todos los seguidores).

Básicamente, todo el proceso de transmisión se divide en 3 pasos:

1. Copie todos los datos en Follwer

2. Espere a que Follwer responda a Ack, y el número mínimo es más de la mitad para tener éxito

3. Cuando más de la mitad de la respuesta sea correcta, ejecute la confirmación y envíese usted mismo al mismo tiempo.

Mediante los 3 pasos anteriores, se puede mantener la coherencia de los datos entre los clústeres. De hecho, existe una cola de mensajes entre Leader y Follwer para desacoplar el acoplamiento entre ellos, evitar la sincronización y lograr un desacoplamiento asincrónico.

Hay algunos detalles:

1. Una vez que el líder recibe la solicitud del cliente, encapsula la solicitud en una transacción y asigna un ID único que aumenta globalmente a la transacción, llamado ID de transacción (ZXID). El protocolo ZAB necesita garantizar el orden de la transacción, por lo que debe be Cada transacción se clasifica y procesa de acuerdo con ZXID.

2. También hay una cola de mensajes entre Leader y Follwer para desacoplar el acoplamiento entre ellos y desbloquear la sincronización.

3. En el clúster de zookeeper, para garantizar que todos los procesos se puedan ejecutar en un orden ordenado, solo el servidor Leader puede aceptar solicitudes de escritura. Incluso si el servidor Follower recibe la solicitud del cliente, se reenviará al servidor Leader para su procesamiento.

4. De hecho, esta es una versión simplificada de 2PC, que no puede resolver problemas de un solo punto. Más adelante hablaremos sobre cómo ZAB resuelve el problema de un solo punto (es decir, el problema de caída de Leader).

3. Recuperación en caso de accidente

Simplemente dijimos, ¿qué debo hacer si el líder falla durante el proceso de transmisión de mensajes? ¿Se puede garantizar la coherencia de los datos? ¿Qué debo hacer si el líder envía primero localmente y luego no se envía la solicitud de confirmación?

De hecho, cuando el Líder falla, entra en el modo de recuperación por falla que mencionamos al principio (falla significa: Líder pierde contacto con más de la mitad de Follwer). Hablemos en detalle a continuación.

Supuesto 1: El líder se bloquea después de copiar datos a todos los seguidores, ¿qué debo hacer?
Hipótesis 2: ¿Qué pasa si el líder falla después de recibir un Ack y someterse a sí mismo, y enviar algunas confirmaciones al mismo tiempo?

En respuesta a estos problemas, ZAB ha definido 2 principios:

1. El protocolo ZAB asegura que las transacciones que se han comprometido en Leader eventualmente serán confirmadas por todos los servidores.
2. El protocolo ZAB asegura que las transacciones que solo son propuestas / replicadas por el Líder pero no comprometidas se descartan.

Por lo tanto, ZAB ha diseñado el siguiente algoritmo de elección:
puede garantizar que se envíen las transacciones enviadas por el líder, descartando las transacciones que se han omitido.

En respuesta a este requisito, si el algoritmo de elección de Leader puede garantizar que el servidor Leader recién elegido tenga la transacción de todos los números de máquina en el clúster (es decir, el ZXID es el más grande), entonces se puede garantizar que el servidor Leader recién elegido El líder debe tener todas las propuestas enviadas.
Y esto tiene una ventaja: puede guardar el servidor Leader para verificar el compromiso de la transacción y descartar el trabajo de este paso.

De esta manera, los dos problemas que acabamos de asumir se pueden resolver. El Supuesto 1 eventualmente descartará los datos no enviados por la llamada, y el Supuesto 2 finalmente sincronizará los datos de todos los servidores. En este momento surge una pregunta, ¿cómo sincronizar?

4. Sincronización de datos

Después de que se recupera el bloqueo, antes del trabajo formal (recibir la solicitud del cliente), el servidor Leader primero confirma si la transacción ha sido enviada por más de la mitad del Follwer, es decir, si la sincronización de datos se completó. El propósito es mantener la coherencia de los datos.

Cuando todos los servidores de Follwer se hayan sincronizado correctamente, Leader agregará estos servidores a la lista de servidores disponibles.

De hecho, el servidor Leader se basa en ZXID para procesar o descartar transacciones, entonces, ¿cómo se genera este ZXID?

Respuesta: En el diseño ZXID del número de transacción del protocolo ZAB, ZXID es un número de 64 bits, de los cuales los 32 bits inferiores pueden verse como un simple contador incremental. Para cada solicitud de transacción del cliente, el Líder generará una nueva transacción Propuesta y +1 operación en el mostrador.

Los 32 bits superiores representan el ZXID de la propuesta de transacción más grande en el registro local tomado del servidor Leader, y el valor de época correspondiente se analiza a partir del ZXID, y luego este valor se suma en uno.

Los 32 bits altos representan la singularidad de cada generación de Leader, y los 32 bits bajos representan la singularidad de las transacciones en cada generación de Leader. Al mismo tiempo, también puede permitir que Follwer identifique diferentes líderes a través de los 32 bits superiores. Simplificado el proceso de recuperación de datos.

Basado en esta estrategia: cuando Follower se vincula a Leader, el servidor de Leader comparará el ZXID enviado por última vez en su propio servidor con el ZXID en Follower, y el resultado de la comparación se revertirá o sincronizará con Leader.

5. Resumen

Es hora de resumir.

El protocolo ZAB y el protocolo Raft que vimos antes son en realidad similares. Por ejemplo, hay un líder para garantizar la coherencia (Paxos no utiliza el mecanismo Leader para garantizar la coherencia). Luego, existe un mecanismo para garantizar que el servicio esté disponible (de hecho, Paxos y Raft lo hacen).

ZAB permite que todo el clúster de Zookeeper cambie entre los dos modos, transmisión de mensajes y recuperación de fallas. Se puede decir que la transmisión de mensajes es una versión simplificada de 2PC. Resuelve el problema de un solo punto de 2PC a través de la recuperación de fallas y resuelve el problema de bloqueo de sincronización de 2PC a través de colas.

La precisión de los datos después de la recuperación de fallos está respaldada por la sincronización de datos, que está garantizada en función de la singularidad del ZXID de la transacción. Mediante la operación + 1 se puede distinguir el orden de las transacciones.

 

referencia:

Código fuente de Zookeeper;

Teoría Distribuida (7) -ZAB del Protocolo de Consenso

"De Paxos a Zookeeper: principio y práctica de coherencia distribuida"