mirrors - Explicando Apache ZooKeeper
zookeeper apache download (4)
En pocas palabras, ZooKeeper te ayuda a construir 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 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; Mientras la mayoría estricta de los nodos estén 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, 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 se conserven 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. También significa, sin embargo, que no puede tener escrituras simultáneas.
La garantía de 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 utilizarse para el intercambio de datos grandes, como los medios de comunicación. Mientras su comunicación involucre datos compartidos, ZooKeeper le ayuda. Cuando los datos se pueden escribir simultáneamente, ZooKeeper realmente se interpone en el camino, ya que impone un ordenamiento estricto de las operaciones, aunque no sea estrictamente necesario desde la perspectiva de los escritores. Su uso ideal es para la coordinación, donde los mensajes se intercambian entre los clientes.
Cómo se manejan las lecturas
Aquí es donde ZooKeeper sobresale: las lecturas son concurrentes, ya que son servidas por el servidor específico al que se conecta el cliente. Sin embargo, este es también el motivo de la eventual coherencia: la "vista" de un cliente puede estar desactualizada, ya que el maestro actualiza el servidor correspondiente con un retraso limitado pero no definido.
En detalle
La base de datos replicada de ZooKeeper comprende un árbol de znodos , que son entidades que representan aproximadamente los nodos del sistema de archivos (piense en ellos como directorios). Cada znodo puede enriquecerse mediante una matriz de bytes, que almacena datos. Además, cada znodo puede tener otros znodos debajo de él, prácticamente formando un sistema de directorio interno.
Znodos 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 obtener un bloqueo en un recurso, cada uno puede crear simultáneamente un znode secuencial en una ubicación: quien obtenga el número más bajo tiene derecho al bloqueo.
Znodos 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 propio cliente tiene responsabilidades que deben ser asumidas por 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 necesitamos sondear periódicamente el estado de los znodos. 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 se crean nuevos hijos debajo de él. Esto es claramente útil en combinación con las opciones secuenciales y efímeras para los znodos.
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 nodos de clientes y se debe acceder / actualizar de 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 agente).
ZooKeeper es una característica de la luz, lo que significa que los mecanismos como la elección del líder, las cerraduras, las barreras, etc. ya 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 cages y especialmente el curator .
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 contiene ~ 35 páginas que explican esencialmente lo que hace ZooKeeper, seguido de un ejemplo de un servicio de configuración.
Estoy tratando de entender ZooKeeper, cómo funciona y qué hace. ¿Hay alguna aplicación que sea comparable a ZooKeeper?
Si lo sabes, ¿cómo describirías a ZooKeeper a un lego?
He intentado apache wiki, zookeeper sourceforge ... pero todavía no puedo relacionarme con él.
Acabo de leer en http://zookeeper.sourceforge.net/index.sf.shtml , ¿no hay más servicios como este? ¿Es tan simple como replicar un servicio de servidor?
Entiendo el ZooKeeper en general, pero tuve problemas con los términos "quórum" y "cerebro dividido", así que tal vez pueda compartir mis hallazgos con usted (también me considero un lego).
Digamos que tenemos un clúster de ZooKeeper de 5 servidores. Uno de los servidores se convertirá en el líder y los otros en seguidores.
Estos 5 servidores forman un quórum. Quórum simplemente significa "estos servidores pueden votar sobre quién debe ser el líder".
Así que la votación se basa en la mayoría. La mayoría simplemente significa "más de la mitad", por lo que más de la mitad de la cantidad de servidores debe aceptar que un servidor específico se convierta en el líder.
Entonces, hay algo malo que puede suceder que se llama "cerebro dividido". Un cerebro dividido es simplemente esto, por lo que yo entiendo: el grupo 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 preferir? Podrían haber recibido información diferente de los clientes. Por lo tanto, es realmente importante saber qué "equipo del servidor" sigue siendo relevante y cuál puede / debe ignorarse.
La mayoría es también la razón por la que debe usar un número impar de servidores. Si tiene 4 servidores y un cerebro dividido en el que los 2 servidores están separados, entonces ambos "equipos de servidores" podrían decir "hey, ¡queremos decidir quién es el líder!" ¿Pero cómo debes decidir qué 2 servidores debes 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 aceptar que uno de ellos se convertirá en el nuevo líder.
Me doy cuenta de que una vez que lo piensas y entiendes los términos, ya no es tan complicado. Espero que esto también ayude a cualquiera a entender estos términos.
Zookeeper es un servidor de código abierto centralizado para mantener y administrar información de configuración, convenciones de nomenclatura y sincronización para el entorno de clúster distribuido. Zookeeper ayuda a los sistemas distribuidos a reducir su complejidad de administración al proporcionar baja latencia y alta disponibilidad. Zookeeper fue inicialmente un subproyecto para Hadoop, pero ahora es un proyecto independiente de primer nivel de Apache Software Foundation.
Zookeeper es uno de los mejores servidores y servicios de código abierto que ayuda a coordinar de manera confiable los procesos distribuidos. Zookeeper es un sistema CP (Consulte el teorema de CAP) que proporciona tolerancia de consistencia y 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 elegido 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 del blog, ejemplos de la API de Java de Zookeeper , tiene algunos ejemplos si está buscando ejemplos.
Entonces, ¿dónde usamos esto? Si su servicio distribuido necesita una gestión de configuración, bloqueos, colas, etc. centralizada, confiable y consistente, encontrará en Zookeeper una opción confiable.