Java——"Preguntas de la entrevista——Guardián del zoológico"

Traducción literal: La traducción literal del nombre es administrador animal. Animal se refiere a software distribuido como Hadoop. Los tres caracteres de administrador reflejan las características de ZooKeeper: mantenimiento, coordinación, gestión y monitoreo.

Breve descripción: Algún software que desee convertir en un clúster o distribuido, puede usar ZooKeeper para ayudarlo a realizarlo.

Características:

Consistencia eventual: Los datos vistos por el cliente son eventualmente consistentes.
Fiabilidad: El servidor guarda el mensaje, por lo que siempre existe.
En tiempo real: ZooKeeper no puede garantizar que dos clientes obtengan los datos recién actualizados al mismo tiempo.
Independencia (la espera es irrelevante): Los diferentes clientes no se afectan directamente entre sí.
Atomicidad: la actualización tiene éxito o falla, no hay un tercer estado.

Nota: Para responder a las preguntas de la entrevista, no solo responda en una oración. Puede describir su comprensión del concepto, las características y otros aspectos. Déjame decirte que tu propósito es hacer que el entrevistador piense que eres bueno para comunicarte. Por supuesto, si no lo sabe, no finja saberlo y diga demasiadas ideas poco profesionales.

2. ¿Cuáles son los escenarios de aplicación de ZooKeeper?

Publicación de datos y suscripción.

La publicación y la suscripción es la denominada gestión de configuración. Como su nombre lo indica, es publicar datos en los nodos de ZooKeeper para que los suscriptores obtengan datos de forma dinámica y realicen una gestión centralizada y una actualización dinámica de la información de configuración. Por ejemplo, la información de configuración global, las listas de direcciones, etc. son muy adecuadas para su uso.

Un escenario común de publicación/suscripción de datos es el centro de configuración, donde el editor publica datos en uno o una serie de nodos de ZooKeeper para que los suscriptores se suscriban y logren el propósito de obtener datos de forma dinámica.

La información de configuración generalmente tiene varias características:

1. KV con pequeña cantidad de datos

2. El contenido de los datos cambiará dinámicamente durante el tiempo de ejecución

3. Uso compartido de máquinas en clúster, configuración coherente

ZooKeeper utiliza una combinación de empujar y tirar.

1. Push: el servidor enviará la notificación del evento de Wathcer al cliente registrado con el nodo de monitoreo

2. Extracción: después de que el cliente reciba la notificación, irá activamente al servidor para extraer los datos más recientes.

servicio de nombres

Como servicio de nombres distribuido, un servicio de nombres se refiere a obtener la dirección de un recurso o servicio a través de un nombre específico, utilizando ZooKeeper para crear una ruta global, que se puede usar como un nombre, apuntando al clúster en el clúster, la dirección del servicio prestado, o un objeto remoto, etc.

El diagrama de estructura de nombres del servicio de nombres unificado es el siguiente:

1. En un entorno distribuido, a menudo es necesario nombrar aplicaciones/servicios de manera uniforme para facilitar la identificación de diferentes servicios.

Similar a la correspondencia entre los nombres de dominio y las IP, las IP no son fáciles de recordar, pero los nombres de dominio son fáciles de recordar.
Obtenga la dirección, el proveedor y otra información de recursos o servicios por nombre.

2. Organice los nombres de servicios/aplicaciones en una estructura jerárquica.

El nombre del servicio y la información de la dirección se pueden escribir en ZooKeeper y el cliente puede obtener la lista de servicios disponibles a través de ZooKeeper.

gestión de la configuración

El programa se distribuye e implementa en diferentes máquinas, y la información de configuración del programa se coloca bajo el znode de ZooKeeper. Cuando cambia la configuración, es decir, cuando cambia el znode, puede cambiar el contenido de un nodo de directorio en zk para uso El reloj notifica a cada cliente para cambiar la configuración.

El diagrama de la estructura de gestión de la configuración de ZooKeeper es el siguiente:

1. En un entorno distribuido, la administración y sincronización de archivos de configuración es un problema común.

En un clúster, la información de configuración de todos los nodos es coherente, como el clúster de Hadoop.
Después de modificar el archivo de configuración, se espera que pueda sincronizarse rápidamente con cada nodo.

2. ZooKeeper puede implementar la gestión de la configuración.

La información de configuración se puede escribir en un Znode en ZooKeeper.
Cada nodo escucha este Znode.
Una vez que se modifican los datos en Znode, ZooKeeper notificará a cada nodo.

gestión de clústeres

La llamada gestión de clústeres es: si hay máquinas saliendo y uniéndose, y eligiendo el maestro.

La gestión de clústeres se refiere principalmente a la supervisión y el control de clústeres. El primero se enfoca en la recopilación del estado de ejecución del clúster, mientras que el segundo se enfoca en la operación y el control del clúster. En el desarrollo y operación y mantenimiento, frente a los clústeres, suelen existir los siguientes requisitos:

1. Quiere saber cuántas máquinas están trabajando en el clúster

2. Recopilar datos sobre el estado de tiempo de ejecución de cada máquina en el clúster

3. Realice operaciones en línea y fuera de línea en las máquinas del clúster

El diagrama de la estructura de gestión del clúster es el siguiente:

1. En un entorno distribuido, es necesario conocer el estado de cada nodo en tiempo real y se pueden realizar algunos ajustes según el estado en tiempo real de los nodos.

2. Puede ser implementado por ZooKeeper.

La información del nodo se puede escribir en un Znode en ZooKeeper.
Escuche este Znode para obtener sus cambios de estado en tiempo real.

3. Aplicaciones típicas

Seguimiento y elección del estado del maestro en Hbase.

El uso de la sólida consistencia de ZooKeeper puede garantizar la unicidad global de la creación de nodos en el caso de alta concurrencia distribuida, es decir, si hay varias solicitudes de clientes para crear nodos /currentMaster al mismo tiempo, solo se puede crear con éxito una solicitud de cliente en el fin

Notificación distribuida y coordinación

1. En un entorno distribuido, a menudo hay un servicio que necesita saber el estado de los subservicios que administra.

a) NameNode necesita saber el estado de cada Datanode.

b) JobTracker necesita saber el estado de cada TaskTracker.

2. El mecanismo de detección de latidos del corazón se puede realizar a través de ZooKeeper.

3. El envío de información puede ser realizado por ZooKeeper, que es equivalente a un sistema de publicación/suscripción.

bloqueo distribuido

Diferentes servicios en diferentes nodos pueden necesitar acceder a algunos recursos secuencialmente, y aquí se necesita un bloqueo distribuido.

Los bloqueos distribuidos tienen las siguientes características: bloqueos de escritura, bloqueos de lectura y bloqueos de temporización.

Bloqueo de escritura: un nodo temporal sin numerar creado en zk. Debido a que es un número desordenado, no se numerará automáticamente cuando se cree, por lo que solo un cliente puede obtener el bloqueo y luego escribir.

Bloqueo de lectura: cree un nodo numerado temporal en zk, de modo que incluso si el mismo nodo se crea al mismo tiempo cuando un cliente se une la próxima vez, se numerará automáticamente y el objeto de bloqueo se podrá obtener y luego leer.

Bloqueo de sincronización: un nodo numerado temporal creado en zk controla el bloqueo de acuerdo con el tamaño del número.

cola distribuida

Hay dos tipos de colas distribuidas:

1. Cuando todos los miembros de una cola están reunidos, la cola está disponible; de lo contrario, ha estado esperando a que lleguen todos los miembros. Esta es una cola síncrona.

a) Un trabajo consta de múltiples tareas, y el trabajo se ejecutará hasta completarse solo después de que se completen todas las tareas.

b) Se puede crear un directorio /job para el trabajo, y luego se crea un Znode temporal para cada tarea completada en este directorio. Una vez que el número de nodos temporales alcanza el número total de tareas, indica que el trabajo se completó.

2. La cola realiza operaciones de encolado y desencolado de acuerdo con el método FIFO, como implementar los modelos de productor y consumidor.

3. Cuéntame sobre el principio de funcionamiento de Zookeeper.

El núcleo de Zookeeper es la transmisión atómica, que garantiza la sincronización entre servidores. El protocolo que implementa este mecanismo se denomina protocolo Zab.

El protocolo Zab tiene dos modos, que son el modo de recuperación (elección maestra) y el modo de transmisión (sincronización).

El nombre completo del protocolo Zab es Zookeeper Atomic Broadcast** (Zookeeper Atomic Broadcast). Zookeeper utiliza el protocolo Zab para garantizar la coherencia final de las transacciones distribuidas. El protocolo Zab requiere que cada líder pase por tres etapas: descubrimiento, sincronización y transmisión.

Cuando el servicio se inicia o después de que el líder falla, Zab ingresa al modo de recuperación. Cuando se elige al líder y la mayoría de los servidores completan la sincronización de estado con el líder, el modo de recuperación finaliza. La sincronización de estado garantiza que el líder y el servidor tengan el mismo estado del sistema.

Para garantizar la coherencia secuencial de las transacciones, zookeeper utiliza un número de identificación de transacción incremental (zxid) para identificar las transacciones. Todas las propuestas tienen zxid agregado cuando se proponen. En la implementación, zxid es un número de 64 bits, y sus 32 bits superiores se usan por época para identificar si la relación del líder ha cambiado. Cada vez que se elige un líder, tendrá una nueva época, que identifica el período de gobierno actual. de ese líder. Los 32 bits inferiores se utilizan para contar hacia adelante.

Época: Puede entenderse como el nombre del año del emperador. Cuando se produzca un nuevo emperador líder, habrá un nuevo nombre de año de época.

Cada servidor tiene tres estados durante el proceso de trabajo:

BUSCANDO: El servidor actual no sabe quién es el líder y está buscando.
LÍDER: El servidor actual es el líder elegido.
SIGUIENTE: El líder ha sido elegido, y el Servidor actual está sincronizado con él.

4. Describa el mecanismo de notificación de Zookeeper.

Zookeeper le permite al cliente registrar un Watcher con un znode en el servidor. Cuando algunos eventos específicos en el servidor activan el Watcher, el servidor enviará una notificación de evento al cliente especificado para implementar la función de notificación distribuida, y luego el cliente seguirá el estado de Watcher Notify y los tipos de eventos para realizar cambios comerciales.

Se divide aproximadamente en tres pasos:

Registros de clientes Vigilante

1. Llame a las tres API getData, getChildren y exist, y pase el objeto Watcher. 2. Marque la solicitud y encapsule Watcher en WatchRegistration. 3. Encapsúlelo en un objeto de paquete y envíe la solicitud al servidor. 4. Después de recibir la respuesta del servidor, registre el Watcher en ZKWatcherManager para su administración. 5. Solicitud de devolución y completar el registro.

Vigilante de procesamiento del servidor

1. El servidor recibe y almacena Watcher. 2. Active el Watcher 3. Llame al método de proceso para activar el Watcher.

Vigilante de devolución de llamada del cliente

1. El subproceso SendThread del cliente recibe la notificación del evento y el subproceso EventThread devuelve la llamada al Watcher. 2. El mecanismo Watcher del cliente también es único, una vez activado, el Watcher no será válido.

El cliente creará un evento de observación para un determinado znode. Cuando el znode cambie, estos clientes recibirán la notificación zk y luego el cliente podrá realizar cambios comerciales de acuerdo con el cambio del znode.

5. ¿La notificación de vigilancia de Zookeeper al nodo es permanente?

No, único . Ya sea un servidor o un cliente, una vez que se activa un Watcher, Zookeeper lo eliminará del almacenamiento correspondiente. Este diseño reduce efectivamente la presión sobre el servidor, de lo contrario, para los nodos que se actualizan con mucha frecuencia, el servidor enviará continuamente notificaciones de eventos al cliente, lo que ejerce mucha presión tanto sobre la red como sobre el servidor.

6. ¿Cuáles son los roles en el clúster de Zookeeper?

En un clúster, se requieren al menos 3. O garantizar 2N + 1 unidades, que es un número impar. ¿Por qué se garantizan los números impares? Principalmente para el algoritmo de elección.

7. ¿Cuáles son los estados de trabajo de los servidores en el clúster de Zookeeper?

MIRANDO

Busque el estado del líder; cuando el servidor esté en este estado, pensará que no hay un líder en el clúster actual, por lo que debe ingresar al estado de elección del líder

SIGUIENTE

Estado de seguidor; indica que el rol actual del servidor es Seguidor

PRINCIPAL

Estado de líder; indica que el rol actual del servidor es Líder

OBSERVANDO

Estado de observador; indica que el rol actual del servidor es observador

8. ¿Cómo se elige al líder en el grupo Zookeeper?

Cuando el líder falla o pierde la mayoría de los seguidores, Zookeeper ingresa al modo de recuperación. El modo de recuperación necesita volver a elegir un nuevo líder, para que todos los servidores regresen a un estado de MIRADA.

Zookeeper tiene dos algoritmos de elección: basado en paxos básicos y basado en paxos rápidos. El valor predeterminado es paxos rápidos. Debido a problemas de espacio, aquí está la recomendación: [Distribuido] Elección del líder de Zookeeper

9. ¿Cómo asegura Zookeeper la consistencia secuencial de las transacciones?

Zookeeper usa una identificación de transacción incremental para identificar, y todas las propuestas (propuestas) se agregan con zxid cuando se proponen. zxid es en realidad un número de 64 bits.

La época utiliza los 32 bits superiores para identificar si el líder ha cambiado. Si se genera un nuevo líder, la época se incrementará. Los 32 bits inferiores se utilizan para contar hacia adelante. Cuando se genera una nueva propuesta, primero enviará una solicitud de ejecución de transacción a otros servidores de acuerdo con el proceso de dos etapas de la base de datos.Si más de la mitad de las máquinas pueden ejecutar y tener éxito, entonces comenzará la ejecución.

10. ¿Cómo se comunican los servidores entre sí en el clúster de ZooKeeper?

El servidor líder establecerá una conexión TCP con cada servidor seguidor/observador y creará una entidad llamada LearnerHandler para cada seguidor/observador.

LearnerHandler es el principal responsable de la comunicación de red entre el líder y el seguidor/observador, incluida la sincronización de datos, el reenvío de solicitudes y la votación de propuestas.
El servidor líder guarda todos los manejadores de aprendizaje de seguidores/observadores.

11. ¿Cómo se implementa el bloqueo distribuido de ZooKeeper?

Si hay N clientes, como el cliente 1 y el cliente 2, que compiten por un bloqueo distribuido de Zookeeper. Aproximadamente de la siguiente manera:

1. Todos aparecen y crean directamente nodos ordenados temporales uno tras otro bajo un nodo de bloqueo

2. Si no es el primer nodo, agregue un oyente a su nodo anterior

3. Siempre que el nodo anterior libere el bloqueo, se colocará en cola al frente, lo que equivale a un mecanismo de cola.

Y otro propósito de usar nodos secuenciales temporales es que no importa si un cliente se bloquea accidentalmente después de crear un nodo secuencial temporal, Zookeeper eliminará automáticamente el nodo secuencial temporal correspondiente cuando detecte que el cliente está inactivo. liberar automáticamente el bloqueo o cancelar automáticamente su propia cola.

Los bloqueos locales se pueden implementar con JDK, pero los bloqueos distribuidos deben usar componentes distribuidos. Como ZooKeeper, Redis. Hay una gran parte del código en línea, y las entrevistas generalmente no están escritas. Permítanme hablar sobre algunos puntos clave.

Algunos puntos a tener en cuenta son los siguientes.

Problema de interbloqueo: El bloqueo no puede convertirse en interbloqueo debido a un accidente, por lo que se utiliza un nodo temporal de ZK.Si la conexión del cliente falla, el bloqueo se liberará automáticamente.
Problema de espera de bloqueo: los bloqueos tienen requisitos de cola, por lo que se requieren los nodos secuenciales de ZK.
Problema de administración de bloqueo: cuando un usuario libera el bloqueo, se debe notificar a otros usuarios, por lo que se requiere monitoreo.
Efecto de rebaño del monitoreo: por ejemplo, si hay 1000 competidores de candados y se libera el candado, se notificará a 1000 competidores y luego se juzgará, el que tenga el número de serie más pequeño finalmente obtendrá el candado. Los otros 999 competidores se vuelven a registrar para escuchar. Este es el efecto rebaño, si algo sucede, todo el rebaño se alarmará. Cada competidor solo debe monitorear el nodo frente a él. Por ejemplo, si el número 2 abre el bloqueo, solo se notifica al número 3.

12. ¿Entiende la arquitectura del sistema de Zookeeper?

Las cosas principales que debemos entender y dominar en el diagrama de arquitectura de ZooKeeper son:

(1) ZooKeeper se divide en servidor (Servidor) y cliente (Cliente), y el cliente puede conectarse a cualquier servidor de todo el servicio de ZooKeeper (a menos que el parámetro leaderServes esté establecido explícitamente, el líder no puede aceptar conexiones de clientes).

(2) El cliente utiliza y mantiene una conexión TCP a través de la cual envía solicitudes, recibe respuestas, obtiene eventos observados y envía latidos. Si esta conexión TCP se interrumpe, el cliente intentará conectarse automáticamente a otro servidor de ZooKeeper. Cuando un cliente se conecta al servicio de ZooKeeper por primera vez, el servidor de ZooKeeper que acepta la conexión establece una sesión para el cliente. Cuando el cliente se conecta a otro servidor, el nuevo servidor restablecerá la sesión.

(3) Cada servidor de la figura anterior representa una máquina en la que está instalado el servicio Zookeeper, es decir, todo el clúster (o un pseudoclúster) que proporciona el servicio Zookeeper;

(4) Los servidores que componen el servicio de ZooKeeper deben conocerse entre sí. Mantienen una imagen de estado en memoria, así como registros de transacciones e instantáneas en almacenamiento persistente, y el servicio ZooKeeper está disponible siempre que la mayoría de los servidores estén disponibles;

(5) Cuando se inicia ZooKeeper, elegirá un líder de la instancia, y el líder es responsable de procesar las actualizaciones de datos y otras operaciones. Una operación de actualización exitosa se marca si y solo si la mayoría de los servidores modifican con éxito los datos en la memoria. Cada servidor almacena una copia de los datos en la memoria.

(6) Zookeeper se puede replicar en grupos y la coherencia de los datos se mantiene entre grupos a través del protocolo Zab (Zookeeper Atomic Broadcast);

(7) El protocolo Zab consta de dos fases: la fase de elección del líder y la fase Atomic Brodcast.

a) Se elegirá un líder en el clúster y las demás máquinas se llamarán seguidores. Todas las operaciones de escritura se envían al líder y todas las actualizaciones se informan al seguidor a través de brodcast.
b) Cuando el líder falla o el líder pierde la mayoría de los seguidores, se debe volver a elegir un nuevo líder para restaurar todos los servidores a un estado correcto.
c) Cuando se elige al líder y la mayoría de los servidores completan la sincronización de estado con el líder, el proceso de elección de líder ha terminado y entrará en el proceso de transmisión atómica.
d) Atomic Brodcast sincroniza la información entre el líder y el seguidor para garantizar que el líder y el seguidor tengan el mismo estado del sistema.

13. ¿Por qué Zookeeper está diseñado así?

El propósito del diseño de ZooKeeper es proporcionar servicios de coordinación distribuida secuencialmente coherentes, de alto rendimiento y alta disponibilidad, y garantizar la coherencia final de los datos.

Alto rendimiento (modelo de datos simple)

1. Organizar los nodos de datos en una estructura de árbol;

2. Todos los nodos de datos se almacenan en la memoria;

3. Seguidor y observador procesan directamente solicitudes no transaccionales;

Alta disponibilidad (construir clústeres)

1. Si más de la mitad de las máquinas sobreviven, el servicio puede funcionar normalmente

2. Elección automática de líder

Consistencia secuencial (orden de las operaciones de transacción)

1. Cada solicitud de transacción se enviará al líder para su procesamiento

2. A cada transacción se le asignará una identificación incremental única a nivel mundial (zxid, 64 bits: época + identificación de incremento automático)

eventual consistencia

1. Asegurar la confiabilidad de la presentación de transacciones al proponer la votación

2. El método de votación propuesto solo puede garantizar que más de la mitad de los nodos puedan ver los datos más recientes después de que el cliente reciba el envío exitoso de la transacción.

14. ¿Sabes qué roles hay en Zookeeper?

Modelo de sistema:

líder

El servidor Leader proporciona servicios de lectura y escritura para los clientes. Responsable de la iniciación y resolución de votaciones, así como de la actualización del estado del sistema.

aprendiz

Seguidor (follower) El servidor Seguidor proporciona servicios de lectura para los clientes, participa en el proceso de elección de líder y participa en la estrategia de operación de escritura "más de la mitad de las escrituras son exitosas".
Observer (observador) El servidor Observer proporciona servicios de lectura para el cliente, no participa en el proceso de elección de líder y no participa en la estrategia de operación de escritura "más de la mitad de las escrituras son exitosas". Se utiliza para mejorar el rendimiento de lectura del clúster sin afectar el rendimiento de escritura.

cliente

Iniciador de solicitud de servicio.

15. ¿Está familiarizado con el nodo ZNode de Zookeeper y los atributos relacionados?

¿Qué tipos de nodos hay?

Hay dos tipos de Znodos:

Persistente: después de desconectar el cliente y el servidor, el nodo creado no se eliminará (predeterminado).

Efímero: después de que el cliente y el servidor se desconectan, el nodo creado se elimina por sí mismo.

Znode tiene cuatro formas

Nodo de directorio persistente (PERSISTENT): después de que el cliente se desconecta de Zookeeper, el nodo aún tiene un nodo de directorio de número secuencial persistente (PERSISTENT_SEQUENTIAL)
Después de que el cliente se desconecta de Zookeeper, el nodo aún existe, pero Zookeeper numera secuencialmente el nombre del nodo: nodo de directorio temporal (EFÍMERO)
Después de que el cliente se desconecte de Zookeeper, el nodo se elimina: Nodo de directorio de número secuencial temporal (EPHEMERAL_SEQUENTIAL)
Después de que el cliente se desconecta de Zookeeper, el nodo se elimina, pero Zookeeper numera secuencialmente el nombre del nodo

"Nota" : Establezca el identificador de secuencia al crear un ZNode, y se agregará un valor después del nombre del ZNode. El número de secuencia es un contador que aumenta monótonamente mantenido por el nodo principal.

¿Cuáles son los atributos del nodo?

Un nodo znode no solo puede almacenar datos, sino que también tiene otras propiedades especiales. A continuación, creamos un nodo /test para analizar el significado de sus diversos atributos.

[zk: host local: 2181 (CONECTADO) 6] obtener / probar

456

cZxid = 0x59ac //

ctime = lun 30 de marzo 15:20:08 CST 2020

mZxid = 0x59ad

mtime = lun 30 de marzo 15:22:25 CST 2020

pZxid = 0x59ac

cversión = 0

versión de datos = 2

aclVersión = 0

propietario efímero = 0x0

longitud de datos = 3

numChildren = 0

descripción de propiedad

16. Describa brevemente el proceso de selección de maestro de Zookeeper

El núcleo de Zookeeper es la transmisión atómica, que garantiza la sincronización entre servidores. El protocolo que implementa este mecanismo se denomina protocolo Zab. El protocolo Zab tiene dos modos, que son el modo de recuperación (elección maestra) y el modo de transmisión (sincronización). Cuando el servicio se inicia o después de que el líder falla, Zab ingresa al modo de recuperación. Cuando se elige al líder y la mayoría de los servidores completan la sincronización de estado con el líder, el modo de recuperación finaliza. La sincronización de estado garantiza que el líder y el servidor tengan el mismo estado del sistema. La elección del líder es la clave para garantizar la consistencia de los datos distribuidos.

Hay dos escenarios principales para las elecciones: inicialización y líder no disponible.

Cuando se produzca una de las dos situaciones siguientes en un servidor del clúster zk, comenzará la elección del líder.

(1) El servidor se inicializa y se inicia.

(2) La conexión con el líder no se puede mantener durante la ejecución del servidor.

Cuando una máquina ingresa al proceso de elección de líder, el clúster actual también puede estar en los siguientes dos estados.

(1) Ya hay un líder en el clúster.

(2) De hecho, no hay líder en el grupo.

En primer lugar, en el primer caso, por lo general, cierta máquina en el clúster se inicia relativamente tarde y, antes de que se inicie, el clúster ha estado funcionando normalmente, es decir, ya hay un servidor líder. Cuando la máquina intente elegir un líder, se le informará la información del líder del servidor actual, solo necesita establecer una conexión con la máquina líder y realizar una sincronización de estado.

El punto clave es que el líder no está disponible y el sistema de selección de líderes en este momento.

La información de votación contiene dos datos básicos.

sid: la identificación del servidor, que se utiliza para identificar el número de serie de la máquina en el clúster.

zxid: el número de identificación de la transacción del cuidador del zoológico.

Cada cambio de estado de ZooKeeper corresponde a un ID de transacción incrementado, que se denomina zxid.Debido a la naturaleza incremental de zxid, si zxid1 es más pequeño que zxid2, entonces zxid1 debe ocurrir antes que zxid2. Crear cualquier nodo, actualizar los datos de cualquier nodo o eliminar cualquier nodo hará que cambie el estado de Zookeeper, lo que dará como resultado un aumento en el valor de zxid.

Una información de votación se identifica en forma de (sid, zxid).

Por ejemplo: si el servidor actual quiere recomendar un servidor con sid de 1 y zxid de 8 para convertirse en el líder, la información de votación se puede expresar como (1, 8)

Después de que cada máquina del clúster envía su propio voto, también acepta votos de otras máquinas del clúster. Cada máquina procesará los votos recibidos de otras máquinas de acuerdo con ciertas reglas, para decidir si cambia su propio voto.

Las reglas son las siguientes:

(1) En la etapa inicial, todos votarán por sí mismos.

(2) Al recibir votos de otros servidores, es necesario comparar los votos de otras personas con sus propios votos. Las reglas son las siguientes: verifique zxid primero. El servidor con un zxid más grande tiene prioridad como líder. Si el zxid es el mismo, se compara el sid y el servidor con el sid más grande es el líder.

El proceso de elección cuando comienzan todos los servicios:

Tres servidores servidor1, servidor2, servidor3:

1. se inicia server1, no se elegirá una máquina.

2. Inicie el servidor 2, cambie el estado del servidor 1 y el servidor 2 para mirar, transmitir la votación

3. Server3 se inicia, el estado cambia a buscando y se une a la votación de difusión.

4. En el estado de conocimiento por primera vez, todos no se conocen, todos piensan que son el rey y votan por sí mismos como el líder.

5. Instrucciones para la información de votación.La información de votación es originalmente una tupla quíntuple.Aquí, para mayor claridad de lógica, la expresión se simplifica.

Por primera vez zxid = 0, y sid es el nombre de cada nodo, este sid se configura en zoo.cfg y no se repetirá.

1. Zxid inicial = 0, votos del servidor 1 (1, 0), votos del servidor 2 (2, 0), votos del servidor 3 (3, 0)

2. Cuando server1 recibe el voto (2, 0), primero verificará la legitimidad del voto y luego pk su propio voto. La lógica de pk es comparar zxid primero, server1 (zxid) = server2 (zxid) = 0, zxid es igual Luego compare sid, server1 (sid) < server2 (sid), pk, el resultado es que gana el voto de server2. server1 actualiza su voto a (2, 0) y server1 vota nuevamente.

3. TODO Si es 2 o 3 al final aquí debe determinarse a través de experimentos.

4. Cuando el servidor 2 recibe el voto del servidor 1, primero verificará la legitimidad del voto y luego pk, su propio voto gana, el servidor no necesita actualizar su propio voto, después de pk, volverá a enviar el voto nuevamente.

5. Contar los votos.Después de pk, se contarán los votos.Si más de la mitad de los nodos emiten el mismo voto, se determina que el Líder ha sido elegido.

6. Una vez finalizada la elección, el estado del nodo seleccionado cambia de BUSCANDO a LÍDER, y el estado de otros nodos que participan en la elección cambia de BUSCANDO a SIGUIENTE. Si hay un nodo Observador, si el Observador no participa en la elección, su estado siempre es OBSERVANDO antes y después de la elección, sin ningún cambio.

hablando en general

Comience a votar -> el estado del nodo se convierte en MIRANDO -> cada nodo se elige a sí mismo -> recibe votos para PK -> gana Big Sid -> actualiza los votos -> vota nuevamente -> cuenta los votos, más de la mitad de los resultados de los votos -> el estado del nodo se actualiza al estado de su propio personaje.

17. ¿Por qué el número de grupos de Zookeeper es generalmente impar?

En primer lugar, es necesario aclarar las reglas de elección del cuidador del zoológico: la elección del líder requiere el número de nodos disponibles > número total de nodos/2.

Por ejemplo: Marcar si una escritura es exitosa se considera válido solo cuando más de la mitad de los nodos envían la solicitud de escritura con éxito. Del mismo modo, la elección del nodo líder de Zookeeper solo es válida cuando más de la mitad de los nodos están de acuerdo. Finalmente, si Zookeeper es normal depende de si más de la mitad de los nodos son normales. Esto se basa en el principio de consistencia de CAP.

Zookeeper tiene una característica de este tipo: siempre que más de la mitad de las máquinas del clúster funcionen normalmente, todo el clúster está disponible para el mundo exterior.

Es decir, si hay 2 cuidadores del zoológico, mientras 1 cuidador del zoológico esté muerto, el cuidador del zoológico no se puede usar, porque 1 no es más de la mitad, por lo que la tolerancia a la muerte de 2 cuidadores del zoológico es 0;

Del mismo modo, si hay 3 zookeepers, uno de ellos está muerto, y quedan 2 normales, más de la mitad, por lo que la tolerancia de 3 zookeepers es 1;

Del mismo modo:

2->0; dos cuidadores del zoológico, hasta 0 cuidadores del zoológico pueden no estar disponibles.
3->1; tres cuidadores del zoológico, como máximo un cuidador del zoológico puede no estar disponible.
4->1; cuatro cuidadores del zoológico, como máximo un cuidador del zoológico puede no estar disponible.
5->2; cinco cuidadores del zoológico, hasta 2 cuidadores del zoológico pueden no estar disponibles.
6->2; dos cuidadores del zoológico, como máximo 0 cuidadores del zoológico pueden no estar disponibles.
....

Encontrará una regla de que la tolerancia de 2n y 2n-1 es la misma, ambos son n-1, así que para ser más eficiente, ¿por qué agregar ese cuidador de zoológico innecesario?

La estrategia de elección de Zookeeper también requiere que más de la mitad de los nodos acepten ser el líder.Si hay nodos pares, puede llevar a la misma cantidad de votos.

18. ¿Conoces el principio del oyente Zookeeper?

1. Cree un subproceso Main().

2. Cree dos subprocesos en el subproceso Main(), uno es responsable de la comunicación de conexión de red (conectar) y el otro es responsable de escuchar (escucha).

3. Envíe el evento de escucha registrado a Zookeeper a través del hilo de conexión.

4. Agregue el evento de escucha registrado a la lista de oyentes registrados de Zookeeper.

5. Cuando Zookeeper detecta que hay cambios en los datos o en la ruta, envía este mensaje al subproceso de escucha.

6. El método process() se llama dentro del hilo Listener

19. Hable sobre el mecanismo de control de permisos de ACL en Zookeeper

UGO（Usuario/Grupo/Otros）

Actualmente se utiliza en el sistema de archivos Linux/Unix y también es el método de control de permisos más utilizado. Es un modo de control de permisos del sistema de archivos de granularidad gruesa.

Lista de control de acceso ACL (Lista de control de acceso)

Incluyendo tres aspectos:

Modo de permiso (esquema)

(1) IP: control de permisos desde la granularidad de la dirección IP

(2) Resumen: el más utilizado, que utiliza un identificador de permisos similar a nombre de usuario: contraseña para la configuración de permisos, que es conveniente para distinguir diferentes aplicaciones para el control de permisos.

(3) Mundo: el método de control de permisos más abierto, que es un modo de resumen especial con solo un identificador de permiso "mundo: cualquiera"

(4) Súper: súper usuario

objeto autorizado

El objeto de autorización se refiere al usuario al que se le otorga la autorización o una entidad específica, como una dirección IP o una luz de máquina.

Permiso

(1) CREAR: Autoridad de creación de nodos de datos, que permite que los objetos autorizados creen nodos secundarios bajo este Znode

(2) ELIMINAR: permiso de eliminación de nodos secundarios, lo que permite que el objeto autorizado elimine los nodos secundarios del nodo de datos

(3) LECTURA: El permiso de lectura del nodo de datos, que permite que el objeto autorizado acceda al nodo de datos y lea su contenido de datos o la lista de nodos secundarios, etc.

(4) ESCRIBIR: autoridad de actualización del nodo de datos, lo que permite que el objeto autorizado actualice el nodo de datos

(5) ADMIN: autoridad de gestión del nodo de datos, que permite que los objetos autorizados realicen operaciones de configuración relacionadas con ACL en el nodo de datos

20. ¿Cuáles son los modos de implementación de Zookeeper?

Zookeeper tiene tres modos de implementación:

1. Implementación independiente: se ejecuta en un clúster;

2. Implementación de clústeres: varios clústeres en ejecución;

3. Implementación de pseudoclúster: un clúster inicia la ejecución de varias instancias de Zookeeper.

21. ¿El clúster de Zookeeper admite la adición dinámica de máquinas?

De hecho, es expansión horizontal, y Zookeeper no es muy bueno en ese sentido. Dos caminos:

Reiniciar todo: cierra todos los servicios de Zookeeper y los inicia después de modificar la configuración. Las sesiones de clientes anteriores no se ven afectadas.

Reiniciar uno por uno: bajo el principio de que más de la mitad de las máquinas están vivas y disponibles, reiniciar una máquina no afecta los servicios externos proporcionados por todo el clúster. Esta es la forma más común.

La versión 3.5 comenzó a admitir la expansión dinámica.

22. Describa el protocolo ZAB

El protocolo ZAB es un protocolo definido por el propio ZooKeeper, y su nombre completo es protocolo de transmisión atómica ZooKeeper.

El protocolo ZAB tiene dos modos: cómo recuperarse cuando el nodo líder falla y cómo transmitir mensajes a todos los nodos.

Cuando todo el clúster de ZooKeeper no tiene un nodo líder, se bloquea. Por ejemplo, el inicio del clúster acaba de comenzar y los nodos no se conocen en este momento. Por ejemplo, la operación del nodo líder está inactiva o hay un problema de red y otros nodos no pueden hacer ping al nodo líder. En este momento, se requiere el protocolo de colapso de nodos en ZAB, y todos los nodos ingresan al modo de elección para elegir un nuevo líder. Todo el proceso electoral se realiza por radiodifusión. Después de que la elección sea exitosa, todo debe basarse en los datos del líder, por lo que se requiere sincronización de datos.

23. ¿Cuál es la conexión y la diferencia entre el algoritmo ZAB y Paxos?

Mismo punto:

(1) Ambos tienen una función similar al proceso Líder, que es responsable de coordinar la operación de múltiples procesos Seguidor

(2) El proceso de Líder esperará a que más de la mitad de los Seguidores brinden comentarios correctos antes de enviar una propuesta.

(3) En el protocolo ZAB, cada Propuesta contiene un valor de época para representar el ciclo Líder actual, y el nombre en Paxos es Ballot

diferencia:

ZAB se usa para construir un sistema maestro y de copia de seguridad de datos distribuidos de alta disponibilidad (Zookeeper), y Paxos se usa para construir un sistema de máquina de estado consistente distribuido.

24. ¿Cómo lidiar con el tiempo de inactividad de ZooKeeper?

ZooKeeper en sí también es un clúster y se recomienda configurar un número impar de servidores. Debido al tiempo de inactividad, se requieren elecciones, y la elección necesita la mitad de +1 votos para ser aprobada, a fin de evitar un empate. Entra sin un número par de servidores.

Si el seguidor está caído, no importa y no afecta ningún uso. Los usuarios no se dan cuenta. Si el líder falla, el clúster debe detener los servicios externos y comenzar las elecciones. Después de elegir un nodo líder, se realiza la sincronización de datos para garantizar que los datos de todos los nodos y el líder estén unificados, y luego comienzan los servicios externos.

¿Por qué los votos requieren la mitad + 1? Si la mitad es suficiente, los problemas de red pueden hacer que el clúster elija dos líderes, cada uno con la mitad de los hermanos menores apoyándolo, por lo que los datos se desordenarán.

25. Describa la idea de la gestión de sesiones en ZooKeeper.

Estrategia de cubo:

En pocas palabras, las diferentes caducidades de sesión pueden tener intervalos de tiempo, como 15 segundos, 15,1 segundos y 15,8 segundos. ZooKeeper caduca uniformemente estas sesiones en 16 segundos. Esto es muy conveniente para la gestión. Consulte la fórmula a continuación. El tiempo de caducidad siempre es un múltiplo entero de ExpirationInterval.

Fórmula de cálculo:

ExpirationTime = currentTime + sessionTimeout

ExpirationTime = (ExpirationTime / ExpirationInrerval + 1) * ExpirationInterval ,

ver imagen:

El tiempo de espera de la sesión configurado por defecto es 2tickTime~20tickTime.

26. ¿Cuál es la diferencia entre el balanceo de carga de ZooKeeper y el balanceo de carga de Nginx?

Guardián del zoológico：

No existe un problema de un solo punto, y el mecanismo zab garantiza que un solo punto de falla pueda reelegir a un Líder
Solo responsable del registro y descubrimiento de servicios, no para el reenvío, reduciendo un intercambio de datos (comunicación directa entre el consumidor y el servidor)
Debe implementar el algoritmo de equilibrio de carga correspondiente usted mismo

Nginx:

Hay un problema de punto único, la carga de punto único es alta y el volumen de datos es grande, y KeepAlived necesita la asistencia para lograr una alta disponibilidad
Cada carga actúa como un rol de reenvío intermediario, que a su vez es un servidor proxy inverso
Algoritmo de equilibrio de carga incorporado

27. Hablar sobre la serialización de ZooKeeper

Publicación por entregas:

Los datos de la memoria deben serializarse al guardarlos en el disco duro.
Los datos de la memoria, transmitidos a otros nodos a través de la red, deben serializarse.

El protocolo de serialización utilizado por ZK es Jute, que proporciona la interfaz Record. La interfaz proporciona dos métodos:

serializar método de serialización
deserialize método de deserialización

El método que se va a serializar se puede almacenar en el objeto de flujo en estos dos métodos.

28. ¿Qué es Zxid en Zookeeper y qué hace?

Zxid, es decir, el id de la transacción, para garantizar la coherencia secuencial de la transacción, ZooKeeper utiliza la transacción incremental Zxid para identificar la transacción. Zxid se agregará a la propuesta. Zxid es un número de 64 bits, y Epoch utiliza sus 32 bits superiores para identificar cambios de dinastía. Por ejemplo, Epoch se cambiará cada vez que se realice una elección. Los 32 bits inferiores se utilizan para contar.

Época: Se puede entender como la edad o ciclo del cúmulo actual, cada Líder es como un emperador y tiene su propio nombre de año, por lo tanto, cada vez que cambie la dinastía, el Líder sumará 1 a la era anterior después del cambio. De esta manera, incluso después de que el antiguo Líder se estrelle y se recupere, nadie lo escuchará, porque el Seguidor solo obedece las órdenes del líder actual.

29. Explicar el mecanismo de persistencia de ZooKeeper

¿Qué es la persistencia?

Datos, almacenados en disco o en un archivo.
Después de que la máquina se reinicie, los datos no se perderán. El mapeo de memoria -> disco es algo similar a la serialización.

Persistencia de ZooKeeper:

Instantánea SnapShot, grabando la cantidad total de datos en la memoria
TxnLog Registro de transacciones incrementales, registrando cada registro de adición, eliminación y modificación (la verificación no es un registro de transacciones y no provocará cambios en los datos)

¿Por qué la persistencia es una molestia? ¿No hay una disponible?

La desventaja de la instantánea es que el archivo es demasiado grande y el archivo de la instantánea no tendrá los datos más recientes. La desventaja del registro de transacciones incremental es que lleva mucho tiempo ejecutarlo, hay demasiados registros y la carga es demasiado lenta. Una combinación de los dos funciona mejor.

Modo de instantánea:

Los datos almacenados en la memoria de ZooKeeper en la estructura de datos DataTree se almacenan periódicamente en el disco.
Dado que el archivo de instantánea es una copia de seguridad completa regular de los datos, los datos del archivo de instantánea no suelen ser los más recientes.

ver imagen:

30. ¿Cuál es la tupla quíntuple de información de votación en la elección de Zookeeper?

Líder: SID del Líder electo
Zxid: el ID de transacción del líder elegido
Sid: SID del servidor actual
choiceEpoch: la ronda actual de votaciones
peerEpoch: Época del servidor actual

Época > Zxid > Sid

Tanto Epoch como Zxid pueden ser iguales, pero Sid debe ser diferente, por lo que los dos votos definitivamente darán como resultado PK.

31. ¿Hablar sobre el cerebro dividido en Zookeeper?

En pocas palabras, Split-Brain significa que cuando hay dos nodos en su clúster, ambos saben que se debe elegir un maestro en este clúster. Luego, cuando no haya problemas con la comunicación entre los dos, se llegará a un consenso y uno de ellos será seleccionado como maestro. Pero si hay un problema con la comunicación entre ellos, los dos nodos sentirán que ahora no hay un maestro, por lo que cada uno se elige a sí mismo como el maestro, por lo que habrá dos maestros en el clúster.

Para Zookeeper, hay una pregunta muy importante, es decir, ¿qué tipo de situación se usa para juzgar si un nodo está muerto o caído? En un sistema distribuido, estos son juzgados por monitores, pero también es difícil para los monitores determinar el estado de otros nodos. La única forma confiable es el latido del corazón. Zookeeper también usa el latido del corazón para determinar si el cliente todavía está vivo.

Usar ZooKeeper para hacer Leader HA es básicamente de la misma manera: cada nodo intenta registrar un nodo temporal que simboliza al líder, y otros que no logran registrarse se convierten en seguidores, y monitorean los nodos temporales creados por el líder a través del mecanismo de vigilancia. El mecanismo de latido interno se utiliza para determinar el estado del líder. Una vez que le ocurre un accidente al líder, Zookeeper puede enterarse rápidamente y notificar a otros seguidores, y otras flores responderán en consecuencia, completando así un cambio. Parte de esto está hecho . Pero aquí hay un problema muy serio. Si no lo nota, causará una división del cerebro en el sistema en un corto período de tiempo. Debido a que el tiempo de espera del latido del corazón puede ser que el líder cuelgue, pero también puede ser un problema con la red entre los nodos de Zookeeper, lo que resultó en que el líder En el caso de la animación suspendida, el líder en realidad no murió, pero un problema con la red con ZooKeeper hizo que Zookeeper pensara que estaba inactivo y luego notificó a otros nodos para que cambiaran. de modo que uno de los seguidores se convirtió en el líder, pero el líder original no En este momento, el cliente también recibe el mensaje de cambio de líder, pero aún habrá algunas demoras. Zookeeper necesita comunicarse y debe ser notificado uno por uno . En este momento, todo el sistema es muy caótico. Tal vez se haya notificado a algunos clientes que se conecten al nuevo líder. , Algunos clientes aún están conectados al antiguo líder. Si dos clientes necesitan actualizar los mismos datos del líder en el Al mismo tiempo, y estos dos clientes están conectados con los líderes antiguos y nuevos en este momento, se producirán problemas graves.

Aquí hay un breve resumen: Fingir muerte: se cree que el líder está muerto debido a un tiempo de espera de latido (causado por razones de red), pero en realidad el líder todavía está vivo. Cerebro dividido: debido a la animación suspendida, se iniciará una nueva elección de líder para elegir un nuevo líder, pero la red de líder anterior se vuelve a conectar, lo que da como resultado dos líderes, algunos clientes se conectan al líder anterior y otros clientes luego se conectan a la nuevo líder

32. ¿Qué causa el cerebro dividido de Zookeeper?

La razón principal es que el clúster de Zookeeper y el cliente de Zookeeper no se pueden sincronizar por completo al evaluar el tiempo de espera. Al mismo tiempo, también hay una secuencia de velocidades para notificar a cada cliente después del descubrimiento y el cambio. En general, la probabilidad de esta situación es muy pequeña y el nodo líder debe desconectarse de la red del clúster de Zookeeper, pero no hay problema con la red entre otros roles del clúster y las condiciones anteriores deben cumplirse, pero una vez que ocurre , causará graves consecuencias Los datos son inconsistentes.

33. ¿Cómo resuelve Zookeeper el problema del cerebro dividido?

Para resolver el problema del Split-Brain, generalmente existen los siguientes métodos: Método de Quórums (quórum): Por ejemplo, en un clúster con 3 nodos, Quórums = 2, es decir, el clúster puede tolerar la falla de 1 nodo. Se puede elegir un líder y el grupo todavía está disponible. Por ejemplo, para un clúster con 4 nodos, sus quórumes = 3 y los quórumes deben exceder 3, lo que significa que la tolerancia del clúster sigue siendo 1. Si fallan dos nodos, el clúster completo sigue siendo inválido. Este es el método predeterminado utilizado por el cuidador del zoológico para evitar el "cerebro dividido".

Se utiliza el modo de comunicaciones redundantes (comunicación redundante): se utilizan múltiples modos de comunicación en el clúster para evitar que los nodos del clúster no puedan comunicarse debido a la falla de un modo de comunicación.

Método de vallado (recursos compartidos): Por ejemplo, si puede ver los recursos compartidos, significa que está en el clúster. El líder que puede obtener el candado de los recursos compartidos es el líder. Si no puede ver los recursos compartidos, recursos, no está en el clúster.

De hecho, es muy sencillo evitar la "división del cerebro" del guardián del zoológico. Cuando el nodo seguidor cambia, no lo hace inmediatamente después de comprobar que hay un problema con el antiguo nodo líder, sino que duerme durante un período de tiempo suficiente para garantizar que el antiguo líder ha sido informado del cambio y Después de realizar el trabajo de limpieza de apagado relevante y luego registrarse como el maestro, este tipo de problema puede evitarse. El tiempo de suspensión generalmente se define como el período de tiempo de espera definido por zookeeper, pero es posible que el sistema no sea disponible durante este período, pero vale la pena por las consecuencias de los datos inconsistentes.

1. ZooKeeper adopta Quórums de forma predeterminada para evitar el fenómeno de "cerebro dividido". Es decir, solo más de la mitad de los nodos del clúster votan para elegir un Líder. De esta manera se puede asegurar la unicidad del líder, ya sea que se elija al único líder o que la elección fracase. El papel de los quórumes en zookeeper es el siguiente:

El número mínimo de nodos en el clúster se usa para elegir un líder para garantizar que el clúster esté disponible.
Informe a los clientes que la cantidad mínima de nodos en el clúster ha guardado los datos antes de que los datos se guarden de forma segura. Una vez que estos nodos hayan guardado los datos, se notificará al cliente que se ha guardado de forma segura y puede continuar con otras tareas. Los nodos restantes en el clúster eventualmente también contendrán los datos.

Suponiendo que un líder muere en animación suspendida, el resto de los seguidores elige un nuevo líder. En este momento, el antiguo líder revive y todavía se considera líder. En este momento, también se rechazará enviar solicitudes de escritura a otros seguidores. Porque cada vez que se genera un nuevo líder, se generará una etiqueta de época (que identifica el período de gobierno actual del líder). Esta época es incremental. Si los seguidores confirman la existencia del nuevo líder y conocen su época, rechazarán la época. siendo más pequeño que el líder actual.Todas las solicitudes de época. ¿Hay algún seguidor que no conozca la existencia del nuevo líder?, es posible, pero seguro que no la mayoría, de lo contrario no se puede generar el nuevo líder. La escritura de Zookeeper también sigue el mecanismo de quórum. Por lo tanto, la escritura que no es apoyada por la mayoría es inválida. Incluso si el antiguo líder se considera líder, todavía no tiene efecto.

Además de utilizar el método de quórum predeterminado anterior para evitar el "cerebro dividido", el cuidador del zoológico también puede tomar las siguientes medidas preventivas: 2. Agregar líneas de latidos cardíacos redundantes, como líneas de doble línea, para minimizar la posibilidad de "cerebro dividido". 3. Habilite el bloqueo de disco. La parte servidora bloquea el disco compartido y, cuando se produce un "cerebro dividido", la otra parte es completamente "incapaz de quitar" los recursos del disco compartido. Pero el uso de un disco bloqueado también tiene un gran problema: si la parte que ocupa el disco compartido no "desbloquea" activamente, la otra parte nunca obtendrá el disco compartido. En realidad, si el nodo de servicio falla repentinamente o falla, es imposible ejecutar el comando de desbloqueo. El nodo de copia de seguridad no puede hacerse cargo de los recursos compartidos y los servicios de aplicaciones. Así que alguien diseñó una cerradura "inteligente" en HA. Es decir, la parte servidora solo habilita el bloqueo del disco cuando descubre que todas las líneas de latido están desconectadas (no se puede detectar el extremo del par). Por lo general, no está bloqueado. 4. Establecer un mecanismo de arbitraje. Por ejemplo, establezca una IP de referencia (como la IP de la puerta de enlace). Cuando la línea de latido del corazón esté completamente desconectada, ambos nodos harán ping a la IP de referencia. Si falla, significa que el punto de interrupción está en el extremo local, no solo en el "latido del corazón". , pero también "servicio" externo. Si el enlace de red local del extremo local se rompe, incluso si el servicio de la aplicación se inicia (o continúa), es inútil, por lo que la competencia se abandona voluntariamente y el extremo que puede hacer ping la IP de referencia puede iniciar el servicio. Para estar más seguro, la parte que no puede hacer ping a la IP de referencia simplemente se reinicia para liberar por completo los recursos compartidos que aún pueden estar ocupados.

34. ¿Cuénteme acerca de las compensaciones realizadas en el tema CAP de Zookeeper?

Coherencia C : Zookeeper es un sistema de consistencia fuerte. Para garantizar una disponibilidad sólida, el método de sincronización de datos de "más de la mitad de éxito significa éxito" puede causar inconsistencia de datos en algunos nodos. Por lo tanto, Zookeeper también proporciona la operación sync() para sincronizar los datos de todos los nodos, lo que deja la elección de C y A al usuario, porque el uso de sync() inevitablemente prolongará el tiempo de sincronización y provocará cierta pérdida de disponibilidad.

Disponibilidad A : los datos de Zookeeper se almacenan en la memoria y cada nodo puede responder a las solicitudes de lectura, con un buen rendimiento de respuesta. Zookeeper garantiza que los datos estén siempre disponibles sin bloqueos. Y más de la mitad de los nodos tienen los datos más recientes.

Tolerancia de partición P : Demasiados nodos seguidores aumentarán el retraso de la sincronización de datos (más de la mitad de los seguidores necesitan terminar de escribir y confirmar). Al mismo tiempo, la velocidad de convergencia del proceso electoral será más lenta y la disponibilidad se verá reducida. Zookeeper alivia este problema mediante la introducción de nodos de observador. Después de agregar nodos de observador, el clúster puede aceptar más nodos para las solicitudes de los clientes y los observadores no participan en la votación, lo que puede mejorar la disponibilidad y la escalabilidad, pero la sincronización de datos de múltiples nodos siempre es un problema. por lo que la consistencia disminuirá.

35. ¿Por qué el seguimiento del reloj es único?

Si el servidor cambia con frecuencia y hay muchos clientes de monitoreo, todos los clientes deben ser notificados de cada cambio, lo que ejerce mucha presión sobre la red y el servidor.

Generalmente, el cliente ejecuta getData(node A,true). Si se cambia o elimina el nodo A, el cliente obtendrá su evento de observación, pero luego el nodo A cambia nuevamente y el cliente no configura el evento de observación. Es ya no se envía al cliente.

En aplicaciones prácticas, en muchos casos, nuestro cliente no necesita saber cada cambio del servidor, solo necesito los datos más recientes.