Principios detallados de Zookeeper

La estructura de vista de Zookeeper es una estructura de árbol. Cada nodo del árbol se denomina nodo de datos (es decir, ZNode). Los datos se pueden almacenar en cada ZNode o montarse en nodos secundarios. El nodo raíz de Zookeeper es "/".

En Zookeeper, cada nodo de datos tiene un ciclo de vida y la duración de su ciclo de vida depende del tipo de nodo del nodo de datos. Hay varios tipos de nodos en Zookeeper:

Además de almacenar su contenido de datos, cada nodo de datos también almacena cierta información de estado (Estado) sobre el propio nodo de datos.

En Zookeeper, una transacción es una operación que cambia el estado del servidor Zookeeper. También la llamamos transacción u operación de actualización. Generalmente incluye la creación y eliminación de nodos de datos, y la actualización de nodos de datos. contenido, y la creación y creación de sesiones de clientes, Caducidad y otras operaciones. Zookeeper asigna a cada solicitud de transacción un ID de transacción único a nivel mundial, representado por ZXID, que suele ser un número de 64 bits. Cada ZXID corresponde a una operación de actualización y, a través de estos ZXID, puede determinar indirectamente el orden global en el que Zookeeper maneja estas solicitudes de actualización.

Un ZXID es un número de 64 bits, cuyos 32 bits inferiores pueden considerarse como un simple contador que aumenta monótonamente. Cuando el servidor Leader genera una nueva propuesta de transacción, la solicitud de transacción de cada cliente se incrementará en. 1, y los 32 bits superiores representan el número de época del ciclo líder. Siempre que se selecciona un nuevo servidor Leader, el ZXID de la propuesta de transacción más grande en el registro local se extraerá del servidor Leader, el valor de época correspondiente se analizará a partir del ZXID y luego se incrementará en 1, y luego el número se utilizará como nueva época y los 32 bits inferiores serán 0 para comenzar a generar un nuevo ZXID.

Zookeeper introduce el concepto de versiones para nodos de datos. Cada nodo de datos tiene tres tipos de información de versión (el significado de estos tres tipos de información de versión se describió en la información de estado anterior), y cualquier actualización del nodo de datos hará que cambie el número de versión. Tome la versión de datos como ejemplo. Después de crear un nodo de datos, el valor dataVersion del nodo es 0, lo que significa que "el nodo actual se ha actualizado 0 veces desde su creación". Si el contenido de datos del nodo ahora está actualizado, el valor de dataVersion pasará a ser 1.

Versión utilizada para implementar "escribir suma de comprobación" en el mecanismo de bloqueo optimista. Por ejemplo, cuando desee modificar el contenido de datos de un nodo de datos, ingrese el número de versión. Si el número de versión del nodo de datos es igual al número de versión pasado, se realizará la modificación; de lo contrario, la modificación fallará.

Zookeeper proporciona funcionalidad de publicación/suscripción para datos distribuidos. Un sistema modelo de publicación/suscripción típico define una relación de suscripción de uno a muchos, que permite que varios suscriptores escuchen un objeto de tema al mismo tiempo y notifica a todos los suscriptores cuando el estado del objeto de tema cambia, permitiéndoles responder. en consecuencia. En Zookeeper, se introduce un mecanismo de observador para implementar esta función de notificación distribuida. Zookeeper permite al cliente registrar un observador en el servidor. Cuando un evento específico en el servidor activa al observador, se enviará una notificación de evento al cliente especificado, realizando así la función de notificación distribuida.

En la figura anterior, podemos ver que el mecanismo Watcher de Zookeeper consta principalmente de tres partes: hilo del cliente, WatchMananger del cliente y servidor Zookeeper.

Desde el punto de vista del flujo de trabajo específico, en pocas palabras, cuando el cliente registra un observador en el servidor Zookeeper, el objeto del observador se almacenará en el WatchMananger del cliente. Cuando el servidor Zookeeper activa un evento de vigilancia, enviará una notificación al cliente y el hilo del cliente obtendrá el objeto de vigilancia correspondiente de WatchManager para ejecutar la lógica de devolución de llamada.

Watcher es una interfaz. Cualquier clase que implemente la interfaz Watcher es un nuevo Watcher. Contiene dos clases de enumeración: KeeperState y EventType.

Nota: El cliente recibe notificaciones de eventos que solo contienen información. sobre el estado y el tipo del evento, no sobre el tipo de evento.

Arriba analizamos el estado de la conexión del cliente de zookeeper y los tipos de eventos de los nodos znode que monitorea zookeeper. Usamos zk.getChildren(path, watch), zk.exists(path, watch), zk.getData(path, watcher, stat) para registrar oyentes para znode en zookeeper.

La siguiente tabla toma el nodo node-x como ejemplo para ilustrar la relación entre el método de registro llamado y los eventos escuchables:

Zookeeper proporciona un conjunto completo de ACL (control de acceso lista) para garantizar la seguridad de los datos.

La ACL consta de tres partes, a saber, modo de permiso (Esquema), objeto de autorización (ID) y permiso (Permiso). "Esquema:? Id: permiso" se usa generalmente para identificar información de ACL válida. La siguiente es una descripción de cada parte:

1.7.4 ACL Super Administrador

Uno de los modos de administración de permisos de zookeeper se llama super, que proporciona a los administradores acceso a nodos con cualquier permiso. Conveniente

Suponiendo que el administrador es: super:admin, debe generar un cifrado de contraseña para el administrador.

Luego abra zookeeper y cree una ACL para el nodo al que desea acceder. p> Luego abra el archivo de secuencia de comandos del servidor /bin/zkServer.sh en zookeeper y busque la siguiente línea:

Este es el comando para iniciar zookeeper en la secuencia de comandos. De forma predeterminada, solo existen las dos configuraciones anteriores. Necesitamos configurar Agregar un elemento de configuración a la tubería

Luego, después de la modificación, el comando completo se convierte en

Después de iniciar zookeeper, ingrese el siguiente comando para agregar permisos

En el servidor En la fase de inicialización del clúster, tomamos como ejemplo un clúster de servidores de tres máquinas. Cuando se inicia un servidor, el servidor1, no puede realizar la elección de líder. Cuando la segunda máquina, el servidor2, también se inicia. Los dos servidores ya pueden comunicarse entre sí y cada máquina puede comunicarse entre sí. Cuando se inicia la segunda máquina server2, los dos servidores pueden comunicarse entre sí y cada máquina intenta encontrar un líder, lo que conduce al proceso de elección del líder.

Durante el proceso de ejecución de zookeeper, los servidores líder y no líder realizan sus respectivas tareas. Incluso si el servidor no líder deja de funcionar o se agrega recientemente, no afectará al líder. el servidor líder se cuelga, todo el clúster suspenderá los servicios externos y entrará en una nueva ronda de elección de líder. Este proceso es básicamente el mismo que el proceso de elección de líder al inicio.

Suponiendo que el Servidor 1, el Servidor 2 y el Servidor 3 están todos ejecutándose, y que el líder actual es el Servidor 2, entonces, si el líder se bloquea en algún momento, comenzará la elección del líder. El proceso de elección es el siguiente:

Características del rol de observador:

Para utilizar el rol de observador, agregue la siguiente configuración a cualquier archivo de configuración al que desee convertir. el rol de observador:

y en los archivos de configuración de todos los servidores, agregar la línea de configuración para el servidor configurado en modo observador como configuración adicional. Por ejemplo: