Red de conocimiento informático - Conocimiento del nombre de dominio - Descripción general de los mecanismos comunes de elección de grupos distribuidos

Descripción general de los mecanismos comunes de elección de grupos distribuidos

1, Zookeeper -- paxos

2, kafka -- crear nodos en zookeeper

3, redis -- modo centinela

4, Eureka -- replicación mutua

Cuando exploramos los mecanismos de elección de estos clústeres, en realidad estamos explorando su alta disponibilidad. ¿Cómo garantizar la disponibilidad si algunos nodos del clúster se bloquean? Este problema es uno de los tres principales problemas que enfrentan los sistemas distribuidos.

El mecanismo de elección de líder de Zookeeper es el mecanismo de elección más complejo entre los cuatro grupos y también es la implementación más cercana al algoritmo paxos entre los cuatro grupos. En comparación con el mecanismo de elección de Zookeeper, el mecanismo de elección del clúster Kafka, el clúster Redis y el clúster Eureka es mucho más simple.

La elección del líder de Zookeeper es la clave para la coherencia de los datos de Zookeeper, pero también existen algunos problemas. Aún es necesario reconocer las ventajas y desventajas de Zookeeper para que podamos usarlo bien.

El mecanismo de elección de Zookeeper tiene dos puntos de activación: la fase de inicio del clúster y la fase de ejecución del clúster cuando el líder se cuelga. El proceso electoral en estos dos casos es básicamente el mismo. Tomemos como ejemplo la suspensión del líder durante la fase de operación del grupo. Después de que el líder se cuelgue, vuelva a elegirlo. El proceso de elección es el siguiente:

1. El seguidor del grupo Zookeeper detecta que el líder se ha colgado, luego establece su estado en MIRANDO y comienza la elección del líder.

2. Cada servidor se elige a sí mismo como líder y luego notifica a otros servidores sobre los resultados de su votación mediante transmisión.

3. Cada servidor recibe votos de otros servidores y realiza controles de legalidad. Hay dos controles principales, uno es la inspección de la ronda electoral y el otro es la inspección del estado del servidor.

4. Procesar los votos. Cada servidor combinará sus propios votos con los de otros servidores. Las reglas de PK son las siguientes:

La primera regla: PK ZXID primero y el más grande gana.

La segunda regla: si ZXID es igual, entonces PK myid, el más grande gana.

Una vez finalizado el PK, si el servidor actual pierde el PK, volverá a votar su voto al ganador y luego notificará a otros servidores para que actualicen sus votos mediante transmisión.

5. Cuente los votos. Según el principio de más de la mitad de los votos, cada servidor contará los votos de LEADER. Si los votos son más de la mitad, la elección finalizará.

6. Actualizar el estado del servidor. Los seguidores actualizan su estado a SIGUIENTE y los líderes actualizan su estado a LÍDER.

Bien, este es el mecanismo de elección de líder de Zookeeper. Después de varias rondas de elecciones, el grupo Zookeeper continúa brindando servicios al público. Dado que el PK de la boleta compara primero el ZXID, Zookeeper puede garantizar que los datos del líder estén actualizados.

¿Cómo garantiza un clúster Kafka una alta disponibilidad?

Kafka utiliza Zookeeper para gestionar la configuración del clúster, elegir líderes y realizar reequilibrios cuando cambia el grupo de consumidores.

Entonces quiero preguntar, ¿cómo elige Kafka al líder?

En resumen, el proceso de elección del líder de Kafka es el siguiente: todos los agentes en Kafka crean un nodo temporal en la ruta /controller de Zookeeper. El agente que crea con éxito el nodo temporal se convertirá en el líder. Otros agentes se convertirán en seguidores.

Cuando el líder está suspendido, puede usarse como líder o como seguidor.

Cuando el líder se cuelga, el nodo temporal se eliminará. Este es el mecanismo de monitoreo de otros nodos a través de Zookeeper, que escuchará el cambio del líder y luego todos los seguidores serán elegidos como líderes. de nuevo.

La elección de Kafka es en realidad la creación de nodos temporales, que es básicamente el mismo principio que la implementación de bloqueo distribuido de Zookeeper.

Comprenda la conmutación maestro-esclavo de Redis y el clúster de Redis.

Tenga en cuenta que la conmutación maestro-esclavo tiene solo un nodo maestro de forma predeterminada, pero no hay conmutación maestro-esclavo en un clúster con múltiples nodos maestros.

Redis no tiene un mecanismo de elección similar a Zookeeper. Cuando el nodo maestro de Redis cuelga, el clúster de Redis cambiará del nodo maestro al nodo esclavo para garantizar una alta disponibilidad.

Existen dos métodos para cambiar entre maestro y esclavo de Redis: manual y automático.

Aquí analizamos el cambio automático. El cambio automático maestro-esclavo de redis requiere el soporte del modo centinela. El modo centinela simplemente significa: monitorear la estación maestra y la estación esclava. la estación esclava cambiará automáticamente a la estación esclava. Cambie a la estación maestra Una vez restaurada la estación maestra, sirve como estación esclava de la nueva estación maestra para brindar servicios al mundo exterior.

Las anteriores son las dos primeras formas de utilizar el sistema.

Para ser precisos, no existe una relación maestro-esclavo entre los nodos del clúster Eureka. Los nodos del clúster Eureka tienen una relación punto a punto, mientras que los otros tres tipos de clústeres tienen una relación maestro-esclavo, que es una característica del clúster Eureka.

Los servidores del clúster Eureka logran una alta disponibilidad del clúster registrándose entre sí. Los datos se sincronizan mediante copias de seguridad incrementales, lo que garantiza que cada servidor tenga los datos más recientes y completos. Esto garantiza una alta disponibilidad del clúster. Esto garantiza una alta disponibilidad del clúster, de modo que incluso si el servidor se bloquea, el clúster aún puede proporcionar servicios al mundo exterior.

Eureka tiene un elemento de configuración: eureka.client.fetch-register, que indica si se debe obtener información de registro del servidor Eureka. Si somos un clúster de Eureka, entonces este elemento se configura en verdadero para que los servidores de Eureka puedan registrarse entre sí directamente.

Bueno, este artículo solo ofrece una introducción general al mecanismo de elección de los cuatro grupos, y los detalles específicos aún son muy complicados. El artículo anterior se centró en analizar la elección del líder de Zookeeper. A continuación, escribiremos otro artículo para analizar el mecanismo de elección de varios otros grupos, y habrá una explicación más profunda en ese momento.