Le sugiero que lea la transcripción de la conferencia "Hadoop. ZooKeeper" de la serie "Métodos para el procesamiento distribuido de grandes volúmenes de datos en Hadoop".
Qué es ZooKeeper, su lugar en el ecosistema Hadoop. Mentiras sobre la computación distribuida. Diagrama de un sistema distribuido estándar. Dificultad para coordinar sistemas distribuidos. Problemas típicos de coordinación. Los principios detrás del diseño de ZooKeeper. Modelo de datos de ZooKeeper. banderas de nodo. Sesiones. API de cliente. Primitivas (configuración, pertenencia a grupos, cerraduras simples, elección de líder, cerraduras sin efecto rebaño). Arquitectura de ZooKeeper. Base de datos ZooKeeper. ZAB. Controlador de solicitudes.
Hoy hablaremos de ZooKeeper. Esto es muy útil. Como cualquier producto Apache Hadoop, tiene un logotipo. Representa a un hombre.
Antes de esto, hablamos principalmente sobre cómo se pueden procesar los datos allí, cómo almacenarlos, es decir, cómo usarlos de alguna manera y trabajar con ellos de alguna manera. Y hoy me gustaría hablar un poco sobre la creación de aplicaciones distribuidas. Y ZooKeeper es una de esas cosas que te permite simplificar este asunto. Este es un tipo de servicio que está destinado a algún tipo de coordinación de la interacción de procesos en sistemas distribuidos, en aplicaciones distribuidas.
La necesidad de este tipo de aplicaciones es cada día mayor, de eso se trata nuestro curso. Por un lado, MapReduce y este marco listo para usar le permiten nivelar esta complejidad y liberar al programador de escribir primitivos como la interacción y la coordinación de procesos. Pero, por otro lado, nadie garantiza que esto no tenga que hacerse de todos modos. MapReduce u otros marcos ya preparados no siempre reemplazan por completo algunos casos que no se pueden implementar con este. Incluyendo el propio MapReduce y muchos otros proyectos de Apache; de hecho, también son aplicaciones distribuidas. Y para facilitar la escritura, escribieron ZooKeeper.
Como todas las aplicaciones relacionadas con Hadoop, fue desarrollada por Yahoo! Ahora también es una aplicación oficial de Apache. No está tan desarrollado activamente como HBase. Si vas a JIRA HBase, todos los días hay un montón de informes de errores, un montón de propuestas para optimizar algo, es decir, la vida en el proyecto continúa constantemente. Y ZooKeeper, por un lado, es un producto relativamente simple y, por otro lado, esto garantiza su confiabilidad. Y es bastante fácil de usar, por lo que se ha convertido en un estándar en aplicaciones dentro del ecosistema Hadoop. Entonces pensé que sería útil revisarlo para entender cómo funciona y cómo usarlo.
Esta es una foto de una conferencia que tuvimos. Podemos decir que es ortogonal a todo lo que hemos considerado hasta ahora. Y todo lo que aquí se indica, en un grado u otro, funciona con ZooKeeper, es decir, es un servicio que utiliza todos estos productos. Ni HDFS ni MapReduce escriben sus propios servicios similares que funcionen específicamente para ellos. En consecuencia, se utiliza ZooKeeper. Y esto simplifica el desarrollo y algunas cosas relacionadas con los errores.
¿De dónde viene todo esto? Parecería que lanzamos dos aplicaciones en paralelo en diferentes computadoras, las conectamos con una cuerda o en una malla y todo funciona. Pero el problema es que la Red no es confiable, y si huele el tráfico o observa lo que sucede allí en un nivel bajo, cómo interactúan los clientes en la Red, a menudo puede ver que algunos paquetes se pierden o se reenvían. No en vano se inventaron los protocolos TCP, que permiten establecer una determinada sesión y garantizar la entrega de mensajes. Pero en cualquier caso, ni siquiera TCP puede salvarte siempre. Todo tiene un tiempo de espera. Es posible que la red simplemente se caiga por un tiempo. Puede que simplemente parpadee. Y todo esto lleva al hecho de que no se puede confiar en que la Red sea confiable. Esta es la principal diferencia con escribir aplicaciones paralelas que se ejecutan en una computadora o en una supercomputadora, donde no hay red, donde hay un bus de intercambio de datos más confiable en la memoria. Y ésta es una diferencia fundamental.
Entre otras cosas, al utilizar la Red siempre hay una cierta latencia. El disco también lo tiene, pero la Red tiene más. La latencia es un tiempo de retraso, que puede ser pequeño o bastante significativo.
La topología de la red está cambiando. ¿Qué es la topología? Esta es la ubicación de nuestro equipo de red. Hay centros de datos, hay bastidores allí, hay velas. Todo esto se puede volver a conectar, mover, etc. Todo esto también debe tenerse en cuenta. Los nombres de IP cambian, la ruta por la que viaja nuestro tráfico cambia. Esto también hay que tenerlo en cuenta.
La red también puede cambiar en términos de equipamiento. En la práctica, puedo decir que a nuestros ingenieros de redes les gusta mucho actualizar periódicamente algo sobre las velas. De repente apareció un nuevo firmware y no estaban particularmente interesados en algún clúster de Hadoop. Tienen su propio trabajo. Para ellos lo principal es que la Red funcione. En consecuencia, quieren volver a cargar algo allí, actualizar su hardware y el hardware también cambia periódicamente. Todo esto hay que tenerlo en cuenta de alguna manera. Todo esto afecta a nuestra aplicación distribuida.
Por lo general, las personas que empiezan a trabajar con grandes cantidades de datos, por alguna razón, creen que Internet es ilimitado. Si hay un archivo de varios terabytes allí, puede llevarlo a su servidor o computadora y abrirlo usando gato y ver. Otro error está en Empuje mira los registros. Nunca hagas esto porque es malo. Porque Vim intenta almacenar todo en el buffer, cargar todo en la memoria, especialmente cuando comenzamos a movernos por este registro y buscar algo. Son cosas que se olvidan, pero que vale la pena considerar.
Es más fácil escribir un programa que se ejecute en una computadora con un procesador.
Cuando nuestro sistema crezca, queremos paralelizarlo todo, y paralelizarlo no solo en una computadora, sino también en un clúster. Surge la pregunta: ¿cómo coordinar este asunto? Es posible que nuestras aplicaciones ni siquiera interactúen entre sí, pero ejecutamos varios procesos en paralelo en varios servidores. ¿Y cómo vigilar que todo les vaya bien? Por ejemplo, envían algo por Internet. Deben escribir sobre su estado en algún lugar, por ejemplo, en algún tipo de base de datos o registro, luego agregar este registro y luego analizarlo en algún lugar. Además, debemos tener en cuenta que el proceso estaba funcionando y funcionando, de repente apareció algún error o falló, entonces, ¿qué tan rápido nos enteraremos?
Está claro que todo esto se puede controlar rápidamente. Esto también es bueno, pero el monitoreo es algo limitado que le permite monitorear algunas cosas al más alto nivel.
Cuando queremos que nuestros procesos comiencen a interactuar entre sí, por ejemplo, para enviarse algunos datos, también surge la pregunta: ¿cómo sucederá esto? ¿Habrá algún tipo de condición de carrera, se sobrescribirán entre sí, los datos llegarán correctamente, se perderá algo en el camino? Necesitamos desarrollar algún tipo de protocolo, etc.
La coordinación de todos estos procesos no es algo baladí. Y obliga al desarrollador a bajar a un nivel aún más bajo y escribir sistemas desde cero o no desde cero, pero esto no es tan simple.
Si se le ocurre un algoritmo criptográfico o incluso lo implementa, deséchelo inmediatamente, porque lo más probable es que no le funcione. Lo más probable es que contenga un montón de errores que olvidó proporcionar. Nunca lo uses para nada serio porque lo más probable es que quede inestable. Porque todos los algoritmos que existen han sido probados por el tiempo durante muchísimo tiempo. Está molestado por la comunidad. Este es un tema aparte. Y aquí ocurre lo mismo. Si es posible no implementar algún tipo de sincronización de procesos usted mismo, entonces es mejor no hacerlo, porque es bastante complicado y lo lleva por el camino inestable de la búsqueda constante de errores.
Hoy hablamos de ZooKeeper. Por un lado es un framework, por otro lado es un servicio que facilita la vida al desarrollador y simplifica al máximo la implementación de la lógica y la coordinación de nuestros procesos.
Recordemos cómo sería un sistema distribuido estándar. De esto es de lo que hablamos: HDFS, HBase. Existe un proceso maestro que gestiona los procesos trabajadores y esclavos. Es el responsable de coordinar y distribuir tareas, reiniciar trabajadores, lanzar nuevos y distribuir la carga.
Una cosa más avanzada es el Servicio de Coordinación, es decir, mover la tarea de coordinación en sí a un proceso separado, además de ejecutar algún tipo de Maestro de respaldo o de reserva en paralelo, porque el Maestro puede fallar. Y si el Maestro cae, entonces nuestro sistema no funcionará. Estamos ejecutando una copia de seguridad. Algunos estados indican que el maestro debe replicarse en una copia de seguridad. Esto también puede confiarse al Servicio de Coordinación. Pero en este diagrama el propio Maestro es el responsable de coordinar a los trabajadores, aquí el servicio es el que coordina las actividades de replicación de datos.
Una opción más avanzada es cuando toda la coordinación la realiza nuestro servicio, como se hace habitualmente. Él asume la responsabilidad de asegurarse de que todo funcione. Y si algo no funciona, lo averiguamos e intentamos solucionar esta situación. En cualquier caso nos quedamos con un Maestro que de alguna manera interactúa con los esclavos y puede enviar datos, información, mensajes, etc. a través de algún servicio.
Existe un esquema aún más avanzado, cuando no tenemos un Maestro, todos los nodos son maestros esclavos, diferentes en su comportamiento. Pero todavía necesitan interactuar entre sí, por lo que todavía queda algún servicio para coordinar estas acciones. Probablemente, Cassandra, que trabaja según este principio, se ajuste a este esquema.
Es difícil decir cuál de estos esquemas funciona mejor. Cada uno tiene sus pros y sus contras.
Y no hay necesidad de tener miedo de algunas cosas con el Maestro, porque, como muestra la práctica, él no es tan susceptible a servir constantemente. Lo principal aquí es elegir la solución adecuada para alojar este servicio en un nodo potente separado, de modo que tenga suficientes recursos, de modo que, si es posible, los usuarios no tengan acceso allí, para que no interrumpan accidentalmente este proceso. Pero al mismo tiempo, en un esquema de este tipo es mucho más fácil gestionar a los trabajadores del proceso Maestro, es decir, este esquema es más simple desde el punto de vista de la implementación.
Y este esquema (arriba) es probablemente más complejo, pero más confiable.
El principal problema son los fallos parciales. Por ejemplo, cuando enviamos un mensaje a través de la Red, ocurre algún tipo de accidente, y quien envió el mensaje no sabrá si su mensaje fue recibido y qué sucedió por parte del receptor, no sabrá si el mensaje fue procesado correctamente. , es decir, no recibirá ninguna confirmación.
En consecuencia, debemos procesar esta situación. Y lo más sencillo es reenviar este mensaje y esperar hasta recibir respuesta. En este caso, no se tiene en cuenta si ha cambiado el estado del receptor. Es posible que enviemos un mensaje y agreguemos los mismos datos dos veces.
ZooKeeper ofrece formas de afrontar este tipo de rechazos, lo que también nos hace la vida más fácil.
Como se mencionó un poco antes, esto es similar a escribir programas multiproceso, pero la principal diferencia es que en las aplicaciones distribuidas que construimos en diferentes máquinas, la única forma de comunicarnos es la Red. Básicamente, se trata de una arquitectura sin compartir nada. Cada proceso o servicio que se ejecuta en una máquina tiene su propia memoria, su propio disco, su propio procesador, que no comparte con nadie.
Si escribimos un programa multiproceso en una computadora, entonces podemos usar la memoria compartida para intercambiar datos. Tenemos un cambio de contexto allí, los procesos pueden cambiar. Esto afecta el rendimiento. Por un lado, no existe tal cosa en el programa en un clúster, pero hay problemas con la red.
En consecuencia, los principales problemas que surgen al escribir sistemas distribuidos son la configuración. Estamos escribiendo algún tipo de solicitud. Si es simple, entonces codificamos todo tipo de números en el código, pero esto es un inconveniente, porque si decidimos que en lugar de un tiempo de espera de medio segundo queremos un tiempo de espera de un segundo, entonces necesitamos recompilar la aplicación y desplegar todo de nuevo. Una cosa es cuando está en una máquina, cuando puedes simplemente reiniciarlo, pero cuando tenemos muchas máquinas, tenemos que copiar todo constantemente. Debemos intentar que la aplicación sea configurable.
Aquí estamos hablando de configuración estática para procesos del sistema. Esto no es del todo, tal vez desde el punto de vista del sistema operativo, puede ser una configuración estática para nuestros procesos, es decir, esta es una configuración que no se puede tomar y actualizar simplemente.
También hay una configuración dinámica. Estos son los parámetros que queremos cambiar sobre la marcha para que se recojan allí.
¿Cuál es el problema aquí? Actualizamos la configuración, la implementamos, ¿y qué? El problema puede ser que, por un lado, implementamos la configuración, pero nos olvidamos de la novedad, la configuración permaneció allí. En segundo lugar, mientras estábamos implementando, la configuración se actualizó en algunos lugares, pero no en otros. Y algunos procesos de nuestra aplicación que se ejecutan en una máquina se reiniciaron con una nueva configuración y en algún lugar con una antigua. Esto puede hacer que nuestra aplicación distribuida sea inconsistente desde una perspectiva de configuración. Este problema es común. Para una configuración dinámica, es más relevante porque implica que se puede cambiar sobre la marcha.
Otro problema es la pertenencia a un grupo. Siempre tenemos algún grupo de trabajadores, siempre queremos saber cuál de ellos está vivo y cuál está muerto. Si hay un Maestro, entonces debe comprender qué trabajadores pueden ser redirigidos a los clientes para que realicen cálculos o trabajen con datos y cuáles no. Un problema que surge constantemente es que necesitamos saber quién está trabajando en nuestro clúster.
Otro problema típico son las elecciones de líderes, cuando queremos saber quién está a cargo. Un ejemplo es la replicación, cuando tenemos algún proceso que recibe operaciones de escritura y luego las replica entre otros procesos. Él será el líder, todos los demás le obedecerán, le seguirán. Es necesario elegir un proceso que sea inequívoco para todos, para que no resulte que se seleccionen dos líderes.
También existe un acceso mutuamente excluyente. El problema aquí es más complejo. Existe un mutex cuando se escriben programas multiproceso y se desea que el acceso a algún recurso, por ejemplo, una celda de memoria, esté limitado y realizado por un solo subproceso. Aquí el recurso podría ser algo más abstracto. Y las diferentes aplicaciones de diferentes nodos de nuestra Red solo deben recibir acceso exclusivo a un recurso determinado, y no para que todos puedan cambiarlo o escribir algo allí. Estas son las llamadas cerraduras.
ZooKeeper te permite resolver todos estos problemas en un grado u otro. Y mostraré con ejemplos cómo te permite hacer esto.
No hay primitivas de bloqueo. Cuando empezamos a usar algo, esta primitiva no esperará a que ocurra ningún evento. Lo más probable es que esto funcione de forma asincrónica, lo que permitirá que los procesos no se cuelguen mientras esperan algo. Esto es algo muy útil.
Todas las solicitudes de los clientes se procesan en el orden de la cola general.
Y los clientes tienen la oportunidad de recibir notificaciones sobre cambios en algún estado, sobre cambios en los datos, antes de que el cliente vea los datos modificados.
ZooKeeper puede funcionar en dos modos. El primero es independiente, en un nodo. Esto es conveniente para realizar pruebas. También puede funcionar en modo clúster en cualquier número de servidores. Si tenemos un cluster de 100 máquinas, entonces no es necesario que funcione en 100 máquinas. Basta con seleccionar varias máquinas donde pueda ejecutar ZooKeeper. Y profesa el principio de alta disponibilidad. En cada instancia en ejecución, ZooKeeper almacena una copia completa de los datos. Más adelante os contaré cómo lo hace. No fragmenta datos ni los particiona. Por un lado, la desventaja es que no podemos almacenar mucho, por otro lado, no es necesario hacerlo. No está diseñado para eso, no es una base de datos.
Los datos se pueden almacenar en caché en el lado del cliente. Este es un principio estándar para no interrumpir el servicio y no cargarlo con las mismas solicitudes. Un cliente inteligente normalmente lo sabe y lo almacena en caché.
Por ejemplo, algo ha cambiado aquí. Hay algún tipo de aplicación. Se eligió un nuevo líder, que es responsable, por ejemplo, de procesar las operaciones de escritura. Y queremos replicar los datos. Una solución es ponerlo en un bucle. Y constantemente cuestionamos nuestro servicio: ¿ha cambiado algo? La segunda opción es más óptima. Este es un mecanismo de vigilancia que le permite notificar a los clientes que algo ha cambiado. Este es un método menos costoso en términos de recursos y más conveniente para los clientes.
El cliente es el usuario que utiliza ZooKeeper.
El servidor es el proceso de ZooKeeper en sí.
Znode es la clave en ZooKeeper. ZooKeeper almacena todos los znodes en la memoria y los organiza en forma de diagrama jerárquico, en forma de árbol.
Hay dos tipos de operaciones. La primera es actualizar/escribir, cuando alguna operación cambia el estado de nuestro árbol. El árbol es común.
Y es posible que el cliente no complete una solicitud y se desconecte, pero pueda establecer una sesión a través de la cual interactúa con ZooKeeper.
El modelo de datos de ZooKeeper se parece a un sistema de archivos. Hay una raíz estándar y luego recorrimos los directorios que van desde la raíz. Y luego el catálogo del primer nivel, segundo nivel. Todo esto es znodes.
Cada znode puede almacenar algunos datos, normalmente no muy grandes, por ejemplo, 10 kilobytes. Y cada znode puede tener una cierta cantidad de hijos.
Los Znodes vienen en varios tipos. Se pueden crear. Y al crear un znode, especificamos el tipo al que debe pertenecer.
Hay dos tipos. La primera es la bandera efímera. Znode vive dentro de una sesión. Por ejemplo, el cliente ha establecido una sesión. Y mientras esta sesión esté viva, existirá. Esto es necesario para no producir algo innecesario. Esto también es adecuado para momentos en los que es importante para nosotros almacenar datos primitivos dentro de una sesión.
El segundo tipo es la bandera secuencial. Incrementa el contador en el camino hacia el znode. Por ejemplo, teníamos un directorio con la aplicación 1_5. Y cuando creamos el primer nodo, recibió p_1, el segundo - p_2. Y cuando llamamos a este método cada vez, pasamos la ruta completa, indicando solo una parte de la ruta, y este número se incrementa automáticamente porque indicamos el tipo de nodo: secuencial.
Nodo normal. Ella siempre vivirá y tendrá el nombre que le digamos.
Otra cosa útil es la bandera de vigilancia. Si lo instalamos, el cliente puede suscribirse a algunos eventos para un nodo específico. Más adelante te mostraré con un ejemplo cómo se hace esto. El propio ZooKeeper notifica al cliente que los datos en el nodo han cambiado. Sin embargo, las notificaciones no garantizan que hayan llegado algunos datos nuevos. Simplemente dicen que algo ha cambiado, por lo que aún tendrás que comparar los datos más adelante con llamadas separadas.
Y como ya dije, el orden de los datos está determinado por kilobytes. No es necesario almacenar datos de texto grandes allí, porque no es una base de datos, es un servidor de coordinación de acciones.
Te cuento un poco sobre las sesiones. Si tenemos varios servidores, podemos pasar de forma transparente de un servidor a otro utilizando el identificador de sesión. Es bastante conveniente.
Cada sesión tiene algún tipo de tiempo de espera. Una sesión se define en función de si el cliente envía algo al servidor durante esa sesión. Si no transmitió nada durante el tiempo de espera, la sesión se interrumpe o el cliente puede cerrarla él mismo.
No tiene tantas funciones, pero puedes hacer diferentes cosas con esta API. Esa llamada que vimos crear crea un znode y toma tres parámetros. Esta es la ruta al znode y debe especificarse en su totalidad desde la raíz. Y también estos son algunos datos que queremos transferir allí. Y el tipo de bandera. Y después de la creación devuelve la ruta al znode.
En segundo lugar, puedes eliminarlo. El truco aquí es que el segundo parámetro, además de la ruta al znode, puede especificar la versión. En consecuencia, ese znode se eliminará si la versión que transferimos es equivalente a la que realmente existe.
Si no queremos comprobar esta versión, simplemente pasamos el argumento "-1".
En tercer lugar, comprueba la existencia de un znode. Devuelve verdadero si el nodo existe; falso en caso contrario.
Y luego aparece Flag Watch, que le permite monitorear este nodo.
Puede configurar este indicador incluso en un nodo inexistente y recibir una notificación cuando aparezca. Esto también puede resultar útil.
Un par de desafíos más son obtener datos. Está claro que podemos recibir datos a través de znode. También puedes utilizar la vigilancia de banderas. En este caso, no se instalará si no hay ningún nodo. Por lo tanto, es necesario comprender que existe y luego recibir datos.
También hay SetData. Aquí pasamos versión. Y si transmitimos esto, se actualizarán los datos del znode de una determinada versión.
También puede especificar "-1" para excluir esta verificación.
Otro método útil es obtener niños. También podemos obtener una lista de todos los znodes que le pertenecen. Podemos monitorear esto configurando la vigilancia de bandera.
y metodo sincronizar permite enviar todos los cambios a la vez, garantizando así que se guarden y que todos los datos se hayan modificado por completo.
Si hacemos analogías con la programación normal, entonces cuando usa métodos como escribir, que escriben algo en el disco, y luego le devuelve una respuesta, no hay garantía de que haya escrito los datos en el disco. E incluso cuando el sistema operativo confía en que todo ha sido escrito, existen mecanismos en el propio disco donde el proceso pasa a través de capas de buffers, y solo después de eso los datos se colocan en el disco.
Se utilizan principalmente llamadas asincrónicas. Esto permite al cliente trabajar en paralelo con diferentes solicitudes. Puede utilizar el enfoque sincrónico, pero es menos productivo.
Las dos operaciones de las que hablamos son actualización/escritura, que cambian datos. Estos son crear, configurar datos, sincronizar y eliminar. Y la lectura existe, getData, getChildren.
Ahora algunos ejemplos de cómo se pueden crear primitivas para trabajar en un sistema distribuido. Por ejemplo, relacionado con la configuración de algo. Ha aparecido un nuevo trabajador. Agregamos la máquina y comenzamos el proceso. Y hay las siguientes tres preguntas. ¿Cómo consulta ZooKeeper para la configuración? Y si queremos cambiar la configuración ¿cómo la cambiamos? Y después de que lo cambiamos, ¿cómo lo obtienen esos trabajadores que teníamos?
ZooKeeper hace esto relativamente fácil. Por ejemplo, está nuestro árbol znode. Aquí hay un nodo para nuestra aplicación, creamos un nodo adicional en él, que contiene datos de la configuración. Estos pueden o no ser parámetros separados. Dado que el tamaño es pequeño, el tamaño de la configuración suele ser también pequeño, por lo que es muy posible almacenarlo aquí.
Estás usando el método obtener datos para obtener la configuración para el trabajador del nodo. Establecer en verdadero. Si por algún motivo este nodo no existe, se nos informará cuando aparezca, o cuando cambie. Si queremos saber que algo ha cambiado, lo configuramos como verdadero. Y si los datos de este nodo cambian, lo sabremos.
SetData. Configuramos los datos, configuramos "-1", es decir, no verificamos la versión, asumimos que siempre tenemos una configuración, no necesitamos almacenar muchas configuraciones. Si necesita almacenar mucho, deberá agregar otro nivel. Aquí creemos que solo hay uno, por lo que actualizamos solo el último, por lo que no verificamos la versión. En este momento, todos los clientes que se hayan suscrito previamente reciben una notificación de que algo ha cambiado en este nodo. Y después de haberlo recibido, también deberá volver a solicitar los datos. La notificación es que no reciben los datos en sí, sino sólo la notificación de cambios. Luego de esto deberán solicitar nuevos datos.
La segunda opción para usar la primitiva es membresía de grupo. Tenemos una aplicación distribuida, hay un montón de trabajadores y queremos entender que están todos en su lugar. Por lo tanto, deben registrarse ellos mismos que trabajan en nuestra aplicación. Y también queremos saber, ya sea del proceso Máster o de otro lado, de todos los trabajadores activos que tenemos actualmente.
Cómo hacemos esto? Para la aplicación, creamos un nodo de trabajadores y agregamos un subnivel allí usando el método de creación. Tengo un error en la diapositiva. aqui necesitas secuencial especifique, entonces todos los trabajadores se crearán uno por uno. Y la aplicación, al solicitar todos los datos de los hijos de este nodo, recibe todos los trabajadores activos que existen.
Esta es una implementación tan terrible de cómo se puede hacer esto en código Java. Empecemos por el final, con el método principal. Esta es nuestra clase, creemos su método. Como primer argumento usamos el host, donde nos estamos conectando, es decir, lo configuramos como argumento. Y el segundo argumento es el nombre del grupo.
¿Cómo ocurre la conexión? Este es un ejemplo sencillo de la API que se utiliza. Aquí todo es relativamente sencillo. Hay un ZooKeeper de clase estándar. Le pasamos hosts. Y establezca el tiempo de espera, por ejemplo, en 5 segundos. Y tenemos un miembro llamado connectSignal. Básicamente, creamos un grupo a lo largo del camino transmitido. No escribimos datos allí, aunque se podría haber escrito algo. Y el nodo aquí es del tipo persistente. Esencialmente, este es un nodo regular que existirá todo el tiempo. Aquí es donde se crea la sesión. Esta es la implementación del propio cliente. Nuestro cliente enviará mensajes periódicos indicando que la sesión está viva. Y cuando terminamos la sesión, llamamos a cerrar y listo, la sesión se cae. Esto es por si se nos cae algo, de modo que ZooKeeper se entere y corte la sesión.
¿Cómo bloquear un recurso? Aquí todo es un poco más complicado. Tenemos un conjunto de trabajadores, hay algún recurso que queremos bloquear. Para hacer esto, creamos un nodo separado, por ejemplo, llamado lock1. Si pudimos crearlo, entonces tenemos un candado aquí. Y si no pudimos crearlo, entonces el trabajador intenta obtener getData desde aquí, y como el nodo ya se creó, entonces colocamos un observador aquí y en el momento en que el estado de este nodo cambie, lo sabremos. Y podemos intentar tener tiempo para recrearlo. Si tomamos este nodo, tomamos este candado, cuando ya no necesitemos el candado, lo abandonaremos, ya que el nodo existe solo dentro de la sesión. En consecuencia, desaparecerá. Y otro cliente, en el marco de otra sesión, podrá bloquear este nodo, o mejor dicho, recibirá una notificación de que algo ha cambiado y podrá intentar hacerlo a tiempo.
Otro ejemplo de cómo se puede elegir al líder principal. Esto es un poco más complicado, pero también relativamente sencillo. ¿Que está pasando aqui? Hay un nodo principal que agrega a todos los trabajadores. Estamos intentando obtener datos sobre el líder. Si esto sucedió con éxito, es decir, recibimos algunos datos, entonces nuestro trabajador comienza a seguir a este líder. Cree que ya hay un líder.
Si el líder murió por alguna razón, por ejemplo, se cayó, intentamos crear un nuevo líder. Y si lo logramos, nuestro trabajador se convierte en el líder. Y si alguien en este momento logró crear un nuevo líder, entonces tratamos de entender quién es y luego seguirlo.
Aquí surge el llamado efecto rebaño, es decir, el efecto rebaño, porque cuando un líder muere, el que llega primero en el tiempo se convierte en líder.
Al capturar un recurso, puede intentar utilizar un enfoque ligeramente diferente, que es el siguiente. Por ejemplo, queremos conseguir un candado, pero sin el efecto hert. Consistirá en que nuestra aplicación solicite listas de todos los ID de nodos para un nodo ya existente con un bloqueo. Y si antes de eso el nodo para el que creamos un candado es el más pequeño del conjunto que recibimos, entonces esto significa que hemos capturado el candado. Comprobamos que hemos recibido un candado. Como verificación, habrá una condición de que la identificación que recibimos al crear un nuevo candado sea mínima. Y si lo recibimos, seguiremos trabajando.
Si hay una determinada identificación que es más pequeña que nuestro bloqueo, entonces ponemos un observador en este evento y esperamos la notificación hasta que algo cambie. Es decir, recibimos este candado. Y hasta que desaparezca, no tendremos la identificación mínima y no recibiremos el bloqueo mínimo, por lo que podremos iniciar sesión. Y si no se cumple esta condición, inmediatamente vamos aquí e intentamos obtener este bloqueo nuevamente, porque algo podría haber cambiado durante este tiempo.
¿En qué consiste ZooKeeper? Hay 4 cosas principales. Estos son procesos de procesamiento: solicitud. Y también ZooKeeper Atomic Broadcast. Hay un registro de confirmación donde se registran todas las operaciones. Y la propia base de datos replicada en memoria, es decir, la propia base de datos donde se almacena todo este árbol.
Vale la pena señalar que todas las operaciones de escritura pasan por el Procesador de solicitudes. Y las operaciones de lectura van directamente a la base de datos en memoria.
La base de datos en sí está completamente replicada. Todas las instancias de ZooKeeper almacenan una copia completa de los datos.
Para restaurar la base de datos después de un fallo, existe un registro de confirmación. La práctica estándar es que antes de que los datos lleguen a la memoria, se escriben allí para que, si falla, se pueda reproducir este registro y restaurar el estado del sistema. Y también se utilizan instantáneas periódicas de la base de datos.
ZooKeeper Atomic Broadcast es algo que se utiliza para mantener datos replicados.
ZAB selecciona internamente un líder desde el punto de vista del nodo ZooKeeper. Otros nodos se convierten en sus seguidores y esperan algunas acciones de ella. Si reciben entradas, las envían todas al líder. Primero realiza una operación de escritura y luego envía un mensaje sobre lo que ha cambiado a sus seguidores. De hecho, esto debe realizarse de forma atómica, es decir, la operación de grabación y transmisión de todo el conjunto debe realizarse de forma atómica, garantizando así la coherencia de los datos.
Solo procesa solicitudes de escritura. Su principal tarea es transformar la operación en una actualización transaccional. Esta es una solicitud generada especialmente.
Y aquí cabe destacar que la idempotencia de las actualizaciones para una misma operación está garantizada. ¿Lo que es? Esto, si se ejecuta dos veces, tendrá el mismo estado, es decir, la solicitud en sí no cambiará. Y esto debe hacerse para que, en caso de falla, pueda reiniciar la operación, deshaciendo así los cambios que se han caído en este momento. En este caso, el estado del sistema será el mismo, es decir, no debería darse el caso de que una serie de procesos iguales, por ejemplo de actualización, conduzcan a diferentes estados finales del sistema.
Fuente: habr.com