En pocas palabras, ZooKeeper te ayuda a crear aplicaciones distribuidas.
Cómo funciona
Puede describir ZooKeeper como un servicio de sincronización replicado con consistencia eventual. Es robusto, ya que los datos persistentes se distribuyen entre múltiples nodos (este conjunto de nodos se denomina "conjunto") y un cliente se conecta a cualquiera de ellos (es decir, un "servidor" específico), migrando si falla un nodo; Mientras la mayoría estricta de los nodos esté funcionando, el conjunto de nodos ZooKeeper está vivo. En particular, un nodo maestro se elige dinámicamente por consenso dentro del conjunto; Si el nodo maestro falla, la función de maestro migra a otro nodo.
Cómo se manejan las escrituras
El maestro es la autoridad para las escrituras: de esta manera se puede garantizar que las escrituras persistan en orden, es decir, las escrituras son lineales . Cada vez que un cliente escribe en el conjunto, la mayoría de los nodos conservan la información: estos nodos incluyen el servidor para el cliente y, obviamente, el maestro. Esto significa que cada escritura actualiza el servidor con el maestro. Sin embargo, también significa que no puede tener escrituras concurrentes.
La garantía de las escrituras lineales es la razón del hecho de que ZooKeeper no funciona bien para las cargas de trabajo dominantes de escritura. En particular, no debe usarse para el intercambio de datos de gran tamaño, como los medios. Siempre que su comunicación implique datos compartidos, ZooKeeper lo ayudará. Cuando los datos se pueden escribir simultáneamente, ZooKeeper realmente se interpone en el camino, porque impone un orden estricto de las operaciones, incluso si no es estrictamente necesario desde la perspectiva de los escritores. Su uso ideal es para la coordinación, donde se intercambian mensajes entre los clientes.
Cómo se manejan las lecturas
Aquí es donde sobresale ZooKeeper: las lecturas son concurrentes ya que son atendidas por el servidor específico al que se conecta el cliente. Sin embargo, esta es también la razón de la consistencia eventual: la "vista" de un cliente puede estar desactualizada, ya que el maestro actualiza el servidor correspondiente con un retraso limitado pero indefinido.
En detalle
La base de datos replicada de ZooKeeper comprende un árbol de znodes , que son entidades que representan aproximadamente nodos del sistema de archivos (piense en ellos como directorios). Cada znode puede enriquecerse con una matriz de bytes, que almacena datos. Además, cada znode puede tener otros znodes debajo, formando prácticamente un sistema de directorio interno.
Znodes secuenciales
Curiosamente, el nombre de un znode puede ser secuencial , lo que significa que el nombre que proporciona el cliente al crear el znode es solo un prefijo: el nombre completo también viene dado por un número secuencial elegido por el conjunto. Esto es útil, por ejemplo, para fines de sincronización: si varios clientes desean bloquear un recurso, cada uno puede crear simultáneamente un znode secuencial en una ubicación: el que obtenga el número más bajo tiene derecho al bloqueo.
Znodes efímeros
Además, un znode puede ser efímero : esto significa que se destruye tan pronto como el cliente que lo creó se desconecta. Esto es principalmente útil para saber cuándo falla un cliente, lo que puede ser relevante cuando el cliente mismo tiene responsabilidades que debe asumir un nuevo cliente. Tomando el ejemplo del bloqueo, tan pronto como el cliente que tiene el bloqueo se desconecta, los otros clientes pueden verificar si tienen derecho al bloqueo.
Relojes
El ejemplo relacionado con la desconexión del cliente puede ser problemático si necesitáramos sondear periódicamente el estado de znodes. Afortunadamente, ZooKeeper ofrece un sistema de eventos donde se puede configurar un reloj en un znode. Estos relojes pueden configurarse para desencadenar un evento si el znode se cambia o elimina específicamente o si se crean nuevos niños debajo de él. Esto es claramente útil en combinación con las opciones secuenciales y efímeras para znodes.
Dónde y cómo usarlo
Un ejemplo canónico del uso de Zookeeper es el cálculo de memoria distribuida, donde algunos datos se comparten entre los nodos del cliente y se debe acceder / actualizar de una manera muy cuidadosa para tener en cuenta la sincronización.
ZooKeeper ofrece la biblioteca para construir sus primitivas de sincronización, mientras que la capacidad de ejecutar un servidor distribuido evita el problema de punto único de falla que tiene cuando usa un repositorio de mensajes centralizado (similar a un intermediario).
ZooKeeper es una característica de la luz, lo que significa que los mecanismos como la elección del líder, cerraduras, barreras, etc., todavía no están presentes, pero se pueden escribir por encima de las primitivas ZooKeeper. Si la API de C / Java es demasiado difícil de manejar para sus propósitos, debe confiar en las bibliotecas creadas en ZooKeeper, como las jaulas y especialmente el curador .
Donde leer mas
Aparte de la documentación oficial, que es bastante buena, sugiero leer el Capítulo 14 de Hadoop: La guía definitiva que tiene ~ 35 páginas que explican esencialmente lo que hace ZooKeeper, seguido de un ejemplo de un servicio de configuración.