BreakDawn comparte este artículo de Huawei Cloud Community " Cómo Spark logra una alta disponibilidad de clústeres ".
Veamos cómo Spark maneja las excepciones a maestro, trabajador y ejecutor.
Mecanismo de tolerancia a fallas - salidas del ejecutor
En primer lugar, se puede suponer que cuando el ejecutor en el trabajador ejecuta la tarea, se envía una excepción o error inexplicable y luego desaparece el hilo correspondiente. A ver qué pasará en este momento.
La figura anterior lo resume de la siguiente manera:
El ejecutor está envuelto por el proceso de back-end. Si se lanza una excepción, la percibirá y llamará a executorRunner.exitStatus() para notificar al trabajador.
Mire lo que sucede después de que se notifica al trabajador:
- El trabajador notificará al maestro, el maestro borrará exectorInfo y luego programará al trabajador para que lo vuelva a crear.
- Aquí puede ver que la instrucción del trabajador para crear un ejecutor todavía está programada y administrada por el maestro, no creada por sí mismo.
El siguiente paso es reconstruir el ejecutor y luego reiniciar la tarea de este lugar (para que los datos se extraigan nuevamente y los datos almacenados en caché por el remitente pueden ser útiles). El diagrama de flujo completo es el siguiente:
El trabajador sale anormalmente
Suponiendo que el trabajador cuelga en este momento, ¿qué harán el ejecutivo y el maestro que están ejecutando la tarea? como sigue:
Puede ver que el trabajador tiene un gancho de apagado que ayudará a apagar el ejecutor en ejecución.
Pero en este momento el trabajador cuelga, por lo que no puede enviar mensajes al maestro ¿Qué debo hacer?
En el apartado anterior se mencionó que existe un latido entre el maestro y el trabajador, por lo que se procesará de la siguiente manera:
Se puede ver que cuando el maestro descubre que el latido del corazón del trabajador se ha perdido, hará lo siguiente:
- Eliminar información del trabajador en la lista de ejecución
- Redistribuir la operación de crear un trabajador al nodo chispa correspondiente
- Avisar al conductor que se han extraviado todos los extractores de este trabajador
Veamos qué hacen la reconstrucción del trabajador y el controlador en este momento:
Aquí también puedes ver un concepto muy importante:
- el maestro se preocupa por el estado del trabajador
- El conductor se preocupará por el progreso del ejecutor
- Después de reconstruir el ejecutor, debe registrarse en el controlador
El diagrama de flujo completo es el siguiente:
excepción maestra
Dado que el maestro no participa en el cálculo de la tarea, sino que solo administra a los trabajadores, hay dos casos para la excepción del maestro:
1: El maestro sale de manera anormal cuando la tarea se ejecuta normalmente
El proceso es el siguiente:
Se puede ver desde aquí que cuando la tarea se ejecuta normalmente, solo al final, el controlador activará la operación de recurso de limpieza del maestro, pero el proceso maestro se ha colgado, por lo que no importa.
2: durante la ejecución de la tarea, después de que el maestro cuelga, el trabajador y el ejecutor también son anormales
Se puede ver que no hay forma de reiniciar el ejecutor en este momento. En este punto, el lado del conductor parecerá que la tarea no ha progresado.
Para evitar esta situación, el maestro puede convertirse en sin estado y luego actuar como maestro y respaldo para la recuperación ante desastres. Por supuesto, el nodo maestro rara vez se realiza y, por lo general, no es fácil bloquearlo, a menos que se considere que el nodo de eliminación o implementación está defectuoso.
Haga clic en Seguir para conocer las nuevas tecnologías de HUAWEI CLOUD por primera vez~