Zookeeper - Flujo de trabajo

Una vez que se inicia un conjunto de ZooKeeper, esperará a que los clientes se conecten. Los clientes se conectarán a uno de los nodos del conjunto ZooKeeper. Puede ser un nodo líder o seguidor. Una vez que un cliente está conectado, el nodo asigna un ID de sesión al cliente en particular y envía un reconocimiento al cliente. Si el cliente no recibe un reconocimiento, simplemente intenta conectar otro nodo en el conjunto de ZooKeeper. Una vez conectado a un nodo, el cliente enviará latidos al nodo en un intervalo regular para asegurarse de que no se pierda la conexión.

• If a client wants to read a particular znode, envía un read requestal nodo con la ruta de znode y el nodo devuelve el znode solicitado obteniéndolo de su propia base de datos. Por esta razón, las lecturas son rápidas en el conjunto ZooKeeper.

• If a client wants to store data in the ZooKeeper ensemble, envía la ruta de znode y los datos al servidor. El servidor conectado enviará la solicitud al líder y luego el líder volverá a emitir la solicitud por escrito a todos los seguidores. Si solo la mayoría de los nodos responde correctamente, la solicitud de escritura se realizará correctamente y se enviará un código de retorno al cliente. De lo contrario, la solicitud de escritura fallará. La estricta mayoría de nodos se denominaQuorum.

Nodos en un conjunto ZooKeeper

Analicemos el efecto de tener un número diferente de nodos en el conjunto ZooKeeper.

• Si tenemos a single node, entonces el conjunto ZooKeeper falla cuando falla ese nodo. Contribuye al "punto único de falla" y no se recomienda en un entorno de producción.

• Si tenemos two nodes y falla un nodo, tampoco tenemos mayoría, ya que uno de cada dos no es mayoría.

• Si tenemos three nodesy un nodo falla, tenemos mayoría y, por tanto, es el requisito mínimo. Es obligatorio que un conjunto de ZooKeeper tenga al menos tres nodos en un entorno de producción en vivo.

• Si tenemos four nodesy dos nodos fallan, vuelve a fallar y es similar a tener tres nodos. El nodo adicional no tiene ningún propósito y, por lo tanto, es mejor agregar nodos en números impares, por ejemplo, 3, 5, 7.

Sabemos que un proceso de escritura es caro que un proceso de lectura en el conjunto de ZooKeeper, ya que todos los nodos necesitan escribir los mismos datos en su base de datos. Por lo tanto, es mejor tener menos nodos (3, 5 o 7) que tener una gran cantidad de nodos para un entorno equilibrado.

El siguiente diagrama muestra ZooKeeper WorkFlow y la siguiente tabla explica sus diferentes componentes.

Componente	Descripción
Escribir	El proceso de escritura lo maneja el nodo líder. El líder reenvía la solicitud de escritura a todos los znodes y espera las respuestas de los znodes. Si la mitad de los znodes responden, entonces el proceso de escritura está completo.
Leer	Las lecturas se realizan internamente mediante un znode conectado específico, por lo que no es necesario interactuar con el clúster.
Base de datos replicada	Se utiliza para almacenar datos en zookeeper. Cada znode tiene su propia base de datos y cada znode tiene los mismos datos en todo momento con la ayuda de la coherencia.
Líder	Líder es el Znode que se encarga de procesar las solicitudes de escritura.
Seguidor	Los seguidores reciben solicitudes de escritura de los clientes y las reenvían al líder znode.
Procesador de solicitudes	Presente solo en el nodo líder. Gobierna las solicitudes de escritura del nodo seguidor.
Transmisiones atómicas	Responsable de transmitir los cambios desde el nodo líder a los nodos seguidores.