Acuerdo de Zab (transferencia)

¿Qué es el acuerdo de Zab?

Zookeeper utiliza el protocolo Zab para garantizar la coherencia final de las transacciones distribuidas .

1. protocolo Zab es un servicio de coordinación para Zookeeper distribuido diseñado para soportar la recuperación de bloqueo de protocolo de difusión atómica , para garantizar la coherencia de datos es Zookeeper algoritmos básicos. Zab toma prestado del algoritmo de Paxos, pero a diferencia de Paxos, es un algoritmo general de consenso distribuido. Es un protocolo de transmisión atómica diseñado específicamente para Zookeeper para soportar la recuperación de fallas .

2. Zookeeper se basa principalmente en el protocolo Zab para lograr la consistencia de los datos. Basado en este protocolo, zk implementa una arquitectura de sistema de los modelos principales y en espera (es decir, los modelos Leader y Follower) para garantizar la consistencia de los datos entre las copias en el clúster.

El modelo de arquitectura del sistema principal y en espera aquí se refiere a que solo un cliente (Líder) es responsable de procesar las solicitudes de transacciones de escritura externas, y luego el cliente Líder sincroniza los datos con otros nodos de Seguidor.

El cliente de Zookeeper se vinculará aleatoriamente a un nodo en el clúster de zookeeper. Si se trata de una solicitud de lectura, leerá directamente los datos del nodo actual; si se trata de una solicitud de escritura, el nodo enviará una transacción al Líder, y el Líder recibirá el envío de la transacción. La transacción se transmitirá, siempre que más de la mitad de los nodos escriban correctamente, la transacción se confirmará

Caracteristicas

1. El protocolo Zab necesita asegurar que las transacciones que se han confirmado en el servidor líder (Commit) eventualmente sean enviadas por todos los servidores

2. El protocolo Zab debe garantizar que las transacciones que solo se generan en el líder y no se envíen se descarten .

Efecto

1. El uso de un único proceso maestro (Líder) para recibir y solicitud de transacción del cliente proceso (es decir, la solicitud por escrito), y utiliza el protocolo de emisión atómica Zab, el estado de los cambios en los datos del servidor a la propuesta de transacción (propuestas de transacción) en forma de Difusión a todos los procesos de copia (seguidor)

2. Asegúrese de que una secuencia de cambio global se referencia secuencialmente

Zookeeper es una estructura de árbol, y muchas operaciones deben verificarse antes de que pueda determinarse. Por ejemplo, la transacción P1 t1 puede ser para crear el nodo "/ a", t2 puede ser para crear el nodo "/ a / bb", solo el padre se crea primero El nodo "/ a" puede crear el nodo hijo "/ a / b".

Para garantizar esto, Zab debe asegurarse de que las transacciones iniciadas por el mismo líder se apliquen en orden, y al mismo tiempo asegurarse de que solo después de que se aplique la transacción del líder anterior, el líder recién elegido pueda iniciar la transacción nuevamente.

3. Cuando el proceso principal es anormal, todo el clúster zk puede funcionar normalmente

Etapa

Encontrado

Se requiere que el grupo del cuidador del zoológico elija un proceso de líder, y el líder mantendrá una lista de clientes disponibles para el seguidor. Los clientes pueden comunicarse con estos nodos seguidores en el futuro

Sincronización

Leader es responsable de sincronizar sus propios datos con Follower para lograr el almacenamiento de copias múltiples. Esto también proporciona alta disponibilidad y tolerancia a fallas en CAP. El seguidor escribe las solicitudes no procesadas en la cola en el registro de transacciones local después del consumo

Broadcast

El líder puede aceptar la nueva solicitud de propuesta de transacción del cliente y transmitir la nueva solicitud de propuesta a todos los seguidores

Núcleo

Define cómo manejar las solicitudes de transacción

1. Todas las solicitudes de transacciones deben ser coordinadas y procesadas por un servidor único a nivel mundial, que se llama servidor líder . El resto de los servidores son servidores seguidores

2. servidor Leader es responsable de un solicitudes de transacciones del cliente, convertida en una Propuesta transacción , la propuesta y se distribuye a todos los servidores de clúster seguidor, que se emite para enviar solicitudes de datos a todos los nodos del seguidor (o la replicación de datos)

3. Después de la distribución, el servidor Leader debe esperar los comentarios de todos los servidores Follower (solicitudes Ack). En el protocolo Zab, siempre y cuando más de la mitad de los servidores Follower hayan recibido comentarios correctos (es decir, se hayan recibido más de la mitad de las solicitudes Ack Follower), El Líder enviará un mensaje de Compromiso a todos los servidores de Follower nuevamente, solicitándole que confirme la última propuesta de transacción

Contenido del acuerdo de Zab

El protocolo Zab incluye dos modos básicos: recuperación de fallas y transmisión de mensajes.

Mantenga los mensajes en orden.

En toda la transmisión del mensaje, el Líder convertirá cada solicitud de transacción en la propuesta correspondiente para transmitir, y antes de transmitir la Propuesta de transacción, el servidor del Líder primero asignará un ID único para la Propuesta de transacción al incremento único global, llamado transacción ID (es decir, zxid), porque el protocolo Zab debe garantizar la relación estricta de orden de cada mensaje, por lo que cada propuesta debe clasificarse y procesarse de acuerdo con su orden zxid

Transmisión de mensajes

1. En el clúster zookeeper, la estrategia de transmisión de la copia de datos es utilizar el modo de transmisión de mensajes. El método de sincronización de la copia de datos esclava en zookeeper es similar al compromiso de dos fases, pero es diferente. La presentación del segundo párrafo requiere que el coordinador espere hasta que todos los participantes reciban comentarios sobre el mensaje de confirmación ACK antes de enviar el mensaje de confirmación. Todos los participantes deben tener éxito o fracasar. La confirmación en dos etapas causará serios problemas de bloqueo

2. En el protocolo Zab, el Líder espera que el mensaje de respuesta ACK del seguidor signifique "siempre y cuando más de la mitad de los comentarios exitosos del seguidor no necesiten recibir todos los comentarios del seguidor"

Pasos

1. El cliente inicia una solicitud de operación de escritura

2. El servidor Leader convierte la solicitud del cliente en una propuesta de propuesta de transacción y asigna una ID global a cada propuesta, a saber, zxid

3. El servidor Líder asigna una cola separada para cada servidor Seguidor, y luego coloca la Propuesta para ser transmitida en la cola a su vez, y envía mensajes de acuerdo con la política FIFO.

4. Después de que el seguidor reciba la propuesta, primero la escribirá en el disco local en forma de registro de transacciones. Después de una escritura exitosa, enviará un mensaje de respuesta de reconocimiento al líder

5. Después de que el Líder recibe más de la mitad del mensaje de respuesta de Ack del seguidor, considera que el mensaje se ha enviado correctamente y puede enviar un mensaje de confirmación

6. El Líder difunde el mensaje de confirmación a todos los Seguidores y, al mismo tiempo, completará la confirmación de la transacción. Después de que el seguidor recibe el mensaje de confirmación, confirmará la última transacción

Siempre que un servidor envíe la Propuesta, es necesario asegurarse de que todos los servidores finalmente puedan enviar la Propuesta correctamente. Esto también es una manifestación de CAP / BASE logrando la máxima consistencia
Se mantiene una cola de mensajes FIFO separada entre el servidor Líder y cada servidor Seguidor para enviar y recibir mensajes. El uso de mensajes en cola puede lograr un desacoplamiento asíncrono. Líder y seguidor solo necesitan enviar mensajes a la cola

Recuperación de choque

La recuperación del choque incluye principalmente dos partes: elección del líder y recuperación de datos

Cómo el protocolo Zab garantiza la consistencia de los datos

Dos situaciones anormales

1. Se envió una transacción al líder, y más de la mitad del seguidor respondió a Ack, pero el líder colgó antes de que se emitiera el mensaje de confirmación

2. Suponga que una transacción se cuelga después de que el líder lo propone

Los requisitos de recuperación ante fallos del protocolo Zab cumplen los dos requisitos siguientes:

1. Asegúrese de que la propuesta que ha enviado el Líder debe ser presentada finalmente por todos los servidores de Follower

2. Asegúrese de descartar la Propuesta propuesta por el Líder pero no presentada

requisitos del líder

1. El líder recién elegido no puede contener una propuesta no comprometida

2. El nodo Líder recién elegido contiene el zxid más grande

Cómo sincronizar datos en Zab

1. Después de completar la elección del Líder (el nuevo Líder tiene el zxid más alto), y antes de comenzar oficialmente el trabajo (recibir la solicitud de transacción y luego proponer una nueva Propuesta), el servidor del Líder primero confirmará si todas las Propuestas en el registro de transacciones se han agrupado Más de la mitad del servidor Commit

2. El servidor Leader debe asegurarse de que todos los servidores Follower puedan recibir la Propuesta de cada transacción y puedan aplicar la Propuesta de todas las transacciones confirmadas a los datos de la memoria. Después de que el seguidor sincroniza todas las transacciones pendientes Propuesta del servidor del líder y lo aplica a los datos de la memoria, el líder agregará el seguidor a la lista de seguidores realmente disponibles

Cómo lidiar con una propuesta que debe 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 se pueden considerar como un simple contador de un solo incremento . Para cada solicitud de transacción del cliente, el Líder aumentará el contador en 1 cuando genere una nueva transacción de Propuesta. Los 32 bits superiores representan el número de época del ciclo líder .

El protocolo Zab usa el número de época para distinguir el período de cambio de Líder, que puede evitar efectivamente que diferentes Líderes usen incorrectamente el mismo número zxid, y propone diferentes excepciones de Propuesta.

Cuando se inicia un servidor que contiene una Propuesta que no se ha confirmado en el período Líder anterior, cuando esta máquina se une al clúster y se conecta al servidor Líder en el rol de Seguidor, el servidor Líder utilizará la Propuesta que se envió por última vez en su propio servidor para unirse La propuesta del servidor Follower se compara, y el resultado de la comparación debe ser que el Líder requiere que el Follower realice una operación de respaldo, y recurra a la última Propuesta que efectivamente ha sido comprometida por más de la mitad de las máquinas en el clúster.

Principio de implementación de Zab

El nodo de Zab tiene tres estados

Siguiente: el nodo actual es un seguidor y obedece los comandos del nodo líder
Líder: El nodo actual es el Líder, responsable de coordinar las transacciones.
Elección / Mirada: el nodo está en estado de elección y está buscando al líder

la implementación del código, más de un estado: el respeto de estado
que se añade después de la introducción Zookeeper Observador Observador no participa en las elecciones, el nodo está, nada que ver con el acuerdo de Zab de sólo lectura

El estado persistente del nodo.

historial: registro de la transacción Propuesta recibida por el nodo actual
aceptadoEpoca: el seguidor ha aceptado la nueva propuesta de Líder de Época para cambiar la época
currentEpoch: la era actual del Líder
lastZxid: el zxid (zxid máximo) de la propuesta recibida más recientemente en la historia

Las cuatro etapas de Zab.

Etapa electoral

Zookeeper estipula que todos los votos válidos deben estar en la misma ronda. Cuando cada servidor comienza una nueva ronda de votación, incrementará el reloj lógico que mantiene.

Fase de descubrimiento

El objetivo principal de esta etapa es descubrir la última Propuesta recibida por la mayoría de los nodos actuales, y el cuasi-Líder genera una nueva época para que los seguidores reciban y actualicen su Época aceptada.

Fase de sincronización

La fase de sincronización utiliza principalmente el último historial de propuestas obtenido en la fase anterior de Leader para sincronizar todas las réplicas en el clúster

Etapa de transmisión

En esta etapa, el clúster de Zookeeper puede proporcionar servicios de transacción externamente y Leader puede transmitir mensajes. Al mismo tiempo, si se agrega un nuevo nodo, el nuevo nodo debe sincronizarse.
Cabe señalar que las transacciones de envío de Zab no requieren que todos los seguidores sean Ack como 2PC, solo necesitan obtener Ack de quórum (más de la mitad de los nodos).