Zookeeper (VII): modo de clúster del lado del servidor: proceso de procesamiento de solicitudes de transacciones

Anteriormente analizamos el procesamiento de procesos de solicitud de transacciones en modo independiente. La cadena de responsabilidades del proceso PrepRequestProcessor ~ SyncRequestProcessor ~ FinalRequestProcessor es relativamente clara. Esta sección analiza el procesamiento de solicitudes de transacciones en modo clúster, involucrando el protocolo zab. analiza las solicitudes de transacciones en modo clúster. El procesamiento implica la implementación del protocolo zab, la comunicación entre el líder y el seguidor, el flujo de solicitudes entre procesadores, etc.

El punto de entrada es el mismo que para el modo independiente, es decir, escucha en el puerto 2181, luego PrepRequestProcessor verifica la solicitud (por ejemplo, ruta, versión, ACL, ruta, versión, ACL, etc.) y las pasa. al ProposalRequestProcessor Consulte "Zookeeper (V) - Modo independiente del lado del servidor - Procesamiento de solicitudes de transacciones"

La sección anterior ha sido analizada

Consulte "Zookeeper (V); ) -Modo independiente del lado del servidor-Procesamiento de solicitudes de transacciones》

El tamaño de las solicitudes comprometidas no es 0, espere hasta el final, como se muestra en 3 arriba.

Ejecute la lógica de CommitProcessor. ejecutar con el líder junto con el líder La lógica de ejecutar CommitProcessor.run es consistente, como se analizó en 3.1 arriba;

La lógica general de ejecutar operaciones de transacciones en memoria y generar respuestas se ha analizado de manera estándar. modo solo, pero en modo clúster, desde el líder Las solicitudes sincrónicas no necesitan procesarse en la memoria. El líder que sincroniza desde la solicitud no necesita generar una respuesta.

Regrese a 4.1

Igual que 4-3, también puede consultar "Zookeeper (V)-Server; -Procesamiento de solicitudes de transacciones en modo independiente"

Luego regrese a 5.2

Con respecto a toBeApplied, los siguientes son los puntos clave del nuevo contenido

1 .> 1. Cuando Leader.processAck reciba más de la mitad de los ACK, colocará la propuesta actual en la variable miembro toBeApplied del líder;

2. Antes de enviar NEWLEADER, LeaderHandler.run seleccionará la estación maestra y luego sincronizar datos con Follower.

El líder no deja de procesar solicitudes. La solicitud entre commitLog y NEWLEADER es el paso previo para ingresar a toBeApplied; la sincronización de datos consiste en atravesar toBeApplied a través del siguiente método startForwarding para construir PROPOSE y COMMIT y enviarlos al seguidor

3. LeaderZooKeeperServer. setupRequestProcessors construye una cadena de procesador y pasa el toBeApplied de Leader al toBeApplied de ToBeAppliedRequestProcessor;

4. Aquí ToBeAppliedRequestProcessor.processRequest determina si el ACK que ha recibido esta parte de la propuesta se elimina de toBeApplied;

Igual que el proceso en modo independiente, después de actualizar la memoria, se construye una respuesta y se devuelve al cliente (5.4. Para obtener más detalles, consulte Solicitud de transacción en modo independiente del lado del servidor Zookeeper(V). procesamiento

Esta sección solo analiza el proceso directo del líder para recibir solicitudes

1. Después de que el seguidor recibe la solicitud transaccional, FollowerRequestProcessor.run construye un paquete de datos REQUEST y lo envía al líder. (Learner.request) para su procesamiento. Después de que LearnerHandler.run del Líder reciba la SOLICITUD, construya la solicitud pendiente desde el primer procesador del Líder (ZooKeeperServer.submitRequest), y el proceso posterior es coherente con esta sección

2. En comparación con Obverser y Follower, el proceso de procesamiento de solicitudes es exactamente el mismo (sin transacción (las solicitudes transaccionales se procesan directamente/las solicitudes transaccionales se envían al líder para su procesamiento). La única diferencia es que Obverser no participa en el envío de transacciones y elección La única interacción con otros nodos es recibir mensajes de notificación de Leader y actualizar su propio almacenamiento local (ZooKeeperServer.submitRequest) y luego enviar la solicitud al primer procesador de Leader (ZooKeeperServer.submitRequest). La única diferencia es que Obverser no participa en el envío y la elección de transacciones. Su única interacción con otros nodos es recibir mensajes de notificación del líder y actualizar su propio almacenamiento local (esto es principalmente para mejorar el rendimiento de lectura en los centros de datos).