Saltar al contenido

Explicando Apache ZooKeeper

Nuestro team de especialistas despúes de algunos días de investigación y recopilar de información, dimos con la solución, deseamos que todo este artículo sea de gran utilidad en tu proyecto.

Solución:

En pocas palabras, ZooKeeper le ayuda a crear aplicaciones distribuidas.

Cómo funciona

Puede describir a ZooKeeper como un servicio de sincronización replicado con consistencia eventual. Es robusto, ya que los datos persistentes se distribuyen entre varios 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; siempre que la mayoría estricta de los nodos esté funcionando, el conjunto de nodos de ZooKeeper estará vivo. En particular, un nodo maestro se elige dinámicamente por consenso dentro del conjunto; si el nodo maestro falla, el rol 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 se conserven en orden, es decir, las escrituras son lineal. Cada vez que un cliente escribe en el conjunto, la mayoría de los nodos conservan la información: estos nodos incluyen el servidor del 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 simultáneas.

La garantía de escrituras lineales es la razón por la que ZooKeeper no funciona bien para cargas de trabajo dominantes en escritura. En particular, no debe usarse para el intercambio de datos grandes, como medios. Siempre que su comunicación involucre datos compartidos, ZooKeeper lo ayuda. Cuando se pueden escribir datos al mismo tiempo, ZooKeeper se interpone en el camino, porque impone un orden estricto de 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 eventual consistencia: la “vista” de un cliente puede estar desactualizada, ya que el maestro actualiza el servidor correspondiente con un retraso acotado pero indefinido.

En detalle

La base de datos replicada de ZooKeeper comprende un árbol de znodes, que son entidades que representan aproximadamente los nodos del sistema de archivos (piense en ellos como directorios). Cada znode puede enriquecerse con un byte array, que almacena datos. Además, cada znode puede tener otros znode 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 prefix: 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 obtener un bloqueo en un recurso, cada uno de ellos puede crear simultáneamente un znode secuencial en una ubicación: quien 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 deberían ser asumidas por un nuevo cliente. Tomando el ejemplo de la cerradura, tan pronto como el cliente que tiene la cerradura se desconecta, los otros clientes pueden verificar si tienen derecho a la cerradura.

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 un mirar se puede configurar 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 hijos debajo de él. Esto es claramente útil en combinación con las opciones secuenciales y efímeras para znodes.

Donde y como 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 tiene funciones ligeras, lo que significa que los mecanismos como la elección de líder, bloqueos, barreras, etc. no están presentes, pero se pueden escribir sobre las primitivas de 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.

Dónde leer más

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.


Zookeeper es uno de los mejores abiertos servidor de origen y servicio que ayuda a coordinar de manera confiable los procesos distribuidos. Zookeeper es un sistema de CP (consulte el teorema de CAP) que proporciona consistencia y tolerancia a la partición. La replicación del estado de Zookeeper en todos los nodos lo convierte en un servicio distribuido finalmente consistente.

Además, cualquier líder recién electo actualizará a sus seguidores con propuestas faltantes o con una instantánea del estado, si a los seguidores les faltan muchas propuestas.

Zookeeper también proporciona una API que es muy fácil de usar. Esta publicación de blog, Ejemplos de API de Java de Zookeeper, tiene algunos ejemplos si está buscando ejemplos.

Entonces, ¿dónde usamos esto? Si su servicio distribuido necesita una administración de configuración, bloqueos, colas, etc. centralizada, confiable y consistente, encontrará que Zookeeper es una opción confiable.

Entiendo al ZooKeeper en general, pero tuve problemas con los términos “quórum” y “cerebro dividido”, así que tal vez pueda compartir mis hallazgos con ustedes (me considero también un lego).

Digamos que tenemos un clúster de ZooKeeper de 5 servidores. Uno de los servidores se convertirá en líder y los demás en seguidores.

  • Estos 5 servidores forman un quórum. Quórum simplemente significa “estos servidores pueden votar sobre quién debería ser el líder”.

  • Entonces, la votación se basa en la mayoría. Mayoría simplemente significa “más de la mitad”, por lo que más de la mitad del número de servidores debe estar de acuerdo para que un servidor específico se convierta en el líder.

  • Entonces, existe esta cosa mala que puede suceder llamada “cerebro dividido”. Un cerebro dividido es simplemente esto, hasta donde tengo entendido: el clúster de 5 servidores se divide en dos partes, o llamémoslo “equipos de servidores”, con quizás una parte de 2 y la otra de 3 servidores. Esta es realmente una mala situación, ya que si ambos “equipos de servidores” deben ejecutar una orden específica, ¿cómo decidiría qué equipo debería preferirse? Es posible que hayan recibido información diferente de los clientes. Por lo tanto, es realmente importante saber qué “equipo de servidores” sigue siendo relevante y cuál puede / debe ignorarse.

  • La mayoría es también la razón por la que debería utilizar un número impar de servidores. Si tiene 4 servidores y un cerebro dividido donde 2 servidores se separan, ambos “equipos de servidores” podrían decir “¡Oye, queremos decidir quién es el líder!” pero, ¿cómo decidir qué 2 servidores elegir? Con 5 servidores es simple: el equipo de servidores con 3 servidores tiene la mayoría y puede seleccionar al nuevo líder.

  • Incluso si solo tiene 3 servidores y uno de ellos falla, los otros 2 aún forman la mayoría y pueden estar de acuerdo en que uno de ellos se convertirá en el nuevo líder.

Me doy cuenta de que una vez que lo piensas un poco y entiendes los términos, ya no es tan complicado. Espero que esto también ayude a cualquiera a comprender estos términos.

valoraciones y comentarios

Si conservas alguna sospecha y forma de acrecentar nuestro enunciado eres capaz de escribir una reseña y con deseo lo leeremos.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *