Zookeeper - Fundamentos
Antes de profundizar en el funcionamiento de ZooKeeper, echemos un vistazo a los conceptos fundamentales de ZooKeeper. Discutiremos los siguientes temas en este capítulo:
- Architecture
- Espacio de nombres jerárquico
- Session
- Watches
Arquitectura de ZooKeeper
Eche un vistazo al siguiente diagrama. Representa la “Arquitectura Cliente-Servidor” de ZooKeeper.
Cada uno de los componentes que forman parte de la arquitectura de ZooKeeper se ha explicado en la siguiente tabla.
| Parte | Descripción |
|---|---|
| Cliente | Los clientes, uno de los nodos de nuestro clúster de aplicaciones distribuidas, acceden a la información desde el servidor. Durante un intervalo de tiempo particular, cada cliente envía un mensaje al servidor para informarle al servidor que el cliente está vivo. Del mismo modo, el servidor envía un acuse de recibo cuando un cliente se conecta. Si no hay respuesta del servidor conectado, el cliente redirige automáticamente el mensaje a otro servidor. |
| Servidor | Server, uno de los nodos de nuestro conjunto ZooKeeper, proporciona todos los servicios a los clientes. Da reconocimiento al cliente para informar que el servidor está activo. |
| Conjunto | Grupo de servidores de ZooKeeper. El número mínimo de nodos que se requiere para formar un conjunto es 3. |
| Líder | Nodo del servidor que realiza la recuperación automática si falla alguno de los nodos conectados. Los líderes se eligen al inicio del servicio. |
| Seguidor | Nodo del servidor que sigue las instrucciones del líder. |
Espacio de nombres jerárquico
El siguiente diagrama muestra la estructura de árbol del sistema de archivos de ZooKeeper utilizado para la representación de la memoria. El nodo ZooKeeper se conoce comoznode. Cada znode está identificado por un nombre y separado por una secuencia de ruta (/).
En el diagrama, primero tienes una raíz znodeseparado por "/". En root, tiene dos espacios de nombres lógicosconfig y workers.
los config El espacio de nombres se utiliza para la gestión de la configuración centralizada y workers el espacio de nombres se utiliza para nombrar.
Debajo configespacio de nombres, cada znode puede almacenar hasta 1 MB de datos. Esto es similar al sistema de archivos UNIX excepto que el znode padre también puede almacenar datos. El propósito principal de esta estructura es almacenar datos sincronizados y describir los metadatos del znode. Esta estructura se llamaZooKeeper Data Model.
Cada znode del modelo de datos de ZooKeeper mantiene un statestructura. Una estadística simplemente proporcionametadatade un znode. Consiste en el número de versión, la lista de control de acciones (ACL), la marca de tiempo y la longitud de los datos.
Version number- Cada znode tiene un número de versión, lo que significa que cada vez que cambian los datos asociados con el znode, su número de versión correspondiente también aumentará. El uso del número de versión es importante cuando varios clientes del zookeeper intentan realizar operaciones en el mismo znode.
Action Control List (ACL)- ACL es básicamente un mecanismo de autenticación para acceder al znode. Gobierna todas las operaciones de lectura y escritura de znode.
Timestamp- La marca de tiempo representa el tiempo transcurrido desde la creación y modificación de znode. Suele representarse en milisegundos. ZooKeeper identifica cada cambio en los znodes de "ID de transacción" (zxid).Zxid es único y mantiene el tiempo para cada transacción para que pueda identificar fácilmente el tiempo transcurrido entre una solicitud y otra.
Data length- La cantidad total de datos almacenados en un znode es la longitud de los datos. Puede almacenar un máximo de 1 MB de datos.
Tipos de Znodes
Los Znodes se clasifican como persistentes, secuenciales y efímeros.
Persistence znode- El znode de persistencia está vivo incluso después de que el cliente, que creó ese znode en particular, se desconecta. De forma predeterminada, todos los znodes son persistentes a menos que se especifique lo contrario.
Ephemeral znode- Los znodes efímeros están activos hasta que el cliente está vivo. Cuando un cliente se desconecta del conjunto ZooKeeper, los znodes efímeros se eliminan automáticamente. Por esta razón, solo los znodes efímeros no pueden tener más hijos. Si se elimina un znode efímero, el siguiente nodo adecuado ocupará su posición. Los znodes efímeros juegan un papel importante en la elección del líder.
Sequential znode- Los znodes secuenciales pueden ser persistentes o efímeros. Cuando se crea un nuevo znode como un znode secuencial, ZooKeeper establece la ruta del znode adjuntando un número de secuencia de 10 dígitos al nombre original. Por ejemplo, si un znode con ruta/myapp se crea como un znode secuencial, ZooKeeper cambiará la ruta a /myapp0000000001y establezca el siguiente número de secuencia como 0000000002. Si dos znodes secuenciales se crean simultáneamente, ZooKeeper nunca usa el mismo número para cada znode. Los znodes secuenciales juegan un papel importante en el bloqueo y la sincronización.
Sesiones
Las sesiones son muy importantes para el funcionamiento de ZooKeeper. Las solicitudes de una sesión se ejecutan en orden FIFO. Una vez que un cliente se conecta a un servidor, la sesión se establecerá ysession id se asigna al cliente.
El cliente envía heartbeatsen un intervalo de tiempo particular para mantener la sesión válida. Si el conjunto ZooKeeper no recibe latidos de un cliente durante más del período (tiempo de espera de la sesión) especificado al inicio del servicio, decide que el cliente murió.
Los tiempos de espera de la sesión generalmente se representan en milisegundos. Cuando una sesión finaliza por cualquier motivo, los znodes efímeros creados durante esa sesión también se eliminan.
Relojes
Los relojes son un mecanismo simple para que el cliente reciba notificaciones sobre los cambios en el conjunto de ZooKeeper. Los clientes pueden configurar relojes mientras leen un znode en particular. Los relojes envían una notificación al cliente registrado para cualquier cambio de znode (en el que se registra el cliente).
Los cambios de Znode son modificaciones de los datos asociados con el znode o cambios en los hijos del znode. Los relojes se activan solo una vez. Si un cliente quiere una notificación nuevamente, debe hacerlo a través de otra operación de lectura. Cuando expira una sesión de conexión, el cliente se desconectará del servidor y los relojes asociados también se eliminarán.