Descripción general del trabajo flexible para tareas programadas

El siguiente ejemplo cubre muy bien los 3 elementos básicos más importantes de Quartz:

El ejemplo se llama HelloQuartz. ¿Por qué está diseñado como JobDetail Job en lugar de utilizar Job directamente? Esto se debe a que las tareas pueden ejecutarse simultáneamente y, si el programador usa Job directamente, habrá problemas con el acceso simultáneo a la misma instancia de Job. En el método JobDetail & Job, el programador creará una nueva instancia de Job basada en JobDetail cada vez que se ejecute, lo que evita el problema del acceso concurrente.

Defina la clase Job como la clase HelloQuartz. Aquí es donde radica la verdadera lógica de ejecución.

Dangdang encapsula cuarzo encima de cuarzo, correspondiente a

1. Cree una clase de implementación org.quartz.Job e implemente su propia lógica empresarial.

public final class LiteJob implements Job {}

2. Defina un JobDetail que haga referencia a la clase de implementación.

3.Programador programador.

El siguiente es un ejemplo de cómo usar DangDang:

Establezca parámetros de corte, defina la clase de configuración del trabajo, el plan de ejecución y otras configuraciones

Defina la clase de trabajo

pretende ser una implementación simple del tipo sin ningún tipo de encapsulación. Necesidad de implementar la interfaz SimpleJob. La interfaz solo proporciona un método anulable que se ejecutará periódicamente. Esta interfaz es similar a la interfaz local de Quartz, pero proporciona funciones como escalado elástico y fragmentación.

El tipo Dataflow se utiliza para procesar flujos de datos y necesita implementar la interfaz DataflowJob. Esta interfaz proporciona 2 métodos, que se utilizan respectivamente para cubrir la obtención (fetchData) y el procesamiento (processData) de datos.

Tareas de transmisión: involucran dos conceptos: corte y procesamiento por lotes

Es decir, en los dos métodos reescritos anteriormente

fetchData se usa para capturar, por ejemplo , hay un campo en la base de datos de canciones que se debe recuperar para identificar a qué segmento pertenece la tarea, es decir, en qué segmento se ejecutará cuando se acabe el tiempo. Si hay dos segmentos, los números de segmento son 0 y 1 respectivamente. Luego, pasaremos la información de la canción como parámetro de contexto al método de búsqueda. 500 canciones pueden tener un LÍMITE de 100, y cada vez que encontramos 100 canciones para procesar primero, esto se denomina procesamiento por lotes. Una tarea se divide en 2 porciones. cada segmento contiene. Esto se llama procesamiento por lotes. Una tarea se divide en 2 segmentos y cada segmento se ejecuta internamente en 5 lotes según un lote de 100 canciones.

ProcessData se refiere al procesamiento de 100 canciones en cada lote, de las cuales 100 canciones son un subelemento. Si uno de los subelementos genera una excepción o falla de alguna manera, se considera que el procesamiento por lotes ha finalizado. falló y se procesará la próxima vez. Vuelva a ejecutar todos los datos de la tarea en el lote.

El atributo event_trace_rdb_url del seguimiento de eventos corresponde a las tablas JOB_EXECUTION_LOG y JOB_STATUS_TRACE_LOG y a varios índices creados automáticamente por la biblioteca.

JOB_EXECUTION_LOG registra el historial de ejecución de cada trabajo. Hay dos pasos:

Cuando el trabajo comienza a ejecutarse, los datos se insertan en la base de datos, dejando todos los campos en blanco excepto falla_causa y finalización_hora.

Una vez completada la ejecución del trabajo, actualice los datos en la base de datos y actualice is_success, complete_time y Failure_cause (si la ejecución del trabajo falló).

JOB_STATUS_TRACE_LOG registra una tabla de seguimiento de cambios de estado del trabajo. El ciclo de vida de un trabajo y el seguimiento de cambios de estado se pueden consultar mediante el task_id de cada ejecución de trabajo.

El método de monitoreo antes y después de la ejecución del trabajo se puede implementar configurando múltiples detectores de trabajos. Hay dos tipos de oyentes: los que se ejecutan en cada nodo de trabajo y los que se ejecutan en un único nodo en un escenario distribuido.

Si el trabajo procesa archivos en el servidor de trabajos y los elimina una vez finalizado, considere utilizar una tarea de limpieza que se ejecute en cada nodo. Este tipo de tarea es simple de implementar y no es necesario considerar si la tarea distribuida global se ha completado, así que intente utilizar este tipo de oyente.

Pasos:

Definir el oyente

Pasar el oyente como parámetro al JobScheduler

Si la tarea procesa datos de la base de datos, el se completa el procesamiento. Solo se necesita un nodo para completar la tarea de limpieza de datos. Este tipo de procesamiento de tareas es más complejo y requiere sincronización del estado del trabajo en un entorno distribuido. Para evitar un punto muerto causado por la desincronización del trabajo, se proporciona una configuración de tiempo de espera; utilícela con precaución.

Pasos:

Definir el oyente

Pasar el oyente como parámetro a JobScheduler

Ruta completa:

io.elasticjob.lite.api.strategy.impl.AverageAllocationJobShardingStrategy

Descripción de la estrategia:

Estrategia de fragmentación basada en el algoritmo de asignación promedio, que también es la estrategia de fragmentación predeterminada.

Si los fragmentos no se pueden consolidar, los fragmentos sobrantes que no se pueden consolidar se agregarán a servidores con números de serie más pequeños en secuencia. 1=, 2=, 3=

Si hay 3 servidores divididos en 8 fragmentos, entonces los fragmentos de cada servidor son: 1=, 2=, 3=

Si hay Son 3 servidores divididos en 10 shards, los shards de cada servidor son: 1=, 2=, 3=

Ruta completa:

io.elasticjob.lite .api.strategy. impl.OdevitySortByNameJobShardingStrategy

Descripción de la estrategia:

Determina la estrategia de fragmentación para el algoritmo de orden de promoción de IP en función de la paridad de hash del nombre del trabajo.

Los hashes impares de los nombres de los trabajos dan como resultado un orden de IP ascendente.

Incluso los hashes de los nombres de los trabajos dan como resultado un orden de IP descendente.

Se utiliza para distribuir uniformemente la carga de trabajo entre diferentes servidores.

Ruta completa:

io.elasticjob.lite.api.strategy.impl.RotateServerByNameJobShardingStrategy

Descripción de la estrategia:

Basada en el trabajo nombre El valor hash de la lista de servidores rotados.

Descomprima elastic-job-lite-console-${version}.tar.gz y ejecute binstart.sh. Abra un navegador web y visite http://localhost:8899/ para acceder a la consola.

8899 es el número de puerto predeterminado, que se puede personalizar iniciando el script e ingresando -p. Puede personalizar el número de puerto ingresando -p en el script de inicio.

elastic-job-lite-console-${version}.tar.gz se puede compilar usando mvn install.

Iniciar sesión

Hay dos cuentas: administrador e invitado. El administrador tiene todos los derechos de operación y el invitado solo tiene derechos de visualización. El nombre de usuario y la contraseña predeterminados del administrador son root/root, y el nombre de usuario y la contraseña del invitado son guest/guest. Puede cambiar los nombres de usuario y las contraseñas del administrador y del invitado a través de confiuth.properties.

Lista de funciones

Control de seguridad de inicio de sesión

Registro, gestión de fuentes de datos de seguimiento de eventos

Modificación rápida de la configuración del trabajo

> Ver el estado de las dimensiones del trabajo y del servidor

Deshabilitar, habilitar, detener y eliminar el ciclo de vida del trabajo

Consulta de seguimiento de eventos

Observaciones:

Utilice JBoss para modificar la configuración del trabajo. p>

Utilice JDK 1.7 y superior

Utilice Zookeeper 3.4.6 y superior

Utilice Maven 3.0.4 y superior

El registro creará un nodo de nombre de trabajo en el espacio de nombres definido para distinguir diferentes trabajos, por lo que una vez que se crea un trabajo, el nombre del trabajo no se puede modificar y, si se cambia el nombre, se tratará como un trabajo nuevo. . Bajo el nodo de nombre del trabajo, hay cuatro subnodos de datos: configuración, instancia, fragmento, servidor y líder.

Nodo de configuración

Información de configuración del trabajo, almacenada en formato JSON

Nodo de instancia

Información de la instancia de ejecución del trabajo, el nodo secundario es el trabajo actual La clave principal de la instancia en ejecución. La clave principal de la instancia de ejecución del trabajo consta de la dirección IP y el PID del servidor donde se ejecuta el trabajo. La clave principal de una instancia de ejecución de trabajo es un nodo temporal, que se registra cuando la instancia de trabajo se conecta y se borra automáticamente cuando se desconecta. El registro monitorea estos nodos en busca de cambios para coordinar la fragmentación y la alta disponibilidad para trabajos distribuidos. Puede escribir un DISPARADOR en el nodo de instancia que ejecuta el trabajo para indicarle a la instancia que se ejecute una vez inmediatamente.

Nodo de fragmentación

Información de fragmentación del trabajo, su nodo secundario es el número de elemento del fragmento, que comienza desde 0 y termina con el número total de fragmentos menos 1. Los nodos secundarios del número de serie del proyecto de fragmento almacenan información detallada. Los subnodos de cada proyecto de fragmento se utilizan para controlar y registrar el estado de ejecución del fragmento. Descripción de detalles del nodo:

Nodo del servidor

Información del servidor de trabajos, el subnodo es la dirección IP del servidor de trabajos. DISABLED se puede escribir en el nodo de dirección IP, lo que indica que el servidor está deshabilitado. Bajo la nueva arquitectura nativa de la nube, las funciones de los nodos del servidor se debilitan significativamente y solo incluyen la función de controlar si se desactiva el servidor. La funcionalidad del servidor puede eliminarse en el futuro para una implementación más pura de Job Core, y la capacidad de controlar si un servidor puede deshabilitarse debe delegarse a un sistema de implementación automatizado.

Nodo líder

La información del nodo maestro del servidor de trabajos se divide en tres subnodos: elección, fragmentación y conmutación por error. Se utilizan para la elección maestra, la fragmentación y el manejo de conmutación por error.

El nodo líder es un nodo interno, por lo que si no está interesado en los principios del marco laboral, puede dejar este nodo en paz.

Soy Plumfield, gracias por los me gusta, los favoritos y los comentarios, y nos vemos la próxima vez.