Análisis del principio de Zookeeper
1. Introducción a Zookeeper
ZooKeeper es un servicio de coordinación de código abierto de alta disponibilidad, alto rendimiento y alta consistencia diseñado para aplicaciones distribuidas. El servicio básico que proporciona es: servicio de bloqueo distribuido.
Las aplicaciones distribuidas pueden implementar servicios de nivel superior basados en él, como servicios de sincronización, mantenimiento de configuración y gestión de clústeres o servicios de nombres. El servicio Zookeeper en sí puede formar un clúster, 2n 1 (número impar) servicios pueden tolerar n fallas y Zookeeper está disponible cuando más de la mitad de las máquinas en el clúster están disponibles.
Suponiendo que un clúster tiene 3 máquinas, se puede tolerar una falla. Si ocurren 2 fallas, el clúster no estará disponible 1.5. número impar de máquinas. Propósito: Mejorar la tolerancia a fallas y permitir la pérdida de una unidad más.
1.1 Modelo de datos
1) ZooKeeper es esencialmente un sistema distribuido de almacenamiento de archivos pequeños
2) Zookeeper se comporta como un sistema de archivos jerárquico con estructura de árbol de directorios (a diferencia de él); En un sistema de archivos, los nodos pueden tener sus propios datos, mientras que los nodos de directorio en un sistema de archivos solo tienen nodos secundarios), cada nodo puede almacenar una pequeña cantidad de datos (1 M). Cada nodo puede almacenar una pequeña cantidad de datos (aproximadamente 1 M).
3) Cada nodo se llama ZNode. Cada ZNode puede identificarse de forma única por su ruta.
4) Los datos almacenados en cada nodo en ZooKeeper son una operación atómica. Esto significa que las operaciones de lectura recuperarán todos los datos relacionados con ese nodo y las operaciones de escritura reemplazarán todos los datos de ese nodo.
5) Cree un nodo secuencial en zookeeper (cree -s). La ruta del nodo va seguida de un número que es exclusivo del nodo principal del nodo.
/app/
/s100000000001
/s100000000002
6) Hay dos tipos de nodos en ZooKeeper, a saber, nodos temporales y Nodo permanente. El tipo de nodo se determina cuando se crea y no se puede cambiar.
① Nodo temporal: creado usando create -e en el cliente. El ciclo de vida del nodo depende de la sesión en la que se crea el nodo. Una vez finalizada la sesión, el nodo temporal se elimina automáticamente, pero también se puede eliminar manualmente. Aunque cada Znode temporal está vinculado a una sesión de cliente, son visibles para todos los clientes. Además, **No se permite que los nodos temporales de ZooKeeper tengan nodos secundarios.
② Nodos permanentes: El ciclo de vida de dichos nodos no tiene nada que ver con la sesión. Solo se pueden eliminar cuando el cliente muestra que quiere realizar una operación de eliminación.
7) El cliente puede configurar la monitorización en el nodo, al que llamamos monitor. Cuando el estado de un nodo cambia (adición, eliminación o modificación de Znode), se activará la operación correspondiente al monitoreo. Cuando se activa una vigilancia, ZooKeeper enviará una notificación, y solo una, al cliente.
Bloqueo distribuido
ZooKeeper es un diagrama de flujo de coordinación de alta disponibilidad
1.2 Introducción al rol de Zookeeper
El líder es responsable de iniciar y resolución de rondas Consulta, actualiza el estado del sistema (sincronización de datos) y envía latidos.
Alumnos, incluidos seguidores y observadores.
Los seguidores se utilizan para aceptar solicitudes de clientes, devolver resultados al cliente y participar en la votación en el proceso de selección maestra.
Los observadores pueden aceptar solicitudes de clientes y reenviarlas al líder, pero el observador no participa en el proceso de votación y solo sincroniza el estado del líder. El propósito del observador es expandir el sistema y. mejorar la velocidad de lectura.
1) Cuando el líder falla, un nuevo líder será reelegido entre los seguidores.
2) Cada seguidor tiene una conexión con el líder y recibe actualizaciones de datos del líder.
3) El cliente puede conectarse a cada servidor, p>
4) El cliente puede conectarse a cada servidor, y en cada servidor Los datos son exactamente los mismos
5) Cada servidor tiene una conexión con el líder, pero el observador no participa en el proceso de votación, solo sincroniza el estado del líder. p>
4) El servidor de servicio de cada nodo registra registros de transacciones e instantáneas en un almacenamiento persistente
1.3 Principio de funcionamiento
El núcleo de Zookeeper es la transmisión atómica. que es un mecanismo para garantizar la sincronización entre servidores individuales. El protocolo que implementa este mecanismo se llama protocolo Zab. El protocolo Zab tiene dos modos: modo de recuperación (selección maestra) y modo de transmisión (síncrono).
Modo de recuperación: Zab entra en modo de recuperación cuando se inicia el servicio o después de que el líder falla. El modo de recuperación no acepta solicitudes de clientes y finaliza cuando se elige un líder y la mayoría de los servidores han completado la sincronización con el estado del líder. La sincronización de estados garantiza que los líderes y servidores tengan el mismo estado del sistema.
Modo de transmisión: una vez que el líder completa la sincronización del estado con la mayoría de los seguidores, puede comenzar a transmitir información, es decir, ingresar al estado de transmisión. Cuando un servidor se une al servicio ZooKeeper, se inicia en modo de recuperación, descubre al líder y sincroniza su estado con el líder. El estado de transmisión de ZooKeeper continuará hasta que el líder colapse o pierda el apoyo de la mayoría de sus seguidores.
1.4 Proceso de operación de datos del nodo Zookeeper
(1) Operación de escritura
1) Enviar una solicitud de escritura al seguidor u observador en el cliente;
2) Seguidor u Observador envía la solicitud al Líder;
3) El Líder recibe la solicitud e inicia una propuesta.
4) El seguidor recibe la propuesta y realiza una operación de escritura, y luego envía el resultado de la operación al Líder
5) Cuando la mayoría de los seguidores devuelven el resultado de la propuesta, el Líder envía la propuesta; propone y notifica a otros seguidores y observadores sincronizar la información;
6) El seguidor u observador devuelve el resultado de la solicitud al cliente.
(2) Operación de lectura
1) Después de que el cliente envía una solicitud de lectura al seguidor u observador
2) El seguidor u observador devuelve la solicitud; resultado para el cliente;
1.5 características principales
Consistencia final: no importa a qué servidor esté conectado, el cliente verá la misma vista. Esta es la característica más importante de zookeeper. ;
Fiabilidad: Tiene un rendimiento simple, robusto y bueno. Si un servidor acepta un mensaje, será aceptado por todos los servidores.
Tiempo real: Zookeeper garantiza; que el cliente recibirá el mensaje en un cierto intervalo de tiempo. Obtenga información de actualización del servidor o información de falla del servidor dentro de un cierto período de tiempo. Sin embargo, debido a retrasos en la red y otras razones, Zookeeper no puede garantizar que ambos clientes obtengan datos actualizados al mismo tiempo. Si necesita los datos más recientes, debe llamar a la interfaz sync() antes de leer los datos;
Sin esperas: los clientes lentos o los clientes defectuosos no deben interferir con las solicitudes rápidas de los clientes para que cada cliente pueda esperar de manera efectiva. .
Atomic: las actualizaciones solo pueden tener éxito o fallar, no hay un estado intermedio;
Secuencial: las actualizaciones se realizan en el orden en que el cliente envía las solicitudes.
1.6 Escenarios de aplicación de zookeeper
1.6.1 Publicación y suscripción de datos
La publicación y la suscripción se denominan gestión de configuración. Como sugiere el nombre, son publicaciones de datos. to ZK Node permite a los suscriptores acceder dinámicamente a los datos y realizar una gestión centralizada y una actualización dinámica de la información de configuración.
La configuración de la aplicación se concentra en el nodo. Cuando se inicia la aplicación, obtendrá activamente la configuración y registrará observadores en el nodo. El observador será notificado cada vez que se actualice la configuración.
1.6.2 ¿Servicio de espacio de nombres? Servicio de nombres distribuido después de crear un nodo, la ruta del nodo es globalmente única y se puede utilizar como nombre global.
1.6.3 Notificación/coordinación distribuida
Diferentes sistemas escuchan el mismo nodo Una vez que hay una actualización, otros sistemas pueden recibir notificaciones.
1.6.4 Bloqueos distribuidos
Zookeeper garantiza una sólida coherencia de los datos, por lo que los usuarios pueden confiar en que los datos de cada nodo del clúster son los mismos en todo momento. Los bloqueos tienen dos formas:
(1) Mantener la exclusividad
Un usuario crea un nodo como bloqueo y otro usuario detecta el nodo. Si existe, indica que el otro. El usuario lo bloquea y, si no existe, se puede crear un nodo para representar la propiedad del bloqueo.
(2) Tiempo de control
Hay un nodo como nodo principal y debajo de él hay nodos secundarios con números. Todos los usuarios que quieran obtener el bloqueo deben crear un hijo numerado. nodos debajo del nodo principal. Para los nodos secundarios, el nodo con el número más pequeño mantendrá el bloqueo cuando se elimine el nodo con el número más grande, el bloqueo se liberará y luego se encontrará nuevamente el nodo con el número más pequeño; Mantenga la cerradura, lo que garantiza la sincronización global.
1.6.5 Gestión de clústeres
Cada máquina que se una al clúster creará un nodo y escribirá su propio estado. Los usuarios que monitoreen el nodo principal serán notificados y se actuará en consecuencia. Cuando se elimina un nodo mientras está ausente, los usuarios que monitorean el nodo principal también serán notificados.