Lectura 37 del código fuente de zk: análisis del código fuente de ZooKeeperServer
La sección anterior resumió el proceso desde el inicio del servidor hasta la elección del líder. Ahora vamos a ingresar al proceso de interacción de inicio entre el líder y el seguidor, lo que requiere hablar primero sobre ZooKeeperServer.
En la Sección 25 de la interpretación del código fuente anterior, se propuso una parte del código fuente. Aquí explicamos el código fuente de ZooKeeperServer en detalle. El código fuente de ZooKeeperServer se explicará en detalle aquí
Su relación de herencia es la siguiente
El contenido principal de esta sección es el siguiente
Ha sido Explicado en la Sección 24 de Interpretación del código fuente, no entraré en detalles aquí
Es la interfaz interna de SessionTracker
Como se muestra en la siguiente figura
Excluyendo las partes relacionadas con log y jmx, el código fuente es el siguiente
ChangeRecord es una clase interna de ZooKeeperServer, que se presentará a continuación
ServerStats y ZooKeeperServerListener se introducirán en el código fuente de la Sección 25
Esta clase no se llamará, así que no te preocupes
Definir excepciones
Esta es la primera vez que se llama a la clase ZooKeeperServer . Estructura de datos para facilitar el intercambio de información de PrepRequestProcessor y FinalRequestProcessor. Hablemos de ello cuando hablemos de la cadena de llamadas.
Entre ellos, StatPersisted leyó 7 DataNodes en el código fuente. No entraré en detalles sobre el momento.
Descripción del estado actual del servidor.
Las siguientes son las dos capas inferiores Lista de llamadas al constructor
La base de datos que comienza a participar en la carga de datos, y hay dos tipos de clúster e independiente, el orden de llamada
Hay principalmente dos tipos de clústeres y máquinas independientes, el orden de llamada
Hay dos tipos de clústeres y máquinas independientes El orden de llamada para instalar la cadena de procesamiento de solicitudes es PrepRequestProcessor -gt; SyncRequestProcessor -gt; el orden de FinalRequestProcessor
Los detalles se discutirán más adelante en la cadena de procesamiento de solicitudes
Las dos funciones getServerId y expire
ProcessConnectRequest se utilizan para procesa la solicitud de conexión del cliente y no se expande.
La parte digna de mención es la llamada de reconexión
Expandir de la siguiente manera
Función principal de reconexión
Verificar la exactitud del ID de sesión y la contraseña entrante
Generar contraseña basada en el ID de sesión
En el seguimiento de sesiones Determinar si la sesión aún es pequeña en SessionTracker
Completar la inicialización de la sesión, representa el paso o falla de autenticación de acuerdo con la validez del parámetro, determina si el servidor recibe la solicitud de conexión o emite una solicitud para cerrar la conexión, no expanda, ¡importante!
Además de las funciones relacionadas con get, set, jmx y apagado, las otras funciones importantes son las siguientes
Algunas funciones son las siguientes
Obtener el zxid de En el siguiente servidor, la persona que llama debe asegurarse de que el orden de concurrencia esté controlado.
La función ZooKeeperServer#expire anterior llama a la función de cierre, que introduce la función ZooKeeperServer#expire, que es la primera función en ZooKeeperServer# función de caducidad. El ZooKeeperServer#expire anterior llama a la función de cierre, que se describe a continuación
Esta función se utiliza para enviar una solicitud para cerrar el ID de sesión
Hay dos funciones aquí
Antes de que se borre la sesión Como se explica en el código fuente de la Sección 21 "Gestión de sesiones", los registros de sessionTracker se borrarán inmediatamente, mientras que la eliminación de sesiones temporales se completa gradualmente a través de la cadena de llamadas en DateTree. El borrado de sesiones temporales en DateTree se realiza paso a paso a través de la cadena de llamadas, lo que significa que los dos pasos no están sincronizados, por lo que si el estado del servidor cambia a mitad de camino, habrá inconsistencias
requestInProcess representa el proceso que se está procesando Número de solicitudes
Es decir, solicitudes en proceso 1 cuando se realiza una solicitud; solicitudes en proceso 1 cuando la solicitud finalmente se completa y solicitudes en proceso 1. Esto involucra la cadena de procesamiento de solicitudes, cuando se realiza la solicitud, requestInProcess 1, y cuando finalmente se completa la solicitud, requestInProcess-1.
Llamada a ZooKeeperServer#checkPasswd
ZooKeeperServer#generatePasswd
Esto es solo una cuestión de que sessionId coincida con el primer número aleatorio generado por sessionId^superSecret
Es solo cuestión de que la contraseña no sea un número aleatorio. p>
La contraseña no se establece en el cliente, sino que se genera en función del ID de sesión
La llamada opensession en ZooKeeperServer#processConnectRequest
Como se mencionó anteriormente, Core
Aún no lo he analizado en profundidad, hablemos primero de las dudas
Por ejemplo, piense por qué los datos mencionados en loadData son inconsistentes y pertenecen a algún tipo de manejo de excepciones
¿Por qué no ponerlo en otra clase?