light task scheduler
1.7.0 release
LTS (programador de tareas ligeras) se utiliza principalmente para resolver problemas de programación de tareas distribuidas y admite tareas en tiempo real, tareas programadas y tareas Cron. Tiene buena escalabilidad, escalabilidad, robustez y estabilidad y es utilizado por muchas empresas. También esperamos que los entusiastas del código abierto puedan contribuir juntos.
Dirección de Github: https://github.com/ltsopensource/light-task-scheduler
Dirección de Oschina: http://git.oschina.net/hugui/light-task-scheduler
Ejemplos: https://github.com/ltsopensource/lts-examples
Dirección del documento (en actualización, esto prevalecerá más adelante): https://www.gitbook.com/book/qq254963746/lts/details
Ambas direcciones se actualizarán simultáneamente. Si está interesado, únase al grupo QQ: 109500214 (contraseña del grupo: hola mundo) para discutir y mejorar juntos. Cuanta más gente lo apoye, más motivación habrá para actualizarlo. Si lo deseas, recuerda poner una estrella en la esquina superior derecha.
LTS tiene principalmente los siguientes cuatro tipos de nodos:
Los nodos JobClient, JobTracker y TaskTracker no tienen无状态. Se pueden implementar y eliminar dinámicamente varios para lograr el equilibrio de carga y una mayor capacidad de carga, y el marco utiliza la estrategia FailStore para hacer que LTS tenga una buena tolerancia a fallas.
El centro de registro LTS proporciona múltiples implementaciones (Zookeeper, redis, etc.) El centro de registro expone la información del nodo y elige los maestros. (Mongo o Mysql) almacena colas de tareas y registros de ejecución de tareas, netty o mina realizan comunicaciones subyacentes y proporcionan múltiples métodos de serialización como fastjson, hessian2, java, etc.
LTS admite tipos de tareas:
Admite la modificación dinámica de los parámetros de la tarea, el tiempo de ejecución de la tarea y otras configuraciones, admite la adición dinámica de tareas en segundo plano, admite la suspensión de tareas Cron, admite la detención manual de tareas en ejecución (condicional), admite estadísticas de monitoreo de tareas, admite el monitoreo de ejecución de tareas de cada nodo , Monitoreo JVM, etc.
La siguiente figura es un proceso estándar de ejecución de tareas en tiempo real.
Actualmente, el backend tiene una función de autenticación simple proporcionada por ztajy. El nombre de usuario y la contraseña están en auth.cfg y el usuario puede modificarlos.
LTS puede prescindir del marco Spring, pero teniendo en cuenta que muchos proyectos de usuarios utilizan el marco Spring, LTS también proporciona soporte para Spring, incluidos Xml y anotaciones, solo introduzca lts-spring.jar .
Se proporciona un registrador de negocios en el lado de TaskTracker para que lo utilicen las aplicaciones. A través de este registrador de negocios, los registros de negocios se pueden enviar a JobTracker. Estos registros de negocios se pueden concatenar por ID de tarea y la ejecución de las tareas se puede ver en tiempo real en LTS. -Horario administrativo.
La expansión SPI puede lograr una intrusión cero. Solo necesita implementar la interfaz correspondiente y puede ser utilizada por LTS. Las interfaces de expansión actualmente abiertas son.
Cuando el TaskTracker que está ejecutando la tarea deja de funcionar, JobTracker asignará inmediatamente todas las tareas asignadas al TaskTracker caído a otros nodos normales de TaskTracker para su ejecución.
El monitoreo de recursos, el monitoreo de tareas, etc. se pueden realizar en los nodos JobTracker y TaskTracker, y se pueden ver en el fondo de administración de LTS-Admin en tiempo real para realizar una asignación de recursos razonable.
El marco LTS brinda soporte para cuatro resultados de ejecución, EXECUTE_SUCCESS , EXECUTE_FAILED , EXECUTE_LATER y EXECUTE_EXCEPTION , y adopta los mecanismos de procesamiento correspondientes para cada resultado, como el reintento.
El mecanismo FailStore se utiliza para la tolerancia a fallas del nodo. Fail And Store no afectará el funcionamiento de la aplicación actual debido a la inestabilidad de la comunicación remota. Para obtener instrucciones específicas de FailStore, consulte las instrucciones de FailStore en la descripción del concepto.
El proyecto se construye principalmente con maven y actualmente proporciona paquetes de scripts de shell. Dependencias del entorno: Java(jdk1.6+) Maven
El uso del usuario generalmente se divide en dos tipos:
Puede cargar el paquete jar lts en el almacén local mediante el comando maven. Agregue el repositorio correspondiente en el pom.xml principal y cárguelo con el comando de implementación. Para métodos de cita específicos, consulte los ejemplos en lts.
Cada módulo de lts debe empaquetarse en un paquete jar separado y todos los paquetes de dependencia de lts deben importarse. Para obtener una referencia específica sobre qué paquetes jar, puede consultar los ejemplos en lts.
Se proporcionan dos scripts de versión (cmd)windows y (shell)linux para compilación e implementación:
La ejecución del script sh build.sh o build.cmd en el directorio raíz generará la carpeta lts-{version}-bin en dist .
La siguiente es su estructura de directorios, en la que el directorio bin contiene principalmente los scripts de inicio de JobTracker y LTS-Admin. jobtracker contiene el archivo de configuración de JobTracker y el paquete jar que debe usarse. lts-admin es el paquete war y el archivo de configuración relacionado con LTS-Admin. Estructura de archivos de lts-{versión}-bin
-- lts - $ { version }- bin
|-- bin
| |-- jobtracker . cmd
| |-- jobtracker . sh
| |-- lts - admin . cmd
| |-- lts - admin . sh
| |-- lts - monitor . cmd
| |-- lts - monitor . sh
| |-- tasktracker . sh
|-- conf
| |-- log4j . properties
| |-- lts - admin . cfg
| |-- lts - monitor . cfg
| |-- readme . txt
| |-- tasktracker . cfg
| |-- zoo
| |-- jobtracker . cfg
| |-- log4j . properties
| |-- lts - monitor . cfg
|-- lib
| |-- *. jar
|-- war
|-- jetty
| |-- lib
| |-- *. jar
|-- lts - admin . warconf/zoo y luego ejecute sh jobtracker.sh zoo start . Si desea iniciar dos nodos JobTracker, debe copiar un zoológico, por ejemplo, nombrarlo. zoo2 , modifique el archivo de configuración en zoo2 y luego ejecute sh jobtracker.sh zoo2 start . El registro jobtracker-zoo.out se genera en la carpeta de registros.conf/lts-monitor.cfg y conf/lts-admin.cfg , y luego ejecute el script sh lts-admin.sh o lts-admin.cmd en bin . lts-admin.out se generará en la carpeta de registros. Si el inicio es exitoso, la dirección de acceso se imprimirá en el registro. Los usuarios pueden acceder a través de esta dirección de acceso. Los paquetes jar que deben importarse a lts incluyen lts-jobclient-{version}.jar , lts-core-{version}.jar y otros jar dependientes de terceros.
JobClient jobClient = new RetryJobClient ();
jobClient . setNodeGroup ( "test_jobClient" );
jobClient . setClusterName ( "test_cluster" );
jobClient . setRegistryAddress ( "zookeeper://127.0.0.1:2181" );
jobClient . start ();
// 提交任务
Job job = new Job ();
job . setTaskId ( "3213213123" );
job . setParam ( "shopId" , "11111" );
job . setTaskTrackerNodeGroup ( "test_trade_TaskTracker" );
// job.setCronExpression("0 0/1 * * * ?"); // 支持 cronExpression表达式
// job.setTriggerTime(new Date()); // 支持指定时间执行
Response response = jobClient . submitJob ( job );< bean id = "jobClient" class = "com.github.ltsopensource.spring.JobClientFactoryBean" >
< property name = "clusterName" value = "test_cluster" />
< property name = "registryAddress" value = "zookeeper://127.0.0.1:2181" />
< property name = "nodeGroup" value = "test_jobClient" />
< property name = "masterChangeListeners" >
< list >
< bean class = "com.github.ltsopensource.example.support.MasterChangeListenerImpl" />
</ list >
</ property >
< property name = "jobFinishedHandler" >
< bean class = "com.github.ltsopensource.example.support.JobFinishedHandlerImpl" />
</ property >
< property name = "configs" >
< props >
<!-- 参数 -->
< prop key = "job.fail.store" > leveldb </ prop >
</ props >
</ property >
</ bean > @ Configuration
public class LTSSpringConfig {
@ Bean ( name = "jobClient" )
public JobClient getJobClient () throws Exception {
JobClientFactoryBean factoryBean = new JobClientFactoryBean ();
factoryBean . setClusterName ( "test_cluster" );
factoryBean . setRegistryAddress ( "zookeeper://127.0.0.1:2181" );
factoryBean . setNodeGroup ( "test_jobClient" );
factoryBean . setMasterChangeListeners ( new MasterChangeListener []{
new MasterChangeListenerImpl ()
});
Properties configs = new Properties ();
configs . setProperty ( "job.fail.store" , "leveldb" );
factoryBean . setConfigs ( configs );
factoryBean . afterPropertiesSet ();
return factoryBean . getObject ();
}
} Los paquetes jar que deben importarse a lts incluyen lts-tasktracker-{version}.jar , lts-core-{version}.jar y otros jar dependientes de terceros.
public class MyJobRunner implements JobRunner {
@ Override
public Result run ( JobContext jobContext ) throws Throwable {
try {
// TODO 业务逻辑
// 会发送到 LTS (JobTracker上)
jobContext . getBizLogger (). info ( "测试，业务日志啊啊啊啊啊" );
} catch ( Exception e ) {
return new Result ( Action . EXECUTE_FAILED , e . getMessage ());
}
return new Result ( Action . EXECUTE_SUCCESS , "执行成功了，哈哈" );
}
} TaskTracker taskTracker = new TaskTracker ();
taskTracker . setJobRunnerClass ( MyJobRunner . class );
taskTracker . setRegistryAddress ( "zookeeper://127.0.0.1:2181" );
taskTracker . setNodeGroup ( "test_trade_TaskTracker" );
taskTracker . setClusterName ( "test_cluster" );
taskTracker . setWorkThreads ( 20 );
taskTracker . start ();< bean id = "taskTracker" class = "com.github.ltsopensource.spring.TaskTrackerAnnotationFactoryBean" init - method = "start" >
< property name = "jobRunnerClass" value = "com.github.ltsopensource.example.support.MyJobRunner" />
< property name = "bizLoggerLevel" value = "INFO" />
< property name = "clusterName" value = "test_cluster" />
< property name = "registryAddress" value = "zookeeper://127.0.0.1:2181" />
< property name = "nodeGroup" value = "test_trade_TaskTracker" />
< property name = "workThreads" value = "20" />
< property name = "masterChangeListeners" >
< list >
< bean class = "com.github.ltsopensource.example.support.MasterChangeListenerImpl" />
</ list >
</ property >
< property name = "configs" >
< props >
< prop key = "job.fail.store" > leveldb </ prop >
</ props >
</ property >
</ bean > @ Configuration
public class LTSSpringConfig implements ApplicationContextAware {
private ApplicationContext applicationContext ;
@ Override
public void setApplicationContext ( ApplicationContext applicationContext ) throws BeansException {
this . applicationContext = applicationContext ;
}
@ Bean ( name = "taskTracker" )
public TaskTracker getTaskTracker () throws Exception {
TaskTrackerAnnotationFactoryBean factoryBean = new TaskTrackerAnnotationFactoryBean ();
factoryBean . setApplicationContext ( applicationContext );
factoryBean . setClusterName ( "test_cluster" );
factoryBean . setJobRunnerClass ( MyJobRunner . class );
factoryBean . setNodeGroup ( "test_trade_TaskTracker" );
factoryBean . setBizLoggerLevel ( "INFO" );
factoryBean . setRegistryAddress ( "zookeeper://127.0.0.1:2181" );
factoryBean . setMasterChangeListeners ( new MasterChangeListener []{
new MasterChangeListenerImpl ()
});
factoryBean . setWorkThreads ( 20 );
Properties configs = new Properties ();
configs . setProperty ( "job.fail.store" , "leveldb" );
factoryBean . setConfigs ( configs );
factoryBean . afterPropertiesSet ();
// factoryBean.start();
return factoryBean . getObject ();
}
}Descripción del parámetro
Generalmente, solo se necesita una instancia de JobClient en una JVM. No cree una nueva instancia de JobClient para cada tarea. Esto desperdiciará muchos recursos, porque un JobClient puede enviar varias tareas. La misma JVM generalmente intenta mantener solo una instancia de TaskTracker. Si hay más instancias, puede provocar un desperdicio de recursos. Cuando encuentre un TaskTracker que necesite ejecutar varias tareas, consulte "Un TaskTracker realiza varias tareas" a continuación.
A veces, los escenarios comerciales requieren la ejecución de múltiples tareas. Algunas personas pueden preguntar si cada tipo de tarea requiere un TaskTracker para su ejecución. Mi respuesta es no. Si está en una JVM, es mejor usar TaskTracker para ejecutar múltiples tareas, porque usar múltiples instancias de TaskTracker en una JVM es un desperdicio de recursos (por supuesto, cuando tiene una gran cantidad de ciertas tareas). , puede utilizar un nodo TaskTracker independiente para ejecutar esta tarea). Entonces, ¿cómo podemos implementar un TaskTracker para realizar múltiples tareas? A continuación se muestra el ejemplo de referencia que di.
/**
* 总入口，在 taskTracker.setJobRunnerClass(JobRunnerDispatcher.class)
* JobClient 提交 任务时指定 Job 类型 job.setParam("type", "aType")
*/
public class JobRunnerDispatcher implements JobRunner {
private static final ConcurrentHashMap < String /*type*/ , JobRunner >
JOB_RUNNER_MAP = new ConcurrentHashMap < String , JobRunner >();
static {
JOB_RUNNER_MAP . put ( "aType" , new JobRunnerA ()); // 也可以从Spring中拿
JOB_RUNNER_MAP . put ( "bType" , new JobRunnerB ());
}
@ Override
public Result run ( JobContext jobContext ) throws Throwable {
Job job = jobContext . getJob ();
String type = job . getParam ( "type" );
return JOB_RUNNER_MAP . get ( type ). run ( job );
}
}
class JobRunnerA implements JobRunner {
@ Override
public Result run ( JobContext jobContext ) throws Throwable {
// TODO A类型Job的逻辑
return null ;
}
}
class JobRunnerB implements JobRunner {
@ Override
public Result run ( JobContext jobContext ) throws Throwable {
// TODO B类型Job的逻辑
return null ;
}
} Generalmente, al escribir TaskTracker, solo necesita probar si la lógica de implementación de JobRunner es correcta, pero no desea iniciar LTS para pruebas remotas. Para facilitar las pruebas, LTS proporciona el método de prueba abreviado de JobRunner. Simplemente integre com.github.ltsopensource.tasktracker.runner.JobRunnerTester en su propia clase de prueba e implemente initContext y newJobRunner . Como el ejemplo en lts-examples:
public class TestJobRunnerTester extends JobRunnerTester {
public static void main ( String [] args ) throws Throwable {
// Mock Job 数据
Job job = new Job ();
job . setTaskId ( "2313213" );
JobContext jobContext = new JobContext ();
jobContext . setJob ( job );
JobExtInfo jobExtInfo = new JobExtInfo ();
jobExtInfo . setRetry ( false );
jobContext . setJobExtInfo ( jobExtInfo );
// 运行测试
TestJobRunnerTester tester = new TestJobRunnerTester ();
Result result = tester . run ( jobContext );
System . out . println ( JSON . toJSONString ( result ));
}
@ Override
protected void initContext () {
// TODO 初始化Spring容器
}
@ Override
protected JobRunner newJobRunner () {
return new TestJobRunner ();
}
}Para las tareas Cron de Quartz, solo necesita agregar algo de código a la configuración de Spring para conectarse a la plataforma LTS.
< bean class = " com.github.ltsopensource.spring.quartz.QuartzLTSProxyBean " >
< property name = " clusterName " value = " test_cluster " />
< property name = " registryAddress " value = " zookeeper://127.0.0.1:2181 " />
< property name = " nodeGroup " value = " quartz_test_group " />
</ bean > @ SpringBootApplication
@ EnableJobTracker // 启动JobTracker
@ EnableJobClient // 启动JobClient
@ EnableTaskTracker // 启动TaskTracker
@ EnableMonitor // 启动Monitor
public class Application {
public static void main ( String [] args ) {
SpringApplication . run ( Application . class , args );
}
} Todo lo que queda es agregar la configuración correspondiente en application.properties. Para obtener más detalles, consulte el ejemplo en com.github.ltsopensource.examples.springboot en lts-example.
Cuando la máquina tiene dos tarjetas de red en la red interna, a veces si el usuario desea que el tráfico LTS pase a través de la tarjeta de red externa, debe cambiar la dirección de asignación del nombre del host a la dirección de la tarjeta de red externa en el host. Lo mismo ocurre con la red interna.
Si la ID del nodo se establece cuando se inicia el nodo, LTS establecerá un UUID como ID del nodo de forma predeterminada. La legibilidad será deficiente, pero se puede garantizar la unicidad de cada nodo si el usuario puede garantizar la unicidad del nodo. ID por sí mismo, puede setIdentity para configurar, por ejemplo, si cada nodo se implementa en una máquina (una máquina virtual), entonces la identidad se puede configurar en el nombre de host
Admite extensiones SPI para JobLogger, JobQueue, etc.
Ver número 389
La experiencia laboral es de más de tres años.
Requisitos de educación Licenciatura
Nivel de expectativa P6 (ingeniero senior de Java)/P7 (experto técnico)
Descripción del trabajo
La plataforma de membresía es responsable del sistema de usuarios de Alibaba Group, respalda las necesidades de los usuarios de varias líneas comerciales dentro del grupo y respalda los canales comerciales y de usuarios de la cooperación externa del grupo. Incluyendo el inicio de sesión y la autorización del usuario, el sistema de sesión, el registro, la administración de cuentas, la seguridad de la cuenta y otras funciones en cada extremo, los servicios subyacentes de información del usuario, la administración de sesiones y credenciales, etc., es una de las principales líneas de productos del grupo, que ofrece cientos de miles de millones de llamadas cada día, un QPS máximo de decenas de millones y una arquitectura de nube híbrida distribuida globalmente, etc.
Como ingeniero de software, trabajará en nuestros productos principales que brindan funcionalidad crítica para nuestra infraestructura comercial. Dependiendo de sus intereses y experiencia, puede trabajar en una o más de las siguientes áreas: globalización, experiencia del usuario, seguridad de datos, aprendizaje automático. , alta disponibilidad del sistema y más.
