Introducción básica a [Serie Zookeeper]
Muchos sistemas distribuidos proporcionan servicios basados en ZK como componente central subyacente. Por ejemplo, en Kafka, los intermediarios están registrados en ZK, que desempeña múltiples funciones, como centro de registro y elección. Para otro ejemplo, muchos de los proyectos actuales de nuestra empresa son Dubbo, que requieren descubrimiento y registro de servicios basados en ZK.
Además, ZK tiene muchos algoritmos e ideas de diseño excelentes. La familiaridad con el código fuente de ZK también puede mejorar su "fuerza interna".
¿Cómo empezar a utilizar Zookeeper rápidamente? ¡La forma más sencilla es ir directamente al sitio web oficial de Zookeeper! Se recomienda que los lectores consulten los documentos oficiales y el contenido del blog juntos para obtener mejores resultados~
El logotipo de Zookeeper parece un paleador de mierda que sirve a los animales del zoológico.
"Un servicio de coordinación distribuido para aplicaciones distribuidas" es la explicación oficial. Podemos saber que Zookeeper es algo que proporciona servicios de coordinación para marcos distribuidos.
Por ejemplo, qué marcos distribuidos utilizan Zookeeper:
Las capacidades de ZK no terminan ahí. De hecho, también puede implementar equilibrio de carga, configuración unificada, colas distribuidas, etc. Sin embargo, hay relativamente pocos escenarios de uso y se utilizarán otros componentes de marco más profesionales en sistemas de nivel empresarial.
Cerraduras distribuidas, centros de registro y elecciones de líderes serán los contenidos clave compartidos en la serie ZK, así que estad atentos~
En ZK, primero debes comprender los conceptos de algunos términos profesionales, pero no los enumerará todos a la vez. Cuando los conozca en el futuro, me centraré en el análisis. ...
En el clúster ZK, se dividirá en roles de líder, seguidor y observador.
Como líder del clúster, el líder es responsable de las solicitudes de escritura y parte de las solicitudes de lectura; como hermano menor del líder, el seguidor será responsable de parte de las solicitudes de lectura cuando reciba una solicitud de escritura. solicitud, la reenviará al líder, las solicitudes de escritura son manejadas por el líder y los observadores son un poco especiales. Los nodos observadores no participan en el mecanismo de elección y reducción a la mitad de mensajes. Los lectores que no tengan claro esto pueden simplemente tener un recuerdo por ahora y concentrarse en él más tarde.
De hecho, los nodos solo se dividen en nodos persistentes y nodos temporales, pero algunos escenarios necesitan garantizar el orden, por lo que agregaremos números de secuencia (incrementalmente) a los nodos persistentes o temporales para formar nodos de secuencia persistentes. y nodos temporales. & lt/br & gt;Entonces, ¿qué es un nodo persistente y qué es un nodo temporal? El fenómeno más intuitivo es que cada cliente ZK generará un nodo después de conectarse al clúster ZK. Si el cliente ZK se desconecta, el nodo todavía existe como un nodo permanente, si el nodo desaparece después de que el cliente ZK se desconecta, el nodo es un nodo temporal.
Antes de que se inicie el cliente ZK, puede personalizar la función de devolución de llamada de escucha. ¿Para qué es esto? Una vez que se inicia el cliente, envía eventos de monitoreo al clúster Zookeeper, que tiene una lista de eventos de monitoreo registrados. Cuando cambian los nodos del directorio monitoreados por el cliente, como cambios de datos de nodos, adiciones y eliminaciones de nodos, etc. , La función de monitoreo de devolución de llamada del cliente correspondiente se encontrará a través de la lista de monitoreo del clúster ZK, y el cliente puede tomar las acciones correspondientes según el escenario comercial.
El nombre completo del protocolo ZAB es: Zookeeper Atomic Broadcasting. ZAB es el algoritmo central de Zookeeper para garantizar la coherencia de los datos. Basándose en las ideas del algoritmo Paxos, un protocolo de transmisión atómica que admite la recuperación tras fallos está especialmente diseñado para Zookeeper. Incluye dos modos básicos: transmisión de mensajes y recuperación tras fallos.
La transmisión de mensajes significa que solo un líder en el clúster procesa la solicitud de escritura y transmite el evento de solicitud de escritura a todos los seguidores, al tiempo que garantiza que no se pierdan datos. (En otras palabras, la escritura de mensajes es atómica, porque solo el líder puede escribirlos).
La recuperación tras un fallo se refiere a cuando el clúster ZK acaba de iniciarse y el líder aún no ha sido elegido, o el líder Debido a fallas, reinicio, red y otras razones, el protocolo ZAB ingresará al modo de recuperación de fallas. El propósito es elegir un nuevo líder y garantizar que los datos del nuevo líder estén actualizados para evitar la pérdida de paquetes de un solo punto debido. al fracaso del líder. En cuanto a los principios específicos de ZAB, primero puede leer el artículo de referencia a continuación y luego escribiré un artículo específico sobre ZAB cuando tenga la oportunidad.
Artículo de referencia del protocolo ZAB
La estructura del modelo de datos en ZK es muy similar al sistema de archivos Unix y es una estructura de datos de árbol jerárquico. En ZK, las estructuras de datos en forma de árbol utilizan nodos llamados ZNode para contener datos. ZNode es la unidad de estructura de datos más pequeña de ZK. No solo puede guardar datos, sino también montar nodos secundarios para formar un árbol jerárquico.
Vale la pena señalar que la creación de ZNode es una operación pura de memoria, por lo que es muy rápida. Luego, los datos de ZNode se conservarán en el disco regularmente dentro de ZK.
Como todos sabemos, en las aplicaciones empresariales reales, frente a escenarios de alta concurrencia, ciertamente no se puede implementar en un solo nodo, sino que se debe implementar a través de clústeres (denominados "tres máximos") para garantizar alta concurrencia y alto rendimiento, alta disponibilidad.
Alto rendimiento: debido a que los nodos ZNode operan exclusivamente con memoria, siempre que ZK se implemente en un servidor de alta configuración, no hay problema para que tres servidores ZK soporten decenas de miles de solicitudes por segundo. Alta disponibilidad: siempre que se implemente un número impar de clústeres de servidores (como 3, 5, 11 máquinas), siempre que no más de la mitad de los servidores estén inactivos, se puede garantizar que el clúster ZK esté disponible. Alta concurrencia: debido a que ZNode es una operación de memoria pura, escribe datos muy rápidamente; el nodo maestro y los nodos esclavos en el clúster ZK pueden manejar solicitudes de lectura, por lo que el clúster ZK tiene capacidades sólidas de alta concurrencia.
Basado en el protocolo ZAB, las solicitudes de escritura son procesadas de manera uniforme por el servidor líder y luego el líder transmite las solicitudes de datos de escritura a otros seguidores.
Pero, ¿los mensajes serán inconsistentes debido a diversas razones, como fluctuaciones de la red, daño cerebral del líder, tiempo de inactividad de los seguidores, etc.?
De hecho, ZK adopta la idea de envío de dos etapas 2PC, combinada con la transmisión de mensajes ZAB para garantizar la coherencia de los datos. Vale la pena señalar que Zookeeper solo puede garantizar una coherencia eventual, no una coherencia sólida.
Entonces, ¿cómo garantizar la máxima coherencia de los datos? Los lectores interesados pueden consultar mi otro mal libro TODO. ...
Materiales de referencia:
Principios y prácticas de coherencia distribuida desde Paxos hasta Zookeeper
Si crees que el artículo es bueno, dale me gusta. ¡Tu aliento es mi motivación! Si hay algo que no está claro o es incorrecto en el artículo, deje un mensaje en el área de comentarios~