Modelo de datos de ZooKeeper, características del nodo, versión, observador, concepto de control de permisos de ACL

Modelo de datos

    La estructura de datos de ZooKeeper es muy similar a la estructura de árbol del sistema de archivos Unix , pero no existe un concepto de directorios y archivos. Cada nodo de datos se llama ZNode , y la ruta del nodo es muy similar a la ruta del sistema de archivos Unix. Podemos escribir datos en un nodo o crear nodos secundarios debajo del nodo.

    En ZooKeeper, las transacciones se refieren a operaciones que pueden cambiar el estado del servidor de ZooKeeper, que generalmente incluyen operaciones como la creación y eliminación de nodos de datos, actualización de contenido y creación e invalidación de sesiones de clientes. Para cada solicitud de transacción, ZooKeeper le asignará un ID de transacción único a nivel mundial , que está representado por ZXID , generalmente un número de 64 bits, y cada ZXID corresponde a una operación de actualización.

Características del nodo

Tipo de nodo

    Los tipos de nodos se dividen en: nodo persistente ( PERSISTENT ), nodo de secuencia persistente ( PERSISTENT_SEQUENTIAL ), nodo temporal ( EPHEMERAL ), nodo de secuencia temporal ( EPHEMERAL_SEQUENTIAL ).
    Un nodo persistente significa que después de que se crea el nodo de datos, siempre existirá en el servidor de ZooKeeper hasta que haya una operación de eliminación para borrar activamente el nodo.
    El nodo temporal significa que su ciclo de vida está vinculado a la sesión del cliente, si la sesión del cliente falla, el nodo se borrará automáticamente.
    Nodo secuencial significa que en el proceso de creación de un nodo, ZooKeeper agregará automáticamente un sufijo numérico al nombre de nodo dado como un nombre de nodo nuevo y completo. El límite superior de este sufijo numérico es el valor máximo de modelado.

Atributos de estado de estadísticas

    Además del contenido de datos almacenados, el nodo de datos también almacena alguna información de estado del propio nodo de datos. La información de estado está encapsulada en el objeto Stat. La siguiente es la descripción de los atributos de estado del objeto Stat:

Atributo de estado	Descripción
czxid	Indica el ID de la transacción cuando se creó el nodo de datos
mzxid	Indica el ID de transacción cuando el nodo se actualizó por última vez
pzxid	Indica el ID de la transacción cuando se modificó por última vez la lista de nodos secundarios del nodo (solo se actualizará la lista de nodos secundarios y el cambio de contenido del nodo secundario no afectará a pzxid)
ctime	Indica el momento en que se creó el nodo
mtime	Indica la hora en que se actualizó por última vez el nodo
versión	El número de versión del nodo de datos
cversion	El número de versión del nodo hijo
aversión	Número de versión de ACL del nodo
ephemeralOwner	El ID de sesión de la sesión que creó el nodo temporal. Si el nodo es un nodo persistente, el valor de este atributo es 0
longitud de datos	La longitud del contenido de los datos.
numChildren	El número de nodos secundarios del nodo actual.

versión

    La versión aquí indica el número de veces que se ha modificado el contenido de datos del nodo de datos, la lista de nodos secundarios o la información de ACL del nodo . Cuando un nodo de datos se crea correctamente, su valor de versión es 0, lo que significa que el nodo se ha actualizado 0 veces desde que se creó. Si se actualiza el contenido de datos del nodo, el valor de la versión se convertirá en 1.
    La versión se utiliza para evitar algunos problemas de concurrencia de actualizaciones distribuidas, como los servicios de bloqueo distribuido (para garantizar el funcionamiento atómico de los datos distribuidos). Si el cliente A intenta realizar una operación de actualización, se actualizará con el valor de versión obtenido la última vez. Si durante este período de tiempo, los datos del nodo en el servidor de ZooKeeper son actualizados por otros clientes, entonces la versión de los datos debe haber cambiado. La última versión de datos no puede coincidir con la versión llevada por el cliente A, por lo que el cliente A no puede actualizarse correctamente.
    Si no hay un requisito atómico para la operación de actualización del nodo de datos de ZooKeeper, entonces el parámetro de versión de datos puede usar -1 para decirle al servidor que el cliente necesita actualizar en base a la última versión de los datos.

Vigilante

    En ZooKeeper, se introduce el mecanismo Watcher para realizar la función de publicación / suscripción de datos distribuidos . ZooKeeper permite que el cliente registre un Watcher en el servidor.Cuando algunos eventos específicos en el servidor activan el Watcher, enviará una notificación de evento al cliente especificado.

Evento Vigilado

    En ZooKeeper, la clase de interfaz Watcher se utiliza para representar un controlador de eventos estándar, que define la lógica relacionada con la notificación de eventos, incluidas dos clases de enumeración KeeperState y EventType , que representan el estado de notificación y el tipo de evento, y definen el evento al mismo tiempo. El proceso del método de devolución de llamada (evento WatchedEvent) .

KeeperState	Tipo de evento	Condiciones desencadenantes
SyncConnected	Ninguna	El cliente y el servidor establecen correctamente una sesión
SyncConnected	NodeCreated	Se crea el nodo de datos correspondiente supervisado por Watcher
SyncConnected	NodeDeleted	Se elimina el nodo de datos correspondiente supervisado por Watcher
SyncConnected	NodeDataChanged	Cambios en el contenido de datos del nodo de datos correspondiente monitoreado por Watcher
SyncConnected	NodeChildrenChanged	La lista de nodos secundarios del nodo de datos correspondiente supervisado por Watcher cambia
Desconectado	Ninguna	El cliente se desconecta del servidor de ZooKeeper
Caducado	Ninguna	Hora de término de la sesión
AuthFailed	Ninguna	Utilice un esquema incorrecto para la verificación de permisos o la verificación de permisos SASL falló
ConnectedReadOnly	Ninguna	Modo de solo lectura

package org.apache.zookeeper;

import org.apache.yetus.audience.InterfaceAudience;
import org.apache.zookeeper.proto.WatcherEvent;
import org.apache.zookeeper.Watcher.Event.EventType;
import org.apache.zookeeper.Watcher.Event.KeeperState;

/**
 *  A WatchedEvent represents a change on the ZooKeeper that a Watcher
 *  is able to respond to.  The WatchedEvent includes exactly what happened,
 *  the current state of the ZooKeeper, and the path of the znode that
 *  was involved in the event.
 */
@InterfaceAudience.Public
public class WatchedEvent {
    
    
    final private KeeperState keeperState;
    final private EventType eventType;
    private String path;
    
    /**
     * Create a WatchedEvent with specified type, state and path
     */
    public WatchedEvent(EventType eventType, KeeperState keeperState, String path) {
    
    
        this.keeperState = keeperState;
        this.eventType = eventType;
        this.path = path;
    }
    
    /**
     * Convert a WatcherEvent sent over the wire into a full-fledged WatcherEvent
     */
    public WatchedEvent(WatcherEvent eventMessage) {
    
    
        keeperState = KeeperState.fromInt(eventMessage.getState());
        eventType = EventType.fromInt(eventMessage.getType());
        path = eventMessage.getPath();
    }
    
    public KeeperState getState() {
    
    
        return keeperState;
    }
    
    public EventType getType() {
    
    
        return eventType;
    }
    
    public String getPath() {
    
    
        return path;
    }

    @Override
    public String toString() {
    
    
        return "WatchedEvent state:" + keeperState
            + " type:" + eventType + " path:" + path;
    }

    /**
     *  Convert WatchedEvent to type that can be sent over network
     */
    public WatcherEvent getWrapper() {
    
    
        return new WatcherEvent(eventType.getIntValue(), 
                                keeperState.getIntValue(), 
                                path);
    }
}

    WatchedEvent encapsula tres atributos básicos de cada evento del servidor: estado de notificación (KeeperState), tipo de evento (EventType) y ruta del nodo (Path). Una vez que el servidor genera el evento WatchedEvent , llamará al método getWrapper para integrarse en un evento WatcherEvent serializable y luego lo transmitirá al cliente a través de la red. Una vez que el cliente recibe el objeto de evento del servidor, restaurará el evento WatcherEvent a un evento WatchedEvent y lo pasará al método de proceso para su procesamiento. Por lo tanto, WatchedEvent es un evento lógico, utilizado para los objetos lógicos necesarios durante la ejecución de los programas del servidor y del cliente. WatcherEvent implementa una interfaz de serialización para la transmisión de red.
    Ya sea WatchedEvent o WatcherEvent, el evento del servidor simplemente está encapsulado. El cliente no puede obtener directamente el contenido de datos original del nodo de datos correspondiente y el nuevo contenido de datos después del cambio del evento. El cliente necesita obtener activamente los datos (ZooKeeper usa Modo de combinación push-pull , monitoreo del cliente, notificación del servidor, el cliente obtiene datos activamente).

Funciones de Watcher

    El mecanismo de trabajo de Watcher se puede resumir como: el cliente registra a Watcher, el servidor procesa Watcher y el cliente devuelve la llamada a Watcher.
    Cuando el cliente registra Watcher con el servidor, no pasa el objeto Watcher al servidor, pero usa el atributo de tipo booleano para marcar la solicitud del cliente. Al mismo tiempo, el servidor solo guarda el objeto ServerCnxn actualmente conectado (ServerCnxn representa la conexión entre el cliente y el servidor). Esto se hace para reducir la sobrecarga de transmisión de la red.
    Una vez : ya sea en el servidor o en el cliente, una vez que se activa un Watcher, ZooKeeper lo eliminará del almacenamiento correspondiente.
    El proceso de devolución de llamada de Watcher del cliente es un proceso de sincronización en serie, que asegura el orden de ejecución.

Control de permisos ACL

    El método de control de permisos utilizado en el sistema de archivos Unix / Linux es el mecanismo de control de permisos UGO (Usuario, Grupo, Otros). Un archivo o directorio se configura con diferentes permisos para el creador (Usuario), el grupo del creador (Grupo) y otros usuarios (Otros). UGO es un modo de control de permisos del sistema de archivos de grano grueso. No puede resolver el siguiente escenario: El usuario U ₁ crea un archivo F ₁ y espera que el grupo de usuarios G ₁ donde se encuentra U ₁ tenga permiso para leer, escribir y ejecutar en F ₁ , y Un grupo de usuarios G ₂ tiene permisos de lectura, mientras que otro usuario U ₃ no tiene ningún permiso.
    La lista de control de acceso (ACL) puede realizar un control de permisos detallado para cualquier usuario y grupo. Por lo general, use el modo de permiso (Esquema), objeto de autorización (ID), permiso (Permiso), "Esquema: ID: Permiso" para representar una información ACL válida.
    El modo de autorización se utiliza para determinar la estrategia de inspección utilizada en el proceso de verificación de autorización. Generalmente se utilizan los siguientes cuatro modos de permiso:

Modo de permiso	Descripción
IP	El control de permisos se realiza por dirección IP, por ejemplo, se configura "IP: 192.168.0.1", lo que significa que el control de permisos es para esta dirección IP. Al mismo tiempo, el modo IP también admite la configuración de acuerdo con el segmento de red. Por ejemplo, "IP: 192.168.0.1/24" significa que la autoridad está controlada para el segmento de red 192.168.0. *.
Digerir	Digest es el modo de control de permisos más utilizado. Utilice la identificación de autoridad en forma de "nombre de usuario: contraseña" para la configuración de la autoridad, que es conveniente para distinguir diferentes aplicaciones para el control de la autoridad. Cuando configuramos la identificación de autorización a través de la forma de "nombre de usuario: contraseña", ZooKeeper la codificará dos veces, es decir, cifrado del algoritmo SHA-1 y codificación BASE64.
Mundo	World es el modo de control de acceso más abierto. La autoridad de acceso del nodo de datos está abierta a todos los usuarios, y todos los usuarios pueden operar los datos en ZooKeeper sin ninguna verificación de autoridad. El modo Mundo se puede considerar como un modo Resumen especial, que solo tiene una identificación de autoridad, a saber, "mundo: cualquiera" .
súper	El modo súper también es un modo resumen especial. En el modo Super, el superusuario puede realizar cualquier operación en cualquier nodo de datos.

    El objeto autorizado se refiere al usuario o una entidad específica a quien se le otorga la autoridad. Por ejemplo, dirección IP o máquina.

Modo de permiso	Descripción
IP	Dirección IP o segmento de red IP
Digerir	Personalizado, generalmente "nombre de usuario: BASE64 (SHA-1 (nombre de usuario: contraseña))"
Mundo	Solo una identificación: cualquiera
súper	Consistente con el modo de resumen

    El permiso se refiere a las operaciones que se pueden realizar después de pasar la verificación de permisos

Autoridad	Descripción
CREAR（c）	Permiso de creación de nodos de datos, que permite que los objetos autorizados creen nodos secundarios bajo el nodo de datos
BORRAR（d）	Permiso de eliminación de nodo de datos
LEER（r）	El permiso de lectura del nodo de datos, que permite a los objetos autorizados acceder al nodo de datos y leer su contenido de datos o lista de nodos secundarios, etc.
ESCRIBIR（w）	Actualizar los permisos de los nodos de datos
ADMIN（a）	La autoridad de gestión del nodo de datos, que permite que los objetos autorizados realicen operaciones de configuración de ACL relacionadas en el nodo de datos.

    Establecer el método 1 de ACL: crear [-s] [-e] datos de ruta acl

create -e /temp nothing digest:abc:123456:cdrwa

    Establecer el método de ACL dos: setAcl path acl

setAcl /temp digest:abc:123456:cdrwa