• xxljob 小结


     

    配置属性详细说明:

    1. 基础配置:
    2. - 执行器:任务的绑定的执行器,任务触发调度时将会自动发现注册成功的执行器, 实现任务自动发现功能; 另一方面也可以方便的进行任务分组。每个任务必须绑定一个执行器, 可在 "执行器管理" 进行设置;
    3. - 任务描述:任务的描述信息,便于任务管理;
    4. - 负责人:任务的负责人;
    5. - 报警邮件:任务调度失败时邮件通知的邮箱地址,支持配置多邮箱地址,配置多个邮箱地址时用逗号分隔;
    6. 触发配置:
    7. - 调度类型:
    8. 无:该类型不会主动触发调度;
    9. CRON:该类型将会通过CRON,触发任务调度;
    10. 固定速度:该类型将会以固定速度,触发任务调度;按照固定的间隔时间,周期性触发;
    11. 固定延迟:该类型将会以固定延迟,触发任务调度;按照固定的延迟时间,从上次调度结束后开始计算延迟时间,到达延迟时间后触发下次调度;
    12. - CRON:触发任务执行的Cron表达式;
    13. - 固定速度:固件速度的时间间隔,单位为秒;
    14. - 固定延迟:固件延迟的时间间隔,单位为秒;
    15. 任务配置:
    16. - 运行模式:
    17. BEAN模式:任务以JobHandler方式维护在执行器端;需要结合 "JobHandler" 属性匹配执行器中任务;
    18. GLUE模式(Java):任务以源码方式维护在调度中心;该模式的任务实际上是一段继承自IJobHandlerJava类代码并 "groovy" 源码方式维护,它在执行器项目中运行,可使用@Resource/@Autowire注入执行器里中的其他服务;
    19. GLUE模式(Shell):任务以源码方式维护在调度中心;该模式的任务实际上是一段 "shell" 脚本;
    20. GLUE模式(Python):任务以源码方式维护在调度中心;该模式的任务实际上是一段 "python" 脚本;
    21. GLUE模式(PHP):任务以源码方式维护在调度中心;该模式的任务实际上是一段 "php" 脚本;
    22. GLUE模式(NodeJS):任务以源码方式维护在调度中心;该模式的任务实际上是一段 "nodejs" 脚本;
    23. GLUE模式(PowerShell):任务以源码方式维护在调度中心;该模式的任务实际上是一段 "PowerShell" 脚本;
    24. - JobHandler:运行模式为 "BEAN模式" 时生效,对应执行器中新开发的JobHandler类“@JobHandler”注解自定义的value值;
    25. - 执行参数:任务执行所需的参数;
    26. 高级配置:
    27. - 路由策略:当执行器集群部署时,提供丰富的路由策略,包括;
    28. FIRST(第一个):固定选择第一个机器;
    29. LAST(最后一个):固定选择最后一个机器;
    30. ROUND(轮询):;
    31. RANDOM(随机):随机选择在线的机器;
    32. CONSISTENT_HASH(一致性HASH):每个任务按照Hash算法固定选择某一台机器,且所有任务均匀散列在不同机器上。
    33. LEAST_FREQUENTLY_USED(最不经常使用):使用频率最低的机器优先被选举;
    34. LEAST_RECENTLY_USED(最近最久未使用):最久未使用的机器优先被选举;
    35. FAILOVER(故障转移):按照顺序依次进行心跳检测,第一个心跳检测成功的机器选定为目标执行器并发起调度;
    36. BUSYOVER(忙碌转移):按照顺序依次进行空闲检测,第一个空闲检测成功的机器选定为目标执行器并发起调度;
    37. SHARDING_BROADCAST(分片广播):广播触发对应集群中所有机器执行一次任务,同时系统自动传递分片参数;可根据分片参数开发分片任务;
    38. - 子任务:每个任务都拥有一个唯一的任务ID(任务ID可以从任务列表获取),当本任务执行结束并且执行成功时,将会触发子任务ID所对应的任务的一次主动调度。
    39. - 调度过期策略:
    40. - 忽略:调度过期后,忽略过期的任务,从当前时间开始重新计算下次触发时间;
    41. - 立即执行一次:调度过期后,立即执行一次,并从当前时间开始重新计算下次触发时间;
    42. - 阻塞处理策略:调度过于密集执行器来不及处理时的处理策略;
    43. 单机串行(默认):调度请求进入单机执行器后,调度请求进入FIFO队列并以串行方式运行;
    44. 丢弃后续调度:调度请求进入单机执行器后,发现执行器存在运行的调度任务,本次请求将会被丢弃并标记为失败;
    45. 覆盖之前调度:调度请求进入单机执行器后,发现执行器存在运行的调度任务,将会终止运行中的调度任务并清空队列,然后运行本地调度任务;
    46. - 任务超时时间:支持自定义任务超时时间,任务运行超时将会主动中断任务;
    47. - 失败重试次数;支持自定义任务失败重试次数,当任务失败时将会按照预设的失败重试次数主动进行重试;

    3.1 BEAN模式(类形式)

    Bean模式任务,支持基于类的开发方式,每个任务对应一个Java类。

    • 优点:不限制项目环境,兼容性好。即使是无框架项目,如main方法直接启动的项目也可以提供支持,可以参考示例项目 “xxl-job-executor-sample-frameless”;
    • 缺点:
      • 每个任务需要占用一个Java类,造成类的浪费;
      • 不支持自动扫描任务并注入到执行器容器,需要手动注入。




    执行器属性说明

    1. AppName: 是每个执行器集群的唯一标示AppName, 执行器会周期性以AppName为对象进行自动注册。可通过该配置自动发现注册成功的执行器, 供任务调度时使用;
    2. 名称: 执行器的名称, 因为AppName限制字母数字等组成,可读性不强, 名称为了提高执行器的可读性;
    3. 排序: 执行器的排序, 系统中需要执行器的地方,如任务新增, 将会按照该排序读取可用的执行器列表;
    4. 注册方式:调度中心获取执行器地址的方式;
    5. 自动注册:执行器自动进行执行器注册,调度中心通过底层注册表可以动态发现执行器机器地址;
    6. 手动录入:人工手动录入执行器的地址信息,多地址逗号分隔,供调度中心使用;
    7. 机器地址:"注册方式""手动录入"时有效,支持人工维护执行器的地址信息;



    4.5 启动/停止任务

    可对任务进行“启动”和“停止”操作。
    需要注意的是,此处的启动/停止仅针对任务的后续调度触发行为,不会影响到已经触发的调度任务,如需终止已经触发的调度任务,可查看“4.9 终止运行中的任务”

    4.6 手动触发一次调度

    点击“执行”按钮,可手动触发一次任务调度,不影响原有调度规则。



    4.12 用户管理

    进入 “用户管理” 界面,可查看和管理用户信息;

    目前用户分为两种角色:

    • 管理员:拥有全量权限,支持在线管理用户信息,为用户分配权限,权限分配粒度为执行器;
    • 普通用户:仅拥有被分配权限的执行器,及相关任务的操作权限;



    5.3.1 设计思想

    将调度行为抽象形成“调度中心”公共平台,而平台自身并不承担业务逻辑,“调度中心”负责发起调度请求。

    将任务抽象成分散的JobHandler,交由“执行器”统一管理,“执行器”负责接收调度请求并执行对应的JobHandler中业务逻辑。

    因此,“调度”和“任务”两部分可以相互解耦,提高系统整体稳定性和扩展性;

    5.3.2 系统组成

      • 调度模块(调度中心):
        负责管理调度信息,按照调度配置发出调度请求,自身不承担业务代码。调度系统与任务解耦,提高了系统可用性和稳定性,同时调度系统性能不再受限于任务模块;
        支持可视化、简单且动态的管理调度信息,包括任务新建,更新,删除,GLUE开发和任务报警等,所有上述操作都会实时生效,同时支持监控调度结果以及执行日志,支持执行器Failover。
      • 执行模块(执行器):
        负责接收调度请求并执行任务逻辑。任务模块专注于任务的执行等操作,开发和维护更加简单和高效;
        接收“调度中心”的执行请求、终止请求和日志请求等。




    5.4.1 quartz的不足

    Quartz作为开源作业调度中的佼佼者,是作业调度的首选。但是集群环境中Quartz采用API的方式对任务进行管理,从而可以避免上述问题,但是同样存在以下问题:

    • 问题一:调用API的的方式操作任务,不人性化;
    • 问题二:需要持久化业务QuartzJobBean到底层数据表中,系统侵入性相当严重。
    • 问题三:调度逻辑和QuartzJobBean耦合在同一个项目中,这将导致一个问题,在调度任务数量逐渐增多,同时调度任务逻辑逐渐加重的情况下,此时调度系统的性能将大大受限于业务;
    • 问题四:quartz底层以“抢占式”获取DB锁并由抢占成功节点负责运行任务,会导致节点负载悬殊非常大;而XXL-JOB通过执行器实现“协同分配式”运行任务,充分发挥集群优势,负载各节点均衡。

    XXL-JOB弥补了quartz的上述不足之处。



    5.4.8 任务HA(Failover)

    执行器如若集群部署,调度中心将会感知到在线的所有执行器,如“127.0.0.1:9997, 127.0.0.1:9998, 127.0.0.1:9999”。

    当任务”路由策略”选择”故障转移(FAILOVER)”时,当调度中心每次发起调度请求时,会按照顺序对执行器发出心跳检测请求,第一个检测为存活状态的执行器将会被选定并发送调度请求。

    5.4.9 调度日志

    调度中心每次进行任务调度,都会记录一条任务日志,任务日志主要包括以下三部分内容:

    • 任务信息:包括“执行器地址”、“JobHandler”和“执行参数”等属性,点击任务ID按钮可查看,根据这些参数,可以精确的定位任务执行的具体机器和任务代码;
    • 调度信息:包括“调度时间”、“调度结果”和“调度日志”等,根据这些参数,可以了解“调度中心”发起调度请求时具体情况。
    • 执行信息:包括“执行时间”、“执行结果”和“执行日志”等,根据这些参数,可以了解在“执行器”端任务执行的具体情况;

    调度日志,针对单次调度,属性说明如下:

    • 执行器地址:任务执行的机器地址;
    • JobHandler:Bean模式表示任务执行的JobHandler名称;
    • 任务参数:任务执行的入参;
    • 调度时间:调度中心,发起调度的时间;
    • 调度结果:调度中心,发起调度的结果,SUCCESS或FAIL;
    • 调度备注:调度中心,发起调度的备注信息,如地址心跳检测日志等;
    • 执行时间:执行器,任务执行结束后回调的时间;
    • 执行结果:执行器,任务执行的结果,SUCCESS或FAIL;
    • 执行备注:执行器,任务执行的备注信息,如异常日志等;
    • 执行日志:任务执行过程中,业务代码中打印的完整执行日志,见“4.8 查看执行日志”;



    5.5.1 “Bean模式” 任务

    开发步骤:可参考 “章节三” ;
    原理:每个Bean模式任务都是一个Spring的Bean类实例,它被维护在“执行器”项目的Spring容器中。任务类需要加“@JobHandler(value=”名称”)”注解,因为“执行器”会根据该注解识别Spring容器中的任务。任务类需要继承统一接口“IJobHandler”,任务逻辑在execute方法中开发,因为“执行器”在接收到调度中心的调度请求时,将会调用“IJobHandler”的execute方法,执行任务逻辑。

    5.5.4 执行器

    执行器实际上是一个内嵌的Server,默认端口9999(配置项:xxl.job.executor.port)。

    在项目启动时,执行器会通过“@JobHandler”识别Spring容器中“Bean模式任务”,以注解的value属性为key管理起来。

    “执行器”接收到“调度中心”的调度请求时,如果任务类型为“Bean模式”,将会匹配Spring容器中的“Bean模式任务”,然后调用其execute方法,执行任务逻辑。如果任务类型为“GLUE模式”,将会加载GLue代码,实例化Java对象,注入依赖的Spring服务(注意:Glue代码中注入的Spring服务,必须存在与该“执行器”项目的Spring容器中),然后调用execute方法,执行任务逻辑。

    5.5.5 任务日志

    XXL-JOB会为每次调度请求生成一个单独的日志文件,需要通过 “XxlJobHelper.log” 打印执行日志,“调度中心”查看执行日志时将会加载对应的日志文件。

    (历史版本通过重写LOG4J的Appender实现,存在依赖限制,该方式在新版本已经被抛弃)

    日志文件存放的位置可在“执行器”配置文件进行自定义,默认目录格式为:/data/applogs/xxl-job/jobhandler/“格式化日期”/“数据库调度日志记录的主键ID.log”。

    在JobHandler中开启子线程时,子线程将会将会把日志打印在父线程即JobHandler的执行日志中,方便日志追踪。

    5.11 故障转移 & 失败重试

    一次完整任务流程包括”调度(调度中心) + 执行(执行器)”两个阶段。

    • “故障转移”发生在调度阶段,在执行器集群部署时,如果某一台执行器发生故障,该策略支持自动进行Failover切换到一台正常的执行器机器并且完成调度请求流程。
    • “失败重试”发生在”调度 + 执行”两个阶段,支持通过自定义任务失败重试次数,当任务失败时将会按照预设的失败重试次数主动进行重试;

    5.14 任务超时控制

    支持设置任务超时时间,任务运行超时的情况下,将会主动中断任务;

    需要注意的是,任务超时中断时与任务终止机制(可查看“4.9 终止运行中的任务”)类似,也是通过 “interrupt” 中断任务,因此业务代码需要将 “InterruptedException” 外抛,否则功能不可用。


    5.16 任务失败告警

    默认提供邮件失败告警,可扩展短信、钉钉等方式。如果需要新增一种告警方式,只需要新增一个实现 “com.xxl.job.admin.core.alarm.JobAlarm” 接口的告警实现即可。可以参考默认提供邮箱告警实现 “EmailJobAlarm”。



    5.20 避免任务重复执行

    调度密集或者耗时任务可能会导致任务阻塞,集群情况下调度组件小概率情况下会重复触发;
    针对上述情况,可以通过结合 “单机路由策略(如:第一台、一致性哈希)” + “阻塞策略(如:单机串行、丢弃后续调度)” 来规避,最终避免任务重复执行。


    https://www.xuxueli.com/xxl-job/#1.1%20%E6%A6%82%E8%BF%B0





  • 相关阅读:
    ORM框架
    优酷项目1
    新年第一天
    前端第十天
    前端第九天
    前端第八天
    前端第七天
    前端第六天
    前端第五天
    月亮与六便士
  • 原文地址:https://www.cnblogs.com/softidea/p/16107135.html
Copyright © 2020-2023  润新知