Bases teóricas del cuidador del zoológico
ZooKeeper fue desarrollado por Yahoo Research y luego donado a Apache. Es un servidor de coordinación de aplicaciones distribuidas de código abierto que proporciona servicios de coherencia para sistemas distribuidos. Su coherencia se logra mediante el protocolo ZAB basado en el algoritmo de Paxos. Sus funciones principales incluyen: mantenimiento de configuración, servicios de nombres de dominio, sincronización distribuida, gestión de clústeres, etc.
Sitio web oficial de Zookeeper: mit function. Vea las instrucciones a continuación.
La ejecución 3PC del algoritmo Paxos se divide en tres etapas: preparación, aceptación y envío.
Si el proponente recibe más de la mitad de los votos, transmitirá dos tipos de mensajes:
La diferencia entre 2PC y 3PC es que el proponente recibe más de la mitad de los votos. durante la fase de preparación Después de recibir comentarios de los votantes, enviará la propuesta real a todos los votantes. Cuando los votantes reciban la propuesta, la sincronizarán localmente sin esperar el mensaje de confirmación.
Entonces, ¿por qué no utilizar 2PC en lugar de 3PC? Esto se debe a que 2PC tiene muchas deficiencias (en las que no entraré aquí). Por lo tanto, muchas implementaciones industriales de Paxos utilizan envíos de 3PC. Pero el envío de 2PC es más eficiente que el envío de 3PC, por lo que si quiere estar seguro, también es factible utilizar el envío de 2PC.
El algoritmo Paxos presentado en la sección anterior tiene muchos inconvenientes en las aplicaciones de ingeniería reales, que dependen de las necesidades reales. Por lo tanto, existen muchos algoritmos de optimización para el algoritmo Paxos básico para mejorar el algoritmo Paxos, como Multi. Paxos, Paxos rápido y EPaxos. Por ejemplo, el algoritmo Paxos tiene un "problema de bloqueo en vivo". El algoritmo Fast Paxos mejora el algoritmo Paxos al permitir que solo un proceso envíe propuestas, es decir, este proceso tiene el derecho exclusivo de operar en N. Este enfoque resuelve el "problema de bloqueo en tiempo real".
ZAB (Zookeeper Atomic Broadcast) es un protocolo de transmisión atómica especialmente diseñado para que ZooKeeper admita la recuperación ante fallos. En Zookeeper, se basa principalmente en el protocolo ZAB para lograr la coherencia de los datos distribuidos.
Zookeeper utiliza un único proceso maestro para recibir y manejar todas las solicitudes transaccionales de los clientes, es decir, solicitudes de escritura. Cuando cambia el estado de los datos del servidor, el clúster los transmite a todos los procesos de réplica en forma de propuestas de asesoramiento de transacciones utilizando el protocolo de transmisión atómica ZAB.
El protocolo ZAB garantiza el ordenamiento global de los cambios, es decir, a cada transacción se le puede asignar un número delta global xid.
Cuando el cliente Zookeeper se conecta a un nodo en el clúster Zookeeper, si el cliente envía una solicitud de lectura, el nodo actual responderá directamente en función de sus propios datos guardados, y si la solicitud es una solicitud de escritura; el nodo actual Si no es el líder, el nodo reenviará la solicitud de escritura al líder, y el líder transmitirá la operación de escritura en forma de propuesta, siempre que más de la mitad de los nodos estén de acuerdo con la operación de escritura. , se finalizará la solicitud de operación de escritura. Siempre que más de la mitad de los nodos acepten la operación de escritura, se enviará la solicitud de escritura. Luego, el líder transmite nuevamente a todos los suscriptores (es decir, alumnos), notificándoles que sincronicen los datos.
El protocolo ZAB es una implementación industrial del algoritmo Paxos. El protocolo ZAB tiene como objetivo establecer un sistema maestro-esclavo de datos distribuidos de alta disponibilidad. En este sistema, los seguidores son esclavos del líder. Si el líder cuelga, se puede elegir un nuevo líder inmediatamente, pero normalmente informarán al líder. líder. Servicios prestados al público. El algoritmo rápido de Paxos se utiliza para construir un sistema de máquina de estado consistente distribuido para garantizar que el estado de cada nodo en el sistema sea consistente.
Además, ZAB también utiliza el algoritmo Chubby de Google como implementación de bloqueos distribuidos, que también es una aplicación del algoritmo Paxos.
El procesamiento de solicitudes de transacciones por parte del clúster zk es una expresión del algoritmo rápido de Paxos, que solo permite al líder hacer propuestas. Esta es una presentación de 3PC.
Sin embargo, la elección del líder también es una manifestación del algoritmo Paxos, porque cuando el líder cae, todos los seguidores pueden enviar sugerencias, y todos son "yo me elijo" inicialmente. Esta es la presentación de 2PC.
Para evitar el problema de punto único de Zookeeper, zk también está agrupado. La agrupación en clústeres de zk tiene tres funciones principales:
Alumno: alumno, sincronizador.
Alumno = Seguidor + Observador
QuorumPeer = Participante = Líder + Seguidor
Hay tres datos muy importantes en ZAB:
En En el modo de protocolo ZAB, zkServer tiene tres descripciones de estado. No existen límites muy claros entre estos tres modos; están entrelazados.
Cada host en el clúster zk se encuentra en un estado diferente en diferentes etapas. Cada anfitrión tiene cuatro estados.
Durante el inicio del clúster, o después de que el líder deja de funcionar, el clúster entra en modo de recuperación. La etapa más importante en el modo de recuperación es la elección de un líder.
A. serverId
Este es el identificador único del servidor en el clúster zk, también llamado sid, que es esencialmente el myid configurado en zk. Por ejemplo, si hay tres servidores zk, están numerados 1, 2 y 3.
B. Reloj lógico
El reloj lógico o reloj lógico es un número entero. Este concepto se llama reloj lógico durante la elección y se llama época después de la elección. Es decir, la época y el reloj lógico son iguales. valor. Diferentes nombres en diferentes contextos.
El proceso de elección de líder (algoritmo) cuando se inicia el grupo es ligeramente diferente del proceso de elección de líder después de que el líder se desconecta, pero es básicamente el mismo.
A. Elección del líder durante el inicio del clúster
Para el servidor 1, su voto es (1, 0), mientras que el voto que recibió del servidor 2 es (2, 0). El servidor 1 primero compara sus ZXID, ambos son 0, luego compara myid, que es el más grande para el servidor 2, por lo que el servidor 1 actualiza su voto a (2, 0) y vota nuevamente. Para el servidor 2, no necesita actualizar el voto, simplemente envía el último voto nuevamente a todos los hosts del clúster.
(4) Conteo de votos. Después de cada votación, el servidor cuenta los votos y determina si más de la mitad de las máquinas recibieron el mismo voto. Para el Servidor 1 y el Servidor 2, se cuenta que ambos hosts del clúster han recibido (2, 0) votos y el nuevo líder, el Servidor 2, se considera elegido.
(5) Cambiar el estado del servidor. Una vez que se determina el líder, cada servidor actualiza su estado a seguidor si es seguidor y a líder si es líder.
(6) Agregar host. Después de que se elige un nuevo líder, el Servidor 3 se inicia e intenta realizar una nueva ronda de elecciones. Sin embargo, dado que el estado actual de cada host en el clúster no es MIRAR, sino que funciona normalmente a su manera, solo puede unirse al clúster como Seguidor.
B. Elección del líder después del tiempo de inactividad
Durante la ejecución de Zookeeper, el servidor líder y el servidor no líder realizan sus respectivas tareas, incluso si el servidor no líder deja de funcionar o es nuevo Agregar un servidor no afectará al líder, pero si el servidor líder se bloquea, se suspenderá todo el clúster. Este proceso es esencialmente el mismo que el proceso de elección de líder durante el inicio.
Como se mencionó anteriormente, el modo de recuperación tiene dos fases: elección de líder y sincronización inicial. Después de la elección del líder, el líder sigue siendo un cuasi líder y debe someterse a una sincronización inicial para convertirse en un verdadero líder.
El proceso es el siguiente:
Cuando los alumnos del clúster completan la sincronización inicial, todo el clúster zk ingresa al modo de funcionamiento normal.
Si un nodo alumno en el clúster recibe una solicitud de transacción de un cliente, reenvía la solicitud al servidor líder. Luego realiza el siguiente proceso:
El número de observadores no siempre es mejor, generalmente es igual al número de seguidores. Debido a que el aumento en el número de observadores no aumentará la presión de las operaciones de transacción, pero requiere la sincronización de datos del líder, el tiempo para que los observadores sincronicen los datos es menor o igual que el tiempo para que los seguidores sincronicen los datos. Cuando se completa la sincronización del seguidor, los hosts observadores en la lista de observadores del líder finalizarán la sincronización. Los observadores que completen la sincronización pasarán a otra lista que brinde servicios al público. Entonces, aquellos hosts observadores que no han sincronizado datos y no pueden proporcionar servicios son un desperdicio de recursos.
Por lo tanto, para sistemas con transacciones frecuentes, no se recomienda utilizar demasiados observadores.
En realidad, hay dos listas de observadores en Leader:
todos: contiene todos los observadores.
servicio: Se ha completado la tarea de sincronización de datos con Leader.
El Líder en realidad almacena dos listas de Seguidores:
todos: requiere que más de la mitad de los Seguidores envíen ACK al Líder
servicio:
El clúster entrará en modo de recuperación cuando se esté iniciando o cuando el líder haya fallado. Es necesario seguir tres principios para restaurar el estado de los datos.
Si el número de latidos recibidos por el Líder del Seguidor en el clúster no excede la mitad del número de latidos recibidos por el Líder, el Líder pensará que hay un problema con su conexión con el clúster, y cambiará su estado a MIRANDO, para encontrar un nuevo Líder.
Otros servidores iniciarán el modo de recuperación porque más de la mitad de los hosts piensan que el líder está perdido, por lo que iniciarán el modo de recuperación para recuperar los datos.
En circunstancias normales, cuando el Líder recibe ACK de más de la mitad de los Seguidores, transmite un mensaje COMMIT a cada Seguidor para autorizar a cada servidor a realizar transacciones de escritura. Cuando cada servidor recibe un mensaje COMMIT del líder, realiza la operación de escritura localmente y luego responde al cliente que la operación de escritura fue exitosa.
Sin embargo, si el líder se cuelga antes de que todos los seguidores hayan recibido el mensaje COMMIT, se producirá un resultado: algunos servidores ejecutan la transacción, mientras que otros servidores no reciben el mensaje COMMIT, por lo que no ejecutan actas. Cuando se elige un nuevo líder, el clúster entrará en modo de recuperación y deberá asegurarse de que todos los servidores hayan realizado las transacciones que algunos servidores han realizado.
Cuando la nueva transacción del líder ha pasado y ha actualizado la transacción localmente, pero ningún seguidor ha recibido el COMMIT, el líder cae y ningún seguidor sabe que existe la propuesta. Si propuestas desconocidas para otros permanecen en ese host, tendrá más datos que otros hosts, lo que resultará en un estado inconsistente para todo el sistema. Por tanto, la "propuesta" debe descartarse. Las transacciones que deberían descartarse de esta manera ya no deberían aparecer en el clúster y deberían eliminarse.
Como dijimos antes, tanto la votación por escrito como la votación de elección de líder deben ser aprobadas por más de la mitad de los anfitriones, lo que significa que si más de la mitad de los anfitriones están caídos, la votación nunca se aprobará. . Según esta teoría, un grupo de 5 hosts solo puede permitir que como máximo 2 hosts caigan. Un grupo de 6 hosts solo puede permitir que como máximo 2 hosts caigan. En otras palabras, 6 hosts tienen las mismas capacidades de recuperación ante desastres que 5 hosts. Por lo tanto, se recomienda utilizar un número impar de hosts para formar un clúster para evitar el desperdicio de recursos.
Pero en términos de rendimiento del sistema, 6 hosts funcionarán mejor que 5 hosts. Por tanto, utilizar 6 hosts no es un desperdicio de recursos.
Para sistemas de alta disponibilidad, además de configurar varios hosts para implementarlos como un clúster para evitar puntos únicos de problemas, también debe considerar implementar el clúster en varias salas de ordenadores y varios edificios.
Los clústeres en varias salas de computadoras y en varios edificios no se pueden implementar a voluntad. El siguiente es un análisis de la implementación de varias salas de computadoras.
Al diseñar una implementación de sala de múltiples máquinas, se debe tener en cuenta la "regla de la mitad y la mitad", es decir, intentar garantizar que más de la mitad de las máquinas del clúster zk estén funcionando con normalidad.
En un entorno de producción, la implementación de tres salas de máquinas es la mejor y más común solución de recuperación ante desastres. La implementación de tres salas de computadoras requiere que la cantidad de hosts en cada sala de computadoras sea menos de la mitad de todo el clúster.
zk official no proporciona una mejor solución de recuperación ante desastres para la implementación de salas de computadoras duales. La única forma es hacer que una de las salas de computadoras tenga más de la mitad de los hosts, convirtiéndola en una sala de computadoras, y la otra sala de computadoras tenga menos de la mitad de los hosts. Por supuesto, si hay un problema en la sala de ordenadores principal, todo el clúster quedará paralizado.
El teorema CAP, también conocido como principio CAP, establece que en un sistema distribuido, la coherencia, la disponibilidad y la tolerancia de partición no son mutuamente excluyentes.
Para los sistemas distribuidos, el entorno de red es relativamente incontrolable y las particiones de red son inevitables, por lo que el sistema debe ser tolerante a fallas de partición.
Para sistemas distribuidos, el principio CAP solo se puede implementar de dos maneras: CP o AP.
BASE es un homónimo de las tres frases Básicamente Disponible, Estado Suave y Eventualmente consistente. Al final consistente.
La idea central de la teoría BASE es que incluso si la coherencia en tiempo real no es posible, cada sistema puede lograr una coherencia eventual de una manera adecuada a sus características comerciales.
La disponibilidad básica se refiere a permitir que un sistema distribuido pierda algo de disponibilidad cuando ocurren fallas impredecibles.
Pérdida de tiempo de respuesta:
Pérdida funcional:
El estado suave es un estado intermedio que permite que existan los datos del sistema y considera la existencia de este estado intermedio. no afectará la disponibilidad general del sistema, es decir, se permite un cierto retraso en el proceso de sincronización de datos entre los hosts del sistema. El estado blando es en realidad un estado gris, un estado de transición.
La coherencia eventual enfatiza que todas las copias de datos en el sistema pueden eventualmente alcanzar un estado consistente después de un período de sincronización. Por lo tanto, la esencia de la coherencia eventual es que el sistema necesita garantizar que los datos finales puedan lograr coherencia, sin garantizar la coherencia en tiempo real de los datos del sistema.
Desde la perspectiva del tiempo necesario para lograr la coherencia, se puede dividir en:
Desde la perspectiva del contenido al que el cliente accede solo, se puede dividir en:
zk sigue el principio CP, que garantiza la coherencia a expensas de la disponibilidad. ¿De qué manera se refleja esto?
Cuando el líder cae, el clúster zk elegirá inmediatamente un nuevo líder. Sin embargo, el tiempo de elección suele ser inferior a 200 milisegundos y no más de 60 segundos, y durante la elección, el clúster zk no acepta lecturas ni escrituras del cliente, lo que significa que el clúster zk está paralizado. Por lo tanto, no está disponible.
Cuando decimos que ZooKeeper puede causar cerebro dividido, queremos decir que en una implementación de múltiples alojamientos, si hay problemas de conectividad de red que crean múltiples particiones, entonces puede ocurrir un cerebro dividido, lo que resulta en datos inconsistentes. .
(1) Escenario 1
(2) Escenario 2
(5) Escenario 5