PortadaApache Zookeeper

Apache Zookeeper

by Donal Sandro Noblejas Huaman

Hola mi nombre es donal Sandro Noblejas Huam谩n de Lima Per煤 馃嚨馃嚜 hoy vengo con otro art铆culo de  Gesti贸n de personal y como siempre y en cada uno de ellos completamente solo y me agrada porque se aprende, y como siempre sin empresas, personas, familiares, ni el estado ni ning煤n tipo de ayuda cuidado con los estafadores solo en mis tiempos libres redactando jejeje, bueno ah铆 vamos.

Apache Zookeeper es un proyecto de c贸digo abierto  de Apache Software Foundation,  un coordinador de servicios que proporciona sincronizaci贸n distribuida de peque帽os datos (informaci贸n de configuraci贸n, espacio de nombres) para un grupo de aplicaciones. Zookeeper es un almac茅n distribuido de valores clave que garantiza un almacenamiento de informaci贸n confiable y consistente mediante replicaci贸n sincr贸nica entre nodos, control de versiones, un mecanismo de cola y bloqueos. Debido al uso de RAM y escalabilidad, tiene alta velocidad. 

Escenarios para usar Zukeeper:

  • Servidor de nombres distribuido ( espacio de nombres – temas para Kafka )
  • Configuraci贸n distribuida ( Hadoop , Kafka )
  • Membres铆a de grupo distribuido (servicios distribuidos Kafka, Hadoop)
  • Elecci贸n de l铆der en sistemas distribuidos con arbitraje.

C脫MO FUNCIONA APACHE ZOOKEEPER

Arquitect贸nicamente, Zukeeper se organiza utilizando tecnolog铆a cliente-servidor, cuando las aplicaciones cliente acceden a uno de los nodos combinados en un conjunto. Entre el conjunto de servidores, hay un nodo l铆der , que realiza todas las operaciones de escritura e inicia la recuperaci贸n autom谩tica si alguno de los servidores conectados falla. Los nodos restantes, suscriptores o seguidores, replican datos del l铆der y son utilizados por las aplicaciones cliente para su lectura.

ZooKeeper simula un sistema de archivos de 谩rbol virtual de nodos interconectados que representan un concepto combinado de archivo y directorio. Cada nodo de esta jerarqu铆a puede almacenar datos simult谩neamente y tener nodos secundarios subordinados.

VENTAJAS Y DESVENTAJAS DE ZUKEEPER

Las principales ventajas de Zookeeper en sistemas distribuidos de Big Data son las siguientes:

  • tolerancia a fallas del cl煤ster;
  • sincronizaci贸n de servicios distribuidos;
  • sincronizaci贸n autom谩tica de datos;
  • ordenamiento de mensajes;
  • car谩cter transaccional de la transferencia de datos.

La otra cara de estas ventajas son las siguientes desventajas :

  • dependencia de la RAM del host;
  • n煤mero excesivo de servidores;
  • caracter铆sticas del protocolo ZAB para sincronizaci贸n de datos en un conjunto de servidores;
  • espacio de nombres limitado y n煤mero de hijos de cada nodo.

Escribimos m谩s sobre por qu茅 se usa Apache Zookeeper en los cl煤steres de Hadoop, Kafka y HBase . Y sobre la arquitectura, principios operativos b谩sicos y principales problemas de Zukiper,

misi贸n del Zookeeper

La funci贸n principal de Zookeeper es coordinar m煤ltiples tareas en un sistema distribuido. colaboraci贸n o podr铆a ser competencia La colaboraci贸n significa que m煤ltiples procesos deben tratar ciertas cosas juntas. Algunos procesos toman ciertas acciones para permitir que otros procesos contin煤en ejecut谩ndose. Por ejemplo, en el modo maestro-esclavo, el nodo maestro se comunica con el nodo esclavo y el nodo maestro asigna tareas a los nodos esclavos; Esto significa que dos procesos no pueden procesar trabajo al mismo tiempo. Un proceso debe esperar a otro proceso. Adem谩s, en la operaci贸n maestro-esclavo, solo hay un maestro en cualquier momento a trav茅s de bloqueos mutuamente excluyentes.

Las aplicaciones que utilizan Zookeeper incluyen los siguientes sistemas familiares:

  • ApacheHBase
  • Apache Kafka
  • apache solr

Adem谩s de las aplicaciones anteriores, existen muchos ejemplos de uso de Zookeeper. Cuando usamos Zookeeper, a menudo usamos la API proporcionada por el cliente Zookeeper. La API del cliente de Zookeeper es poderosa e incluye:

  • Garant铆a de estricta coherencia, orden y durabilidad.
  • Capacidad para implementar primitivas de sincronizaci贸n comunes.
  • En sistemas distribuidos reales, el paralelismo a menudo conduce a un comportamiento incorrecto. Zookeeper proporciona un mecanismo de procesamiento paralelo simple

Escenarios donde Zookeeper no es aplicable

Zookeeper debe utilizarse para gestionar datos clave de colaboraci贸n entre aplicaciones distribuidas. Estos datos suelen ser precisos y poco numerosos. Zookeeper no es adecuado para el almacenamiento masivo de datos. En aplicaciones pr谩cticas, se recomienda separar los datos de colaboraci贸n de los datos de la aplicaci贸n. Los datos de colaboraci贸n pueden utilizar Zookeeper, mientras que los datos de la aplicaci贸n pueden tener en cuenta soluciones de almacenamiento como bases de datos o sistemas de archivos distribuidos.

Sobre el proyecto Apache

Zookeeper es un proyecto de c贸digo abierto alojado por Apache Software Foundation, y el Comit茅 de Gesti贸n de Proyectos de Apache es responsable de gestionar y supervisar los proyectos. Solo los expertos t茅cnicos pueden revisar la soluci贸n, pero cualquier desarrollador puede contribuir con una soluci贸n.

Construyendo un sistema distribuido usando Zookeeper

Hay muchas razones por las que utilizamos un dise帽o de sistema distribuido: un sistema distribuido puede utilizar la potencia de procesamiento de m煤ltiples procesadores para ejecutar componentes como tareas de replicaci贸n paralela. Es posible que sea necesario distribuir el sistema en diferentes ubicaciones; por ejemplo, una aplicaci贸n es atendida por m煤ltiples servidores en diferentes ubicaciones.

En los sistemas distribuidos se debe prestar especial atenci贸n a las siguientes cuestiones:

  • traso del mensaje: La transmisi贸n de un mensaje puede tener alg煤n retraso, por ejemplo debido a la congesti贸n de la red. Este retraso puede tener consecuencias impredecibles. Por ejemplo, el proceso P env铆a un mensaje primero y luego otro proceso Q env铆a el mensaje, pero quiz谩s el mensaje del proceso Q se entrega primero.
  • Rendimiento del procesador: cuando un proceso env铆a un mensaje a otro proceso, la latencia de todo el mensaje es aproximadamente igual a la suma del tiempo del remitente, el tiempo de transmisi贸n y el tiempo de procesamiento del receptor. Por lo tanto, la programaci贸n y la sobrecarga del sistema operativo tambi茅n pueden provocar el mensaje de retraso en el procesamiento.
  • Deriva del reloj: no es raro que los sistemas utilicen el concepto de tiempo, como determinar qu茅 eventos ocurren en un sistema en un momento particular. Sin embargo, la velocidad del reloj del procesador no es confiable y pueden ocurrir compensaciones arbitrarias entre ellos, lo que puede llevar a decisiones incorrectas.

Estos problemas conducen al resultado, es decir, en realidad es dif铆cil juzgar si hubo una falla en el proceso o si algunos factores causaron los retrasos.

El dise帽o preciso de Zookeeper hace que estos problemas sean f谩ciles de resolver, implementa soluciones a importantes problemas de computaci贸n distribuida, proporciona a los desarrolladores un grado de encapsulaci贸n y facilita nuestro desarrollo.

Conceptos b谩sicos del cuidador Zookeeper 

La colaboraci贸n distribuida generalmente requiere proporcionar algunas primitivas; por ejemplo, un mecanismo de bloqueo distribuido debe proporcionar primitivas como crear, obtener y desasignar. Pero como middleware para la coordinaci贸n distribuida, proporcionar primitivas tiene dos desventajas: 

1) Hay muchos tipos de cooperaci贸n distribuida: proporciona una lista detallada de primitivas o actualiza constantemente las primitivas; 

2) La forma en que los primitivos proporcionan servicios carece de flexibilidad.

Por lo tanto, Zookeeper adopta un enfoque diferente: no proporciona primitivas directamente, pero permite que las aplicaciones implementen sus propias primitivas, proporcionando un enfoque similar a un sistema de archivos. Zookeeper mantiene principalmente una estructura de datos de 谩rbol y los nodos de la estructura se denominan znodes. La siguiente figura describe la estructura de un 谩rbol de nodos: el nodo ra铆z contiene 4 nodos secundarios, tres de los cuales tienen un nodo siguiente, y los nodos hoja almacenan informaci贸n de datos.

Descripci贸n general de la API

Un znode puede contener o no datos. Si el znode contiene datos, los datos se almacenan como una matriz de bytes. El formato de matriz de bytes espec铆fico depende de la implementaci贸n de la aplicaci贸n. Zookeeper no proporciona soporte de an谩lisis directo. Una aplicaci贸n puede utilizar paquetes serializados como Protocol Buffer, Thrift, Avro o MessagePack para procesar los datos almacenados en znode, pero a menudo una cadena codificada en UTF-8 o ASCII es suficiente.

La API de Zookeeper proporciona las siguientes operaciones:

  • crear/ruta de datos: crea un znode con nombre/ruta e incluye datos
  • eliminar/ruta: eliminar znode con nombre/ruta
  • Existe/ruta: compruebe si existe un nodo con nombre/ruta
  • setData/ruta de datos: establece los datos de znode con nombre/ruta a los datos
  • getData/path: devuelve datos llamados /nodo de ruta
  • getChildren/path: devuelve una lista de nodos secundarios de nodo/ruta

Cabe se帽alar que Zookeeper no permite la escritura o lectura local. Al leer y escribir datos, el contenido de znode se reemplazar谩 o se leer谩 por completo.

Diferentes tipos de nodo

Al crear un nuevo znode, debe especificar un tipo de nodo; diferentes tipos determinan el comportamiento del znode.

Nodos permanentes y temporales.

Un znode puede ser un nodo persistente o un nodo ef铆mero. Los nodos permanentes solo se pueden eliminar llamando a eliminar, y los nodos temporales tambi茅n se eliminar谩n cuando el cliente salga o cierre la conexi贸n.

Los nodos persistentes pueden guardar datos para aplicaciones, incluso si el creador ya no est谩 vivo, los datos se pueden guardar sin p茅rdida. El nodo temporal transmite informaci贸n sobre ciertos aspectos de la aplicaci贸n, es decir, s贸lo la sesi贸n del creador es efectiva y esta informaci贸n debe almacenarse de manera eficiente. Por ejemplo, en el ejemplo del modo maestro-esclavo, el znode creado por el maestro podr铆a ser un nodo temporal. Cuando existe un nodo, significa que actualmente existe un maestro y est谩 funcionando bien; si el nodo temporal correspondiente al maestro desaparece, significa que el nodo maestro ha fallado. Otros nodos de respaldo pueden hacerse cargo del maestro original.

Nodo ordenado

Un Znode tambi茅n se puede configurar como un nodo secuencial (secuencial), al znode ordenado se le asignar谩 un entero 煤nico que aumenta mon贸tonamente. Al crear un nodo ordenado, se agregar谩 un n煤mero de pedido a la ruta. Por ejemplo, cree un znode ordenado cuya ruta sea /tasks/task-, luego Zookeeper asignar谩 un n煤mero de secuencia como 1 y agregar谩 ese n煤mero a la ruta, y finalmente este nodo ser谩 /tasks/task-1.

En resumen, existen 4 tipos de znoude:

  • persistente
  • ef铆mero
  • persistente_secuencial
  • Temporal y secuencial (ef铆mero_secuencial)

Monitoreo y notificaci贸n

La encuesta suele ser cara. Considere el siguiente ejemplo. La segunda llamada a getChildren/tasks devuelve el mismo valor, que es una colecci贸n vac铆a, pero esta llamada no es realmente necesaria.

lunxun

Por lo tanto, Zookeeper proporciona un mecanismo basado en notificaciones: el cliente establece un punto de vigilancia para un znode en Zookeeper y la notificaci贸n cambia cuando cambia el znode. Sin embargo, el punto de monitoreo se activa una vez y se debe instalar un nuevo punto de monitoreo despu茅s del activador. La siguiente figura muestra un diagrama esquem谩tico del uso de puntos de monitoreo:

notificaci贸n

El cliente puede establecer varios puntos de interrupci贸n:

  • Seguimiento de cambios de datos en znode
  • Escuche los cambios en los znodes secundarios
  • Supervisar la creaci贸n o eliminaci贸n de znode

Tambi茅n vale la pena se帽alar que Zookeeper no proporciona una API para configurar puntos de monitoreo por separado, pero establece puntos de monitoreo como funciones adicionales en las operaciones de lectura (como getData, getChildren, existente, etc.).

versi贸n

Cada znode tiene un n煤mero de versi贸n que se incrementa autom谩ticamente con cada cambio de datos. Zookeeper proporciona dos operaciones API condicionales: setDate y eliminar. Estas dos llamadas pueden pasar un n煤mero de versi贸n espec铆fico y la llamada solo tendr谩 茅xito si el n煤mero de versi贸n pasado coincide con el n煤mero de versi贸n del servidor. Cuando varios clientes de Zookeeper realizan operaciones paralelas en el mismo znode, el uso de n煤meros de versi贸n es especialmente importante. La siguiente figura describe la situaci贸n de esta operaci贸n paralela:

concurrencia

Arquitectura del Zookeeper

La aplicaci贸n utiliza la biblioteca cliente de Zookeeper para comunicarse con el servidor Zookeeper de la siguiente manera:

cliente

El servidor Zookeeper tiene dos modos operativos: modo independiente y modo de qu贸rum. El modo independiente significa que solo hay un servidor y el estado de Zookeeper no se puede copiar, mientras que el modo arbitrado contiene un grupo de servidores de Zookeeper, llamados retiros de Zookeeper, que pueden replicar el estado entre ellos y atender las solicitudes de los clientes simult谩neamente.

Arbitraje del cuidador del zool贸gico

En modo de arbitraje, Zookeeper replica el 谩rbol de estado en todos los servidores del cl煤ster. Pero si el cliente necesita esperar a que cada servidor guarde los datos antes de continuar, entonces la demora ser谩 intolerable, por lo que Zookeeper debe establecer un qu贸rum para el arbitraje: este es el n煤mero m铆nimo de servidores efectivos para que el cl煤ster de Zookeeper funcione normalmente, y tambi茅n la cantidad de servidores que el cliente debe guardar exitosamente al actualizar los datos. Por ejemplo, hay 5 servidores Zookeeper en un cl煤ster y el qu贸rum es 3, por lo que siempre que 3 servidores hayan guardado actualizaciones, el cliente se actualizar谩 correctamente.

Si el qu贸rum es menor o igual a la mitad del total, aparecer谩 Split Brain Este problema. Suponiendo que hay 5 servidores y el qu贸rum es 2, ahora hay una solicitud para crear un znode (suponiendo que la ruta es /z), los servidores s1 y s2 han guardado esta actualizaci贸n, Zookeeper le devuelve al cliente que la llamada fue exitosa, pero se actualizar谩 a s1 y s2 Antes de copiarse a otros servidores en el cl煤ster, s1 y s2 tienen particiones de red con otros servidores y clientes al mismo tiempo. En este escenario, todo el servicio sigue marcado como normal ya que el qu贸rum es 2, pero esos 3 servidores perder谩n znode/z. As铆, para funcionar correctamente, el qu贸rum debe seguir el principio de mayor铆a, que debe exceder la mitad del n煤mero total. Para funcionar correctamente, un conjunto de 5 servidores Zookeeper debe tener al menos 3 servidores normales, y el cliente debe actualizarse correctamente a al menos 3 servidores al actualizar.

Curiosamente, el n煤mero de conjuntos de Zookeeper es impar, a menos que exista una posibilidad aleatoria. Si el n煤mero de conjuntos es 4, entonces el qu贸rum es 3 seg煤n el principio de mayor铆a, entonces este conjunto solo puede tolerar una falla de computadora, pero cada solicitud requiere 3 servidores para actualizarse exitosamente, lo que significa que el retraso de actualizaci贸n es mayor, pero no puede ser asegur贸 una mejor tolerancia a fallos. En otras palabras, si el n煤mero de conjuntos es 4, tambi茅n se puede reducir de 1 a 3.

conversaci贸n

La sesi贸n es un concepto muy importante en Zookeeper: cuando un cliente crea un identificador de Zookeeper, el servicio Zookeeper crear谩 una sesi贸n para 茅l, el cliente se conecta inicialmente al servidor de la colecci贸n. Si no puede conectarse al servidor, su sesi贸n se puede trasladar a otro servidor. Por supuesto, esta traducci贸n la realiza el propio cliente Zookeeper.

Las sesiones imponen el orden, lo que significa que las solicitudes en la misma sesi贸n se ejecutan en orden primero en entrar, primero en salir (FIFO). Normalmente, un cliente solo abrir谩 una sesi贸n y, por supuesto, es posible abrir varias sesiones, pero debe tenerse en cuenta que no se puede garantizar el orden entre varias sesiones simult谩neas.

Garant铆a de pedido

Cuando utilizamos Zookeeper para implementar nuestra aplicaci贸n, debemos tener en cuenta algunas consideraciones importantes sobre el flujo de dise帽o.

Orden de operaciones de escritura

Zookeeper copia los cambios de estado en todos los servidores del cl煤ster y los servidores realizar谩n cambios de estado en el mismo orden. Por ejemplo, si el servidor Zookeeper realiza cambios que primero modifican los datos del nodo /z y luego realiza cambios que eliminan los nodos /z, entonces todos los servidores de la colecci贸n deben realizar los cambios en el mismo orden. Pero el servidor de recopilaci贸n de Zookeeper no necesita realizar estos cambios al mismo tiempo , solo deben realizarse en el mismo orden.

Leer orden

El cliente Zookeeper siempre ver谩 la misma secuencia de actualizaciones incluso si est谩n conectados a diferentes servidores, pero el cliente puede ver la actualizaci贸n en diferentes momentos.

Efecto reba帽o en los puntos de observaci贸n.

Hay un problema a tener en cuenta: cuando cambia un znode, Zookeeper activar谩 todos los puntos de monitoreo registrados en el znode. Por ejemplo, hay 1000 clientes que escuchan el mismo znode usando la operaci贸n existir. Cuando se crea un znode, Zookeeper enviar谩 1000 notificaciones. Esto puede provocar problemas de rendimiento y provocar que otras operaciones se retrasen o se bloqueen. Este fen贸meno se llama efecto reba帽o. Al utilizar Zookeeper para el monitoreo, debe intentar evitar el efecto de manada, es decir, evitar registrar una gran cantidad de puntos de monitoreo en el mismo nodo.

Veamos el problema del bloqueo distribuido. Supongamos que hay n clientes compitiendo por el candado. Para obtener un bloqueo, el cliente debe intentar crear un nodo /lock; si el nodo ya existe, el cliente escucha el evento de eliminaci贸n de ese znode. Cuando se elimina /lock, se notificar谩 a todo el Cliente de monitoreo del nodo /lock. Este esquema causar谩 un efecto de manada, podemos usar un esquema mejor: el cliente puede crear un Nodo /lock/lock- ordenado como se mencion贸 anteriormente, Zookeeper agregar谩 autom谩ticamente un n煤mero de serie despu茅s de este znode en /lock/lock-xxx, donde xxx es el n煤mero de serie. Formularemos una nueva estrategia de adquisici贸n de bloqueo en la que el cliente con el n煤mero de serie m谩s peque帽o obtenga el bloqueo, de modo que despu茅s de que el cliente cree un nodo ordenado, pueda obtener todos los nodos en /lock a trav茅s de /getChildren y determinar si el nodo que cre贸 es el nodo con el n煤mero de serie m谩s peque帽o. Obtenga el bloqueo; de lo contrario, establezca el punto de control en el nodo anterior en la secuencia del n煤mero de serie. Por ejemplo, tenemos tres nodos: /lock/lock-001, /lock/lock-002, /lock/lock-003, entonces la configuraci贸n de los puntos de monitoreo es la siguiente:

  • El cliente que crea /lock/lock-001 obtiene el bloqueo
  • Crear/lock/lock-002 monitor de cliente/lock/lock-001 nodo
  • Crear/lock/lock-003 monitor de cliente/lock/lock-002 nodo

Por tanto, en cada nodo hay como m谩ximo un punto de seguimiento.

Solucionando problemas

Hay tres puntos principales de falla: el servicio Zookeeper, la red y la aplicaci贸n misma. La soluci贸n de problemas depende de la ubicaci贸n espec铆fica donde se encuentra la falla, pero encontrar una ubicaci贸n espec铆fica no es tan f谩cil. Supongamos la siguiente topolog铆a:

![accidente])(/assets/zookeeper/crash.png)

El servicio Zookeeper consta de tres servidores y, al mismo tiempo, hay dos clientes c1 y c2. Si c1 est谩 inicialmente conectado a s1, pero la conexi贸n se desconecta en alg煤n momento, entonces c1 no puede determinar si se debe a una falla de la red o a que el servidor de s1 se desconect贸.

Discusi贸n adicional: suponiendo que esto se debe a una falla de la red y c1 no puede comunicarse con todos los servidores de Zookeeper, entonces, si la falla de la red contin煤a por un tiempo suficiente, la sesi贸n entre c1 y Zookeeper expirar谩 aunque c1 est茅 realmente vivo, pero Zookeeper a煤n estar谩 activo. declare c1 como inactivo porque c1 no puede comunicarse con ning煤n servidor: si c2 est谩 escuchando en el nodo temporal creado por c1, entonces c2 tambi茅n confirmar谩 que c1 ha terminado, aunque en este escenario c1 todav铆a est谩 vivo.

Error corregible

Si se pierde la conexi贸n entre el cliente y el servicio Zookeeper, recibir谩 un evento Desconectado o una ConnectionLossException. Por supuesto, el cliente de Zookeeper intentar谩 activamente salir de esta situaci贸n. Continuar谩 intentando volver a conectarse a otro servidor de Zookeeper hasta que finalmente se restablezca la sesi贸n. Una vez restaurada la sesi贸n, Zookeeper generar谩 un evento SyncConnected y comenzar谩 a procesar el pedido. Adem谩s, el cliente volver谩 a registrar el punto de monitoreo que se registr贸 previamente y generar谩 eventos de punto de monitoreo para los cambios que ocurrieron mientras se perd铆a la conexi贸n.

Cabe se帽alar que cuando un cliente pierde la conexi贸n, no puede recibir notificaciones sobre las actualizaciones de Zookeeper, lo que puede hacer que el cliente pierda algunos cambios de estado importantes mientras se pierde la sesi贸n. Veamos el ejemplo a continuaci贸n.

l铆der

El cliente c1 inicialmente actu贸 como l铆der y perdi贸 la conexi贸n en el momento t2, pero no se dio cuenta de esta situaci贸n hasta que se declar贸 en estado de terminaci贸n en el momento t4, mientras que la sesi贸n expir贸 en el momento t2 y el otro cliente c2 se convirti贸 en el l铆der en el momento t3. De t2 a t4, c1 no sabe que se declara en estado completo y que otro cliente ha asumido la responsabilidad de liderazgo.

Si no manejamos esto con cuidado, entonces el antiguo l铆der y el nuevo l铆der existir谩n simult谩neamente y sus operaciones pueden entrar en conflicto. Por lo tanto, cuando un cliente recibe un evento Desconectado, se recomienda que el proceso se suspenda como l铆der antes de volver a conectarse.

Veamos otro caso con puntos de seguimiento.

En primer lugar, debemos saber que para que la conexi贸n entre la desconexi贸n y la restauraci贸n de la sesi贸n sea m谩s fluida, el cliente Zookeeper restablecer谩 el punto de monitoreo previamente existente en el nuevo servidor. Cuando un cliente se conecta al servidor Zookeeper, env铆a una lista de puntos de monitoreo y el 煤ltimo zxid conocido (marca de tiempo del estado final). El servidor tomar谩 estos puntos de monitoreo y verificar谩 si la marca de tiempo modificada del znode monitoreado es m谩s reciente que el zxid. ,Si es posterior a la fecha l铆mite, se activa este punto de monitoreo.

Cada operaci贸n de Zookeeper sigue esta l贸gica por completo, excepto cuando existe. La operaci贸n existente es diferente de otras operaciones porque esta operaci贸n puede establecer un punto de monitoreo en un nodo inexistente. He aqu铆 una situaci贸n que requiere atenci贸n. Considere la siguiente figura:

existe

El cliente est谩 monitoreando el evento/evento de creaci贸n del nodo, pero est谩 desconectado de Zookeeper por razones de red. Sin embargo, durante el per铆odo de interrupci贸n, otro cliente cre贸 /event y elimin贸 /event. Al configurar un punto de monitoreo, el Cliente se volvi贸 a conectar a Zookeeper y volvi贸 a registrar el punto de monitoreo, pero como se descubri贸 que no hab铆a ning煤n nodo/evento, simplemente registr贸 ese punto de monitoreo y termin贸 haciendo que el cliente perdiera la creaci贸n/ evento evento. Por lo tanto, debemos evitar monitorear la creaci贸n de un znode.

Error fatal

En ocasiones, por algo peor, la sesi贸n no se puede retomar y hay que cerrarla. La raz贸n m谩s com煤n para esta situaci贸n es que la sesi贸n ha caducado y Zookeeper no puede volver a autenticar la sesi贸n autenticada. En ambos casos, Zookeeper restablece el estado de la sesi贸n. El ejemplo m谩s obvio de dicha p茅rdida de estado es un nodo temporal que se elimina cuando se cierra una sesi贸n.

Cuando un cliente no proporciona la informaci贸n de autenticaci贸n correcta para completar la autenticaci贸n de la sesi贸n o volver a conectarse a una sesi贸n caducada despu茅s de un evento Desconectado, se producir谩 una falla fatal. La forma m谩s sencilla de lidiar con fallas irrecuperables es finalizar el proceso y reiniciarlo para que pueda volver a su estado original y reinicializar su estado mediante una nueva sesi贸n.

Elecciones de l铆deres de grupo y recursos externos

Zookeeper proporciona una vista coherente del sistema para todos los clientes, pero cabe se帽alar que Zookeeper no puede proteger las comunicaciones con dispositivos externos. Por ejemplo, cuando el host de un proceso cliente est谩 sobrecargado, el tr谩fico del sistema y el proceso pueden retrasarse. La programaci贸n de subprocesos locales en el host puede causar problemas: el subproceso de la aplicaci贸n cree que todav铆a est谩 activo y retiene el nodo maestro, incluso el subproceso Zookeeper. S贸lo ser谩 notificado cuando el tiempo de espera de la sesi贸n haya expirado.

Considere un ejemplo t铆pico a continuaci贸n:

recurso-l铆der
  • En el momento t1, la comunicaci贸n con Zookeeper se detiene debido a una sobrecarga del sistema y, en este momento, c1 pone en cola las actualizaciones de la base de datos para su ejecuci贸n, pero no recibe un ciclo de reloj de la CPU para realizar estas actualizaciones de la base de datos;
  • En el momento t2, Zookeeper anuncia que la sesi贸n c1 ha finalizado y elimina el nodo temporal asociado con la sesi贸n c1;
  • En el momento t3, c2 se convierte en el nodo maestro;
  • En el momento t4, c2 cambi贸 el estado de DB;
  • En el momento t5, c1 env铆a una actualizaci贸n en cola a la base de datos;
  • En el momento t5, c1 se volvi贸 a conectar con Zookeeper y descubri贸 que su sesi贸n hab铆a caducado y hab铆a perdido los derechos de control, pero desafortunadamente en el momento t5 la base de datos se actualiz贸, lo que provoc贸 que el estado del sistema se corrompiera.

Podemos utilizar una t茅cnica llamada esgrima, lo que significa que solo los clientes con los 煤ltimos s铆mbolos de esgrima pueden acceder a los recursos. Cuando creamos un nodo que representa un encabezado de grupo, podemos obtener informaci贸n sobre la estructura Stat.Czxid en la estructura que representa zxid cuando se crea el nodo. Dado que zxid es un n煤mero ordinal 煤nico que aumenta mon贸tonamente, podemos usar czxid como una convenci贸n aislada. Cuando realizamos una solicitud a un recurso externo, debemos proporcionar este car谩cter de aislamiento. Si un recurso externo recibe una solicitud para una versi贸n superior del s铆mbolo de aislamiento, nuestra solicitud ser谩 rechazada.

Consideraciones del Zookeeper

Resumen de la sesi贸n

Si su cliente Zookeeper falla y luego vuelve a estar en l铆nea, la aplicaci贸n deber铆a resolver una serie de problemas cuando vuelva a estar en l铆nea.

En primer lugar, aunque la aplicaci贸n actual falla, otros clientes todav铆a se est谩n ejecutando y es posible que el estado en Zookeeper haya cambiado, por lo que no use el estado previamente almacenado en cach茅 despu茅s de restaurar la sesi贸n. Por ejemplo, en una implementaci贸n maestro-esclavo, si el nodo maestro falla y se recupera, y el cl煤ster puede completar la recuperaci贸n del fallo del nodo en espera, en ese momento, cuando el antiguo nodo maestro se recupera, ya no puede considerarse un maestro. nodo.

El segundo problema importante es que cuando un cliente falla, una operaci贸n pendiente enviada por Zookeeper podr铆a completarse y el cliente no recibe un mensaje de confirmaci贸n debido al error. Por lo tanto, es posible que el cliente deba realizar algunas operaciones de limpieza del estado de Zookeeper durante la recuperaci贸n.

Cuando se recrea el znode, el n煤mero de versi贸n se restablecer谩

Esto parece obvio, pero es necesario enfatizarlo nuevamente: una vez que se elimina y reconstruye un znode, su n煤mero de versi贸n se restablecer谩. Suponiendo que el cliente recibe los datos de znode, cambie los datos del nodo y escriba seg煤n la condici贸n 1 del n煤mero de versi贸n. Si el znode se elimina y reconstruye cuando el cliente actualiza los datos del nodo, el n煤mero de versi贸n seguir谩 coincidiendo, pero puede contener Datos Incorrectos.

Secuencia cuando se pierde la conexi贸n

Para un evento de p茅rdida de conexi贸n, Zookeeper cancelar谩 la solicitud pendiente, para una llamada a un m茅todo sincr贸nico se generar谩 una excepci贸n, para una llamada de solicitud asincr贸nica la funci贸n de devoluci贸n de llamada devolver谩 un c贸digo de resultado para determinar la p茅rdida de conexi贸n. Una vez que se pierde la conexi贸n, el cliente Zookeeper no reenviar谩 autom谩ticamente la solicitud y la aplicaci贸n misma debe manejar la operaci贸n de reenv铆o para cancelar la solicitud.

Considere la siguiente secuencia de eventos:

  1. La aplicaci贸n env铆a una solicitud asincr贸nica y realiza la operaci贸n op1;
  2. El cliente detecta que la conexi贸n se perdi贸 y cancela la solicitud op1;
  3. El cliente se vuelve a conectar antes de que expire la sesi贸n;
  4. La aplicaci贸n env铆a una solicitud asincr贸nica y realiza op2;
  5. op2 se complet贸 con 茅xito;
  6. op1 devuelve el evento CONNECTIONLOSS;
  7. La aplicaci贸n reenv铆a la solicitud a la operaci贸n op1.

En este caso, la aplicaci贸n envi贸 solicitudes a op1 y op2, pero op2 se complet贸 exitosamente antes que op1. Si op2 depende de op1 para evitar que op2 se ejecute exitosamente antes que op1, podemos esperar a que op1 tenga 茅xito antes de enviar la solicitud de op2.

Llamada sincr贸nica y secuencia multiproceso.

La llamada sincr贸nica a Zookeeper se bloquear谩 hasta que se reciba un mensaje de respuesta. Si dos o m谩s subprocesos env铆an operaciones simult谩neas a Zookeeper, esos subprocesos se bloquear谩n hasta que se reciba un mensaje de respuesta. Zookeeper devolver谩 mensajes de respuesta en secuencia, pero debido a motivos de programaci贸n de subprocesos, los resultados de las operaciones enviadas posteriores pueden procesarse primero.

Secuencia de mezcla sincr贸nica y asincr贸nica.

Si envi贸 dos operaciones de llamada asincr贸nicas, op1 y op2, la llamada sincr贸nica a op3 se realiza en la funci贸n de devoluci贸n de llamada de op1, que bloquea el hilo de propagaci贸n del cliente Zookeeper, lo que har谩 que la aplicaci贸n reciba el resultado de op3. Solo despu茅s de recibir el resultado de op2 es la secuencia de resultados de operaci贸n observados por la aplicaci贸n, representa op1, op3, op2, pero el orden de env铆o real no es correcto.

Restricciones en campos de datos y nodos secundarios

Zookeeper limita el tama帽o de los datos solicitados, que es 1 M de forma predeterminada. Este valor limita el tama帽o del almac茅n de datos del nodo y tambi茅n limita la cantidad de nodos secundarios que puede tener cualquier nodo principal. Por supuesto, podemos aumentar este valor, pero esto puede resultar en un mayor tiempo de procesamiento para znode.

Servidor Zookeeper integrado

Muchos desarrolladores consideran integrar servidores Zookeeper en aplicaciones para ocultar su dependencia de Zookeeper. Este m茅todo hace que los usuarios de la aplicaci贸n sean transparentes para Zookeeper. Esta atenci贸n suena tentadora, pero no es recomendable. Al aceptar el Zookeeper integrado, si ocurre un error en Zookeeper, el usuario ver谩 los registros relacionados con Zookeeper. Desde este punto de vista, el usuario ya no es transparente: lo peor es que la disponibilidad de toda la aplicaci贸n y la disponibilidad de Zookeeper est谩n relacionadas entre s铆. Juntos, si uno de ellos renuncia, el otro tambi茅n debe hacerlo, lo que reduce la mayor ventaja de Zookeeper como servicio de alta disponibilidad.

Principio interno del cuidador del zool贸gico

En un entorno Zookeeper en cl煤ster, se elegir谩 un servidor particular como l铆der y otros servidores seguir谩n al l铆der llamado seguidor, el l铆der del grupo sirve como punto central para procesar todas las solicitudes de cambio al sistema Zookeeper y es responsable de establecer la secuencia. de todas las actualizaciones y los suscriptores reciben solicitudes de operaciones de actualizaci贸n del l铆der del grupo y procesa estas solicitudes.

El l铆der del grupo y sus seguidores forman la entidad principal que asegura el cambio de estado ordenado, y existe un tercer tipo de servidor llamado observador. El observador no participar谩 en la decisi贸n cuyas solicitudes puedan ser aceptadas, solo observa los resultados de la decisi贸n, el observador solo sirve para la escalabilidad horizontal del sistema.

Consultas, Transacciones e Identificadores

El servidor Zookeeper procesar谩 solicitudes de solo lectura (existe, getData, getChildren) localmente. Si el servidor recibe la solicitud getData de un cliente, el servidor lee la informaci贸n del estado local y se la devuelve al cliente. Por tanto, Zookeeper tiene un alto rendimiento al procesar consultas de solo lectura.

Las solicitudes de los clientes (crear, eliminar y establecer datos) que cambian el estado de Zookeeper se reenviar谩n al jefe del grupo, y el jefe del grupo ejecutar谩 la solicitud correspondiente y generar谩 una actualizaci贸n de estado, a la que llamamos transacci贸n. Una transacci贸n es una unidad, lo que significa que el cambio de una transacci贸n debe realizarse de forma at贸mica. Tomando la operaci贸n setData como ejemplo, cambiar la informaci贸n de datos del nodo y cambiar el n煤mero de versi贸n son transacciones at贸micas. El cl煤ster Zookeeper opera de manera transaccional y garantiza que todas las operaciones de modificaci贸n se completen de forma at贸mica, sin interferencia de otras transacciones. Al mismo tiempo, la transacci贸n tambi茅n es idempotente, lo que significa que podemos realizar la misma transacci贸n dos veces y el resultado ser谩 el mismo, incluso podemos realizar m煤ltiples transacciones varias veces y tambi茅n obtendremos el mismo resultado, pero la premisa es que garantizamos que el orden en el que se ejecutan estas transacciones es siempre el mismo.

Cuando un l铆der de grupo genera una transacci贸n, se le asigna un identificador llamado identificador de transacci贸n de Zookeeper (zxid). Al identificar una transacci贸n a trav茅s de zxid, puede ordenarla en cada servidor en el orden especificado por el l铆der del grupo. terminado. Cuando se elige un nuevo l铆der de grupo entre servidores, tambi茅n se intercambia zxid para que pueda saber qu茅 servidor ha recibido m谩s transacciones y mantener sincronizada su informaci贸n de estado. zxid es un entero largo (64 bits) dividido en dos partes: una marca de tiempo (茅poca) y un contador (contador), veremos su funci贸n espec铆fica m谩s adelante.

L铆der electoral

Para el cl煤ster Zookeeper, el problema del cerebro dividido se mencion贸 anteriormente: dos conjuntos de servidores operan de forma independiente, formando dos cl煤steres. Esta situaci贸n provocar谩 inconsistencia en el estado del cl煤ster, por lo que durante el proceso de selecci贸n hay varios qu贸rums para garantizar que, si hay varios qu贸rums, al menos un servidor ser谩 coherente.

Veamos el proceso de selecci贸n de un l铆der de grupo.

Cuando se inicia cada servidor Zookeeper, ingresa al estado MIRANDO. Si ya existe un l铆der de grupo, otros servidores le dir谩n a ese servidor qu茅 l铆der de grupo es y el nuevo servidor establecer谩 una conexi贸n con el l铆der de grupo y sincronizar谩 el estado. Si todos los servidores de un cl煤ster est谩n en el estado MIRANDO, estos servidores se comunicar谩n para elegir un l铆der del grupo. El servidor ganador ingresar谩 al estado L脥DER durante el proceso de elecci贸n y los otros servidores ingresar谩n al estado SIGUIENTE.

El protocolo para seleccionar un l铆der de grupo es muy sencillo. Durante las elecciones, cada servidor env铆a su mensaje de votaci贸n a otros servidores. La votaci贸n contiene, por ejemplo, la identificaci贸n del servidor (sid) y su 煤ltima identificaci贸n de transacci贸n (zxid): El mensaje de votaci贸n enviado por el servidor (1, 5) indica que el sid del servidor es 1 y el 煤ltimo zxid es 5. Cuando el servidor recibe el mensaje de votaci贸n, modifica su propio mensaje de votaci贸n seg煤n las siguientes reglas:

  1. Supongamos que los votos recibidos son voiceId y voiceZxid, y que los identificadores mismos son mySid y myZxid;
  2. Si (voiceZxid > myZxid) o (voiceZxid = myZxid y voiceId > mySid) entonces el servidor votar谩 para actualizar el mensaje de votaci贸n;
  3. De lo contrario no hay cambios.

En resumen, el 煤ltimo servidor gana la elecci贸n. Si varios servidores tienen el mismo zxid, el lado con el valor m谩s alto gana la elecci贸n. Cuando el servidor recibe la misma cantidad de votos de todos los servidores de arbitraje, el servidor anuncia que la elecci贸n del l铆der del grupo fue exitosa. Si el l铆der del grupo seleccionado es el propio servidor, entonces el servidor actuar谩 como l铆der del grupo; de lo contrario, el seguidor se conecta al l铆der del grupo j para la sincronizaci贸n.

Veamos ahora el proceso electoral con un ejemplo. El siguiente diagrama muestra el proceso electoral.

elecci贸n

Inicialmente, cada servidor env铆a su propio sid y zxid a los otros dos servidores. Despu茅s de la primera ronda, los servidores s2 y s3 鈥嬧媍ambiar谩n sus valores de votaci贸n (1, 6) y enviar谩n nuevos mensajes de votaci贸n. Finalmente, se selecciona a s1 como l铆der del equipo.

Zab: protocolo de transmisi贸n para actualizaciones de estado

Despu茅s de recibir una solicitud de escritura, el seguidor reenv铆a la solicitud al l铆der del grupo, y el l铆der del grupo intenta ejecutar la solicitud y comunica el resultado de la ejecuci贸n a todos los seguidores de manera transaccional. Aqu铆 Zookeeper define el protocolo de transmisi贸n at贸mica (Protocolo de transmisi贸n at贸mica de Zookeeper):

  1. El l铆der del grupo env铆a el mensaje OFERTA p a todos los suscriptores;
  2. Cuando el seguidor reciba el mensaje p, responder谩 con un mensaje ACK para notificar al l铆der del grupo que ha aceptado la propuesta (oferta);
  3. Cuando se recibe un mensaje de confirmaci贸n de la cantidad de arbitraje (el l铆der del grupo tambi茅n puede ser miembro de la cantidad de arbitraje), el l铆der del grupo env铆a un mensaje para notificar a los suscriptores que se ha producido una operaci贸n COMMIT.

Antes de responder a un mensaje de oferta, el suscriptor debe realizar algunas operaciones de verificaci贸n. El suscriptor verificar谩 si el mensaje de oferta pertenece al l铆der del grupo que est谩 siguiendo y confirmar谩 que el orden del mensaje de oferta y el mensaje de transacci贸n de confirmaci贸n enviados por el grupo El l铆der tiene raz贸n. El Acuerdo Zab garantiza las siguientes propiedades:

  • Si el l铆der del grupo transmite las transacciones T y T’ secuencialmente, cada servidor garantiza que la transacci贸n T se haya confirmado antes de confirmar T’;
  • Si un servidor particular env铆a transacciones en el orden de las transacciones T y T’, todos los dem谩s servidores tambi茅n deben enviar la transacci贸n T antes de confirmar la transacci贸n T’.

Estas dos propiedades garantizan que las transacciones est茅n en orden y que los servidores del cl煤ster no pierdan transacciones.

Dado que el servidor del l铆der del grupo tambi茅n puede fallar, si esto sucede, los otros servidores deben elegir un nuevo l铆der del grupo para garantizar que todo el sistema a煤n est茅 disponible. Zookeeper utiliza una marca de tiempo (茅poca) para indicar cambios en los derechos de administraci贸n. La marca de tiempo indica el per铆odo de tiempo que el l铆der del grupo ejerce derechos de control. Dentro de una marca de tiempo, el l铆der del grupo transmite un mensaje de propuesta y lo identifica mediante el contador. Cada mensaje Como se mencion贸 anteriormente, la primera parte del zxid es una marca de tiempo, por lo que cada zxid puede identificar f谩cilmente la marca de tiempo que cre贸.

El mayor desaf铆o al implementar este protocolo de transmisi贸n es el paralelismo del l铆der del grupo, y esta situaci贸n no es necesariamente un escenario de cerebro dividido. Los problemas de sincronizaci贸n o la p茅rdida de mensajes pueden causar este problema. Es muy dif铆cil evitar que dos servidores piensen que son l铆deres de grupo en el sistema al mismo tiempo. Para solucionar este problema, el protocolo Zab proporciona las siguientes garant铆as:

  • Un l铆der de grupo elegido garantiza que todas las transacciones que deben enviarse antes de confirmarse se transmitan antes de que se transmitan nuevas transacciones;
  • No habr谩 dos l铆deres de grupo apoyados por el arbitraje en un momento dado.

Para lograr la primera naturaleza, el l铆der del grupo debe asegurarse de que el n煤mero de servidores de arbitraje reconozca el estado inicial del nuevo l铆der del grupo. El estado inicial del nuevo l铆der de grupo debe incluir todas las transacciones confirmadas previamente, as铆 como las transacciones que fueron aceptadas pero no comprometidas (si las hubiera).

En segundo lugar, Zookeeper no impidi贸 por completo que el antiguo l铆der del grupo escapara. Supongamos que el l铆der del grupo actual es l, quien administra el cl煤ster y transmite las transacciones. En un momento determinado, el n煤mero de servidores Q, los 谩rbitros, que l ha desactivado, y comienza a elegir un nuevo l铆der de grupo l’. Supongamos que mientras la instituci贸n de arbitraje Q abandona al l铆der del grupo l, se transmite la transacci贸n T. Cuando se elige al l铆der del grupo l’, solo hay unos pocos servidores de arbitraje en el cl煤ster que se han comprometido con la transacci贸n T. En este caso, el antiguo grupo El l铆der seguir谩 iniciando la operaci贸n de confirmaci贸n. El punto clave aqu铆 es que al menos una de las m谩quinas de arbitraje que respaldan al nuevo l铆der del grupo y la m谩quina de arbitraje que confirma la transacci贸n T son iguales, lo que garantiza que el estado del sistema sea correcto, que la transacci贸n no se pierda y que el estado del sistema sea correcto. no ser destruido.

Veamos el escenario:

liderazgo

El servidor s5 es el antiguo l铆der del grupo l, s3 es el nuevo l铆der del grupo l’, una instituci贸n de arbitraje que admite s3, ya que el nuevo l铆der del grupo consta de s1-s3 y el zxid de la transacci贸n T es (1, 1). Despu茅s de recibir el segundo mensaje de confirmaci贸n, el servidor s5 env铆a con 茅xito un mensaje de confirmaci贸n al servidor s4 para notificar la transacci贸n de confirmaci贸n. Otros servidores ignoran el mensaje del servidor s5 porque siguen al servidor s3. Tenga en cuenta que el zxid que conoce el servidor s3 es (1, 1), por lo que conoce el punto de transacci贸n despu茅s de obtener los derechos de control. El acuerdo de Zab garantiza que el nuevo l铆der del grupo no se perder谩 (1, 1).

observador

El l铆der del grupo y los seguidores est谩n representados arriba, y hay un tipo de servidor que no est谩 representado: el observador. Los observadores y seguidores deben presentar propuestas del l铆der del grupo, pero la diferencia es que 茅l no participa en el proceso de votaci贸n, solo examina las propuestas presentadas en el mensaje INFORM.

Una de las principales razones para introducir observadores es mejorar la escalabilidad horizontal de las solicitudes de lectura. Al agregar observadores, podemos atender m谩s lecturas sin sacrificar el rendimiento de las escrituras. El rendimiento de escritura depende del n煤mero de arbitrajes. Si unimos m谩s servidores de votaci贸n, necesitaremos m谩s arbitrajes, lo que reducir谩 el rendimiento de escritura.

Otra raz贸n para utilizar observadores es la implementaci贸n en m煤ltiples centros de datos porque la latencia entre los centros de datos es relativamente alta y la distribuci贸n de un servidor en m煤ltiples centros de datos reducir谩 significativamente la velocidad del sistema. Una vez que se introducen los observadores, las solicitudes de actualizaci贸n se pueden ejecutar en el centro de datos con alto rendimiento y baja latencia y luego propagarse a centros de datos remotos.

Composici贸n del servidor

El l铆der del grupo, los seguidores y los observadores son esencialmente servidores. La principal abstracci贸n que utiliza Zookeeper al implementar servidores es el procesador de solicitudes. Cada servidor implementa una secuencia de procesadores de solicitudes y la solicitud pasa a trav茅s de la canalizaci贸n del servidor. El procesamiento de todos los procesadores se denomina finalizaci贸n del procesamiento.

El c贸digo Zookeeper tiene una interfaz RequestProcessor cuyo m茅todo principal es ProcessRequest, que toma un par谩metro Request. En una canalizaci贸n de procesador de consultas, el desacoplamiento de procesadores adyacentes se logra mediante colas.

Servidor implementado de forma independiente

La canalizaci贸n de procesamiento de solicitudes m谩s simple en Zookeeper es el servidor Zookeeper en modo independiente. La siguiente figura muestra su proceso de procesamiento. Puede ver que hay tres procesadores de solicitudes principales: PrepRequestProcessor, SyncRequestProcessor y FinalRequestProcessor.

ser 煤nico

El resultado del procesamiento de PrepRequestProcessor es la creaci贸n de una transacci贸n, que es el resultado de la operaci贸n de solicitud y debe actuar en el 谩rbol de datos de Zookeeper. La informaci贸n de la transacci贸n se agregar谩 al objeto de solicitud en forma de encabezado e informaci贸n de registro de transacci贸n. Adem谩s, solo las operaciones que cambian el estado de Zookeeper generar谩n transacciones. Para solicitudes de lectura, el atributo de transacci贸n en el objeto de solicitud es cero.

El siguiente procesador de solicitudes es SyncRequestProcessor, que es responsable de almacenar la transacci贸n en el disco, es decir, de agregar la transacci贸n al registro de transacciones y generar instant谩neas peri贸dicamente.

El procesador de solicitudes final es FinalRequestProcessor. Si la solicitud contiene una transacci贸n, la transacci贸n se aplica al 谩rbol de datos de Zookeeper; de lo contrario, simplemente lee los datos del 谩rbol de datos y regresa.

L铆der del grupo de servidores

En el modo de arbitraje, el canal de trabajo del l铆der del grupo se ve as铆:

tuber铆a l铆der

El primer procesador tambi茅n es PrepRequestProcessor y el siguiente procesador es ProposalRequestProcessor, que preparar谩 la propuesta y la enviar谩 a los suscriptores. ProposalRequestProcessor pasa todas las solicitudes a CommitRequestProcessor y tambi茅n pasa solicitudes de escritura a SyncRequestProcessor.

SyncRequestProcessor es similar a un servidor independiente que debe guardar la transacci贸n en el disco. Una vez ejecutado, inicia AckRequestProcessor, que simplemente genera un mensaje de confirmaci贸n y se lo devuelve a s铆 mismo. En modo de arbitraje, el l铆der del grupo debe recibir mensajes de reconocimiento de cada servidor, incluido el suyo propio, y el AckRequestProcessor es responsable de este mensaje de reconocimiento.

Despu茅s de ProposalRequestProcessor est谩 CommitRequestProcessor, que enviar谩 propuestas que reciban suficientes mensajes de confirmaci贸n.

El 煤ltimo procesador es el FinalRequestProcessor, que realiza la misma funci贸n que el servidor independiente, realizando la actualizaci贸n y devolviendo los datos de la solicitud de lectura.

Servidores de suscriptores y observadores

Ahora analicemos la secuencia del controlador de solicitudes de seguidores. Como puede ver en la figura siguiente, la secuencia del suscriptor no es la 煤nica secuencia. Dado que existen varias formas de entrada (solicitud de cliente, propuesta, confirmaci贸n de transacci贸n), la secuencia tambi茅n es diferente.

seguidor

El primer procesador es FollowerRequestProcessor, que recibe y procesa las solicitudes de los clientes. FollowerRequestProcessor pasa todas las solicitudes a CommitRequestProcessor y tambi茅n pasa la solicitud de escritura al servidor del l铆der del grupo. Para solicitudes de lectura, CommitRequestProcessor se pasa directamente a FinalRequestProcessor, y para solicitudes de escritura, CommitRequestProcessor esperar谩 a que se confirme la transacci贸n antes de pasarla a FinalRequestProcessor.

Cuando el servidor del l铆der del grupo recibe una solicitud de escritura, crea una oferta y la env铆a a los suscriptores. Cuando el suscriptor recibe la oferta, la pasa al SyncRequestProcessor. SyncRequestProcessor almacena la oferta y la env铆a a SendAckRequestProcessor. SendAckRequestProcessor devuelve un mensaje de reconocimiento de oferta al servidor del l铆der del grupo.

Cuando el servidor del l铆der del grupo reciba suficientes mensajes de confirmaci贸n, enviar谩 un mensaje de env铆o para enviar la propuesta. Cuando se recibe un mensaje de recepci贸n, el suscriptor lo procesa a trav茅s de CommitRequestProcessor.

Para mantener el orden, CommitRequestProcessor pausa el procesamiento de solicitudes posteriores despu茅s de recibir una solicitud de escritura hasta que la solicitud de escritura haya pasado CommitRequestProcessor.

La canalizaci贸n del procesador de un servidor observador es similar a la de un servidor suscriptor, pero debido a que el servidor observador no necesita reconocer el mensaje de oferta, el observador no necesita enviar un mensaje de reconocimiento de oferta al servidor l铆der del grupo ni almacenar la transacci贸n. en el disco duro.

Almacenamiento local

Uso de diario y disco

Como se mencion贸 anteriormente, el servidor almacenar谩 las transacciones a trav茅s del registro de transacciones y agregar谩 las transacciones propuestas al registro de transacciones en orden. Dado que el registro de registros de transacciones es tan importante, el propio Zookeeper debe abordar de manera efectiva el problema del registro de registros. En circunstancias normales, agregar registros al disco se completar谩 de manera eficiente, pero Zookeeper usa algunas estrategias para acelerar este proceso, es decir, confirmaciones masivas y relleno. La confirmaci贸n masiva se refiere a que se escriben m煤ltiples transacciones en el disco al mismo tiempo, por lo que solo se requiere una b煤squeda en el disco para registrar m煤ltiples transacciones. El llenado se refiere a la preasignaci贸n de bloques de almacenamiento en disco en un archivo. Si necesita agregar transacciones al registro a un ritmo alto y no hay espacio preasignado en el archivo, entonces se debe asignar un nuevo bloque de almacenamiento cada vez. un registro llega al final del archivo.

instant谩nea

Una instant谩nea es una copia del 谩rbol de datos de Zookeeper. Cada servidor suele guardar el 谩rbol de datos en un archivo de instant谩nea. Debido a que el servidor no bloquea la solicitud al crear una instant谩nea, el 谩rbol de datos puede cambiar cuando se crea el archivo de instant谩nea, por lo que la instant谩nea es borrosa porque no puede reflejar el estado consistente del 谩rbol de datos en ning煤n momento.

Por ejemplo, s贸lo hay 2 znodos en el 谩rbol de datos, /z y /z’. El inicio de datos de ambos nodos es 1. Actualmente se est谩n realizando los siguientes pasos:

  1. Iniciar instant谩nea;
  2. Serializar y agregar /z=1 a la instant谩nea;
  3. La transacci贸n T genera /z datos 2;
  4. Transacci贸n T ‘hace / z’, los datos son 2;
  5. Serialice y agregue /z’=2 a la instant谩nea.

Esta instant谩nea contiene /z=1 y /z’=2, pero esto no se aplica a ning煤n punto del 谩rbol de datos. Pero no es un problema. Cada archivo de instant谩nea estar谩 etiquetado con la 煤ltima transacci贸n confirmada al comienzo de la instant谩nea. Si el servidor descarga el archivo de instant谩nea, reproducir谩 todas las transacciones despu茅s de esta marca. Pero para hacer esto, debemos considerar otra pregunta: 驴habr谩 problemas al volver a ejecutar la misma transacci贸n? Como se mencion贸 anteriormente, las transacciones son idempotentes, por lo que no es un problema para nosotros ejecutar la misma transacci贸n nuevamente en el mismo orden.

Aqu铆 hay un peque帽o detalle para discutir. Si actualmente hay dos operaciones:

  1. establecerDatos /z’, 2, -1
  2. establecerDatos /z’, 3, 2

Por supuesto, la primera operaci贸n se puede ejecutar varias veces, independientemente del n煤mero de versi贸n, pero el problema es que la segunda operaci贸n no coincide con el n煤mero de versi贸n despu茅s de m煤ltiples ejecuciones. 驴Qu茅 debo hacer si falla la reproducci贸n? Este problema se resuelve utilizando el delta de estado generado por el servidor l铆der del grupo. Cuando un l铆der de equipo genera una transacci贸n, incluir谩 alg煤n valor de znode o cambiar谩 sus datos en la solicitud y especificar谩 un n煤mero de versi贸n espec铆fico para que cuando se reproduzca la transacci贸n no genere n煤meros de versi贸n incompatibles.

Autor Donal Sandro Noblejas Huam谩n

Lima Per煤 馃嚨馃嚜 

Whatsapp:51924118897 鈥 51939416004

Sitio web verlista.com

verlista.com

https://pe.linkedin.com/in/donal-sandro-noblejas-huaman

You may also like

Leave a Comment

Are you sure want to unlock this post?
Unlock left : 0
Are you sure want to cancel subscription?
-
00:00
00:00
Update Required Flash plugin
-
00:00
00:00