El entrevistador preguntó: ¿Cuénteme acerca de su comprensión del grupo ZooKeeper y la elección de líder?

ZooKeeper es un servicio de coordinación distribuido de código abierto y una solución de coherencia de datos distribuidos. Basado en ZooKeeper, se pueden realizar funciones como servicio de nombres, administración de clústeres, elección maestra y bloqueo distribuido.

Alta disponibilidad

Para garantizar la disponibilidad de ZooKeeper, en el entorno de producción utilizamos el modo de clúster de ZooKeeper para proporcionar servicios externos, y el tamaño del clúster se compone de al menos 3 nodos de ZooKeeper.

El clúster consta de al menos 3 nodos

De hecho, los nodos de ZooKeeper 2 también pueden formar un clúster y proporcionar servicios externos, pero nuestro principal objetivo al utilizar clústeres es lograr una alta disponibilidad. Si dos nodos forman un clúster, uno de los nodos está inactivo y el nodo de ZooKeeper no puede proporcionar servicios externos normalmente. Por tanto, se pierde el significado de agrupaciones.

Si tres nodos forman un clúster y uno de los nodos cuelga, de acuerdo con el mecanismo de elección de líder de ZooKeeper, uno de los otros dos nodos puede seleccionarse como líder y el clúster puede continuar brindando servicios al mundo exterior.

No es que cuantos más nodos mejor

• Cuantos más nodos, más recursos se utilizan
• Cuantos más nodos, mayor será el costo de comunicación entre los nodos de ZooKeeper y más Sockets interconectados entre los nodos. Afecta el procesamiento de transacciones del clúster de ZooKeeper
• Cuantos más nodos, mayor posibilidad de división cerebral

El tamaño del grupo es extraño

Además de considerar sus propios costos y recursos, el tamaño del clúster también debe considerarse junto con las características de ZooKeeper:

• ahorrar recursos
• Para un clúster de 3 nodos y un clúster de 4 nodos, elegimos usar un clúster de 3 nodos; para un clúster de 5 nodos y un clúster de 6 nodos, elegimos usar un clúster de 5 nodos. Y así. Para garantizar una alta disponibilidad en el entorno de producción, un clúster de 3 nodos puede colgarse como máximo 1, y un clúster de 4 nodos puede colgarse como máximo 1 (la razón se explica en el principio de más de la mitad). De manera similar, un clúster de 5 nodos permite hasta 2 unidades, y un clúster de 6 nodos permite hasta 2 unidades.
• Por el bien de ahorrar recursos, deberíamos usar nodos impares para alcanzar la misma alta disponibilidad.
• Disponibilidad del clúster
• El impacto de los números pares e impares en el clúster cuando hay un problema con la comunicación de red entre los nodos del clúster.

 

Configuración de clúster

La configuración del clúster de ZooKeeper requiere al menos dos cambios:

1. Aumente la configuración del clúster

Agregue la configuración del clúster en {ZK_HOME} /conf/zoo.cfg, la estructura se basa en server.id = ip: port1: port2.

Por ejemplo, el siguiente archivo de configuración representa un clúster compuesto por 3 ZooKeepers:

servidor.1 = localhost: 2881: 3881
servidor.2 = localhost: 2882: 3882server.3 = localhost: 2883: 3883

 

2. Configurar la identificación del nodo

Al configurar el clúster en zoo.cfg, debe especificar server.id. Este id necesita crear un archivo myid en el directorio especificado por dataDir (configurado en zoo.cfg). El contenido del archivo es el id del nodo actual de ZooKeeper.

Rol de clúster

ZooKeeper no utiliza el concepto de maestro / esclavo, pero divide los nodos del clúster en tres tipos de roles:

• Líder
• En un clúster de ZooKeeper, solo puede haber un líder. Este líder es el único programador y procesador de solicitudes de transacción en el clúster. La llamada solicitud de transacción se refiere a una solicitud que cambia el estado del clúster; el líder puede garantizar el orden del procesamiento de la transacción según el ID de la transacción .
• Si hay varios líderes en un grupo, este fenómeno se denomina "cerebro dividido". ¿Imagina el impacto de varios líderes en un clúster?
• Es equivalente al clúster grande original, y se dividen varios clústeres pequeños y los datos entre ellos no se sincronizarán entre sí. Los datos del clúster se volverán muy confusos después de la "división del cerebro".
• Seguidor
• El servicio ZooKeeper del rol de seguidor solo puede procesar solicitudes no transaccionales; si recibe una solicitud de transacción del cliente, reenviará la solicitud al servidor líder; participará en la elección del líder; participará en la votación del procesamiento de transacciones del líder.
• Cuando el Seguidor descubre que el Líder en el grupo no está disponible, cambiará su estado e iniciará una votación de elección de Líder. Al final, un seguidor en el grupo será seleccionado como Líder.
• Observador
• Observer es muy similar a Follower y puede manejar solicitudes no transaccionales; reenviando solicitudes transaccionales al servidor Leader.
• A diferencia de Follower, Observer no participará en la elección de Líder; no participará en la votación de transacciones de Líder.
• Observer se utiliza para mejorar las capacidades de procesamiento de transacciones del clúster sin afectar las capacidades de procesamiento de transacciones del clúster.

Elección de líder

El líder es un papel muy importante en el clúster, responsable del procesamiento y la programación de toda la transacción, y la clave para garantizar la coherencia de los datos distribuidos. Dado que el líder es tan importante en el clúster de ZooKeeper, es necesario asegurarse de que el clúster tenga y solo exista un líder en todo momento.

Si el líder del clúster no está disponible, se necesita un mecanismo para garantizar que se pueda encontrar un servicio óptimo en el clúster y ascender a líder para continuar procesando transacciones y programando responsabilidades. Este proceso se llama elección de líder.

Mecanismo electoral

El líder electoral de ZooKeeper se basa en los siguientes principios y sigue el orden de prioridad:

1. La votación electoral debe realizarse en la misma ronda.

Si el servicio de seguidores tiene diferentes rondas electorales, no se adoptará la votación.

2. El nodo con los datos más recientes será el líder primero.

Los datos nuevos y antiguos están determinados por el ID de la transacción. Cuanto mayor sea el ID de la transacción, se considera que los datos del nodo están cerca de los datos del líder y, naturalmente, deberían convertirse en el líder.

3. Compare server.id, el que tenga un valor de identificación más alto será el líder primero

Si el ID de transacción de cada nodo participante es el mismo, utilice server.id para comparar. server.id es la identificación única del nodo en el clúster, que se configura en el archivo myid.

No importa si el líder es elegido cuando se inicia el grupo o si el líder es reelegido mientras el grupo está en funcionamiento. Cada servicio de rol de seguidor en el clúster selecciona un líder adecuado en función de las condiciones anteriores. Una vez que un nodo es seleccionado por más de la mitad, el nodo es promovido a líder.

Más de la mitad del principio

Hay muchos tipos de votos en el grupo ZooKeeper. Votación de elección de líder; votación de propuesta comercial; estos votos se basan en el principio de mayoría. En otras palabras, ZooKeeper cree que el resultado de la votación supera la mitad del número total de clústeres y las transacciones posteriores se pueden procesar de forma segura.

• Votación de propuesta comercial
• Suponga que hay 3 nodos que forman un clúster de ZooKeeper y el cliente solicita agregar un nodo. Después de recibir la solicitud de transacción, el Líder inicia una propuesta de "creación de nodo" para que todos los seguidores voten. Si el líder recibe más de la mitad de la retroalimentación del clúster, continúa iniciando un compromiso con todos los seguidores. En este momento, Leader piensa que el clúster es más de la mitad, incluso si el clúster está colgado, es seguro y confiable.
• Votación de elección de líder
• Suponga que hay 3 nodos para formar un grupo de ZooKeeper. En este momento, el líder cuelga y usted necesita votar para elegir al líder. El líder es elegido cuando el mismo resultado de votación es más de la mitad.
• Clúster de nodos disponibles
• Cada nodo en el clúster de ZooKeeper tiene su propia función y el principio de más de la mitad debe cumplirse para la disponibilidad del clúster. Esto más de la mitad significa que el número de roles de líder + roles de seguidor disponibles es mayor que el número total de roles de líder + roles de seguidor en el clúster.
• Suponga que hay 5 nodos para formar un clúster de ZooKeeper, un líder, dos seguidores y dos observadores. El grupo no estará disponible cuando dos seguidores o un líder y un seguidor estén suspendidos. Porque el rol de Observador no participa en ninguna forma de votación.

El llamado algoritmo del principio de más de la mitad es que el número de votos> el número total de nodos en el clúster / 2. El resultado del cálculo del número total de nodos de clúster / 2 se redondeará hacia abajo.

Este algoritmo está implementado en el código fuente de ZooKeeper QuorumMaj.java. El siguiente fragmento de código se ha reducido.

public boolean containsQuorum (HashSet <Long> set) {
 / ** n se refiere al número total de clusters * / int half = n / 2; return (set.size ()> half);)

Mirando hacia atrás, echemos un vistazo a los resultados de la elección del líder para grupos pares e impares.

 

Por lo tanto, un clúster compuesto por 3 nodos y 4 nodos solo puede tener 1 nodo como máximo según el principio de ZooKeeper más de la mitad, pero 4 o 3 desperdician un recurso de nodo más.

Escena de combate

Usamos dos escenarios para comprender el proceso de reelección de líderes cuando el clúster no está disponible.

Líder de reelección del cluster de 3 nodos

Suponga un clúster compuesto por 3 nodos, a saber, servidor 1 (seguidor), servidor 2 (líder) y servidor 3 (seguidor). En este momento server.2 no está disponible. El clúster tendrá los siguientes cambios:

1. El clúster no está disponible

Debido a que el líder está caído, el clúster no está disponible para solicitudes de transacciones.

2. Cambio de estado

Todos los nodos seguidores cambian su estado a MIRANDO y cambian su propia votación. El contenido de la votación es el ID de transacción y el ID de servidor del propio nodo. Lo expresamos con (ID de transacción, server.id).

Suponiendo que el ID de transacción del servidor.1 es 10, el propio voto del cambio es (10, 1); el ID de la transacción del servidor.3 es 8 y el propio voto del cambio es (8, 3).

3. La primera ronda de votaciones

Envíe el voto del cambio a todos los nodos seguidores del clúster. server.1 envía (10, 1) a todos los seguidores del clúster, incluido él mismo. Server.3 es el mismo, enviando (8, 3) a todos los seguidores.

De modo que el servidor.1 recibirá dos votos (10, 1) y (8, 3), y el servidor.3 recibirá dos votos (8, 3) y (10, 1).

4. PK de votación

Además de iniciar una votación, cada nodo seguidor también recibe los votos enviados por otros seguidores y compara las dos ID de transacción propuestas y server.id con su propio PK de votación. El resultado de PK determina si cambiar su estado y volver a votar.

Para el servidor.1, se reciben dos votos (10, 1) y (8, 3). En comparación con el voto cambiado por sí mismo, ninguno de ellos es mayor que el voto (10, 1) propio, por lo que el servidor.1 se mantiene. La votación permanece sin cambios.

Para servidor.3, recibe dos votos (10, 1) y (8, 3). Después de comparar con el voto de su propio cambio, se considera que el voto enviado por servidor.1 es mayor que su propio voto, por lo que servidor.3 Cambie su propio voto y envíe el voto modificado a todos los seguidores del grupo.

5. La segunda ronda de votaciones

server.3 cambia su voto a (10, 1) y luego envía el voto a todos los seguidores en el clúster nuevamente.

Para el servidor 1, el voto (10, 1) se recibió en la segunda ronda y el servidor 1 sigue sin cambios después de PK.

Para el servidor.3, el voto (10, 1) se recibió en la segunda ronda, porque el servidor.3 en sí mismo ha cambiado a (10, 3) voto, por lo que esta vez permanece sin cambios.

En este momento servidor.1 y servidor.3 llegaron a un acuerdo sobre la votación.

6. Grupo de recepción de votos

Los votos recibidos por el nodo se almacenan en un depósito de recepción, y el resultado de la votación de cada seguidor solo se registra una vez en el depósito. Map implementa el depósito de recepción en el código fuente de ZooKeeper.

El siguiente fragmento de código es el depósito de recepción definido por ZooKeeper y la escritura de datos en el depósito. Map.Key es un tipo Long, usado para almacenar el server.id del nodo fuente de votación, y Vote es la información de votación del nodo correspondiente. Una vez que el nodo recibe el voto, actualizará el depósito de recepción, lo que significa que el depósito almacena los votos de todos los nodos seguidores y solo se almacena el último resultado de la votación.

HashMap <Long, Vote> recvset = new HashMap <Long, Vote> ();
recvset.put (n.sid, nuevo voto (n.leader, n.zxid, n.electionEpoch, n.peerEpoch));

7. Votación estadística

Después de recibir el voto, intentará contar el voto cada vez, y la elección será exitosa después de la mitad del recuento de votos.

Los datos de las estadísticas de votación provienen de los datos de votación en el grupo de recepción de votos. Describamos este escenario desde el principio y veamos los cambios de datos en el grupo de recepción.

Después de que server.2 cuelga, server.1 y server.3 inician la primera ronda de votación.

servidor.1 recibe el voto (10, 1) del servidor.1 y el voto (8, 3) del servidor.3.

server.3 también recibe (10, 1) votos del server.1 y (8, 3) votos del server.3. En este momento, los datos en el depósito receptor de server.1 y server.3 tienen este aspecto:

 

Después de que server.3 aprobó el PK, creyó que el voto del server.1 era mayor que el suyo, por lo que cambió su voto y reinició la votación.

servidor.1 recibió el voto (10, 1) del servidor.3; servidor.3 recibió el voto (10, 1) del servidor.3. En este momento, los datos en el depósito receptor de server.1 y server.3 se vuelven así:

 

Basado en el principio de ZooKeeper de más de la mitad: votar en el cubo para elegir al servidor.1 para aparecer como líder dos veces, y más de la mitad 2> 3/2, es decir, 2> 1.

Finalmente, el nodo sever.1 se promovió a Leader y server.3 se cambió a Follower.

Cuándo comenzar el líder de expansión del clúster

La expansión del clúster de ZooKeeper requiere agregar nuevos nodos al archivo de configuración zoo.cfg. El proceso de expansión se introduce en la expansión de ZooKeeper. Aquí discutimos el momento del inicio del líder cuando la capacidad de 3 nodos se expande a 5 nodos.

Suponga que actualmente hay tres nodos que forman un clúster, a saber, servidor.1 (seguidor), servidor.2 (líder) y servidor.3 (seguidor). Suponga que los ID de transacción de nodo en el clúster son los mismos. El archivo de configuración es el siguiente.

servidor.1 = localhost: 2881: 3881
servidor.2 = localhost: 2882: 3882server.3 = localhost: 2883: 3883

1. El nuevo nodo se une al clúster

Se agregan dos nuevos nodos, server.4 y server.5, al clúster Primero, modifique la configuración zoo.cfg de server.4 y server.5 e inícielos. Los nodos 4 y 5 cambiarán su estado de votación después del inicio e iniciarán una ronda de votación de elección de líder. Después de que server.1, server.2 y server.3 reciban el voto, dado que el líder ha sido seleccionado en el clúster, retroalimentarán directamente los resultados de la votación de server.4 y server.5: server.2 es el líder. Después de recibir los votos, servidor.4 y servidor.5 determinan que servidor.2 es el líder según el principio de más de la mitad, y cambian a seguidor.

#Node server.1, server.2, server.3 configuración
servidor.1 = localhost: 2881: 3881server.2 = localhost: 2882: 3882server.3 = localhost: 2883: 3883 # 节点 server.4 、 server.5 配置 server.1 = localhost: 2881: 3881server.2 = localhost: 2882 : 3882server.3 = localhost: 2883: 3883server.4 = localhost: 2884: 3884server.5 = localhost: 2885: 3885

2. Detener líder

La adición de server.4 y server.5 necesita modificar la configuración zoo.cfg del clúster server.1, server.2 y server.3 y reiniciar. Sin embargo, cuando se reinicia el nodo líder, es importante tener en cuenta, porque el reinicio del líder hará que el seguidor en el clúster inicie una reelección de líder. Después de que los dos nuevos nodos de server.4 y server.5 se agregan normalmente, el clúster no cambiará el líder porque se agregó el nuevo nodo, por lo que actualmente server.2 sigue siendo el líder.

Comenzamos en un orden incorrecto para ver qué pasa con el grupo. Modifique el archivo de configuración server.2zoo.cfg, aumente la configuración de server.4 y server.5 y detenga el servicio server.2. Una vez que se detiene server.2, el líder ya no existe y todos los seguidores del clúster iniciarán la votación. Cuando server.1 y server.3 inician una votación, la votación no se envía a server.4 y server.5, porque los nodos server.4 y server.5 no están incluidos en la configuración del clúster de server.1 y server.3. Por el contrario, server.4 y server.5 enviarán votos a todos los nodos del clúster. En otras palabras, para server.1 y server.3, creen que solo hay 3 nodos en el clúster. Para server.4 y server.5, creen que hay 5 nodos en el clúster.

De acuerdo con el principio de más de la mitad, server.1 y server.3 pronto seleccionarán un nuevo líder. Aquí asumimos que server.3 es promovido para convertirse en el nuevo líder. Pero cuando no iniciamos server.2, debido a que la votación no cumple con el principio de más de la mitad, server.4 y server.5 siempre votarán por Leader. Hasta ahora, el estado de los nodos del clúster es el siguiente:

 

3. Líder de inicio

Ahora, iniciamos server.2. Debido a que server.2zoo.cfg ya es una configuración completa de server.1 a serverv.5, la votación electoral se iniciará después de que se inicie server.2, y serverv.4 y serverv.5 también están iniciando constantemente la votación electoral. Cuando la ronda de elección de server.2 se alinea con las rondas de elección de serverv.4 y serverv.5, finalmente server.2 cambiará su estado y determinará que server.5 es Leadader.

Sucedieron cosas inesperadas y aparecieron dos líderes:

 

Cuando se expande el clúster de ZooKeeper, este problema se puede evitar si el nodo líder se inicia en último lugar, porque antes de que se reinicie el nodo líder, todos los nodos seguidores de la configuración zoo.cfg ya son iguales, se basan en la misma configuración de clúster para interconectarse y votar elección.