1. 项目概述为什么我们需要一个独立的调度中心如果你负责过几个后台服务大概率遇到过这样的场景订单系统需要在每天凌晨2点统计前一天的交易数据用户活跃度报表需要每小时生成一次或者某个重要的数据同步任务需要在业务低峰期执行。最开始你可能会用操作系统的crontab或者在Spring Boot项目里用Scheduled注解。这在小规模、单机环境下确实够用。但随着业务发展问题就来了。当你有几十个、上百个定时任务分散在不同的应用里管理就成了噩梦。任务失败了谁去重启执行日志去哪里看如何保证集群环境下任务不被重复执行如果某台服务器挂了上面的定时任务就全停了怎么实现高可用这时候一个独立、集中式的任务调度中心就成了刚需。XXL-JOB 就是为解决这些问题而生的一个分布式任务调度平台。它采用了经典的“调度中心”与“执行器”分离的架构。调度中心负责管理所有任务的调度逻辑比如什么时候触发、触发哪个任务、失败了怎么处理而执行器则是真正执行业务代码的“工人”它嵌入在你的业务应用中接收调度中心的指令并执行。这种解耦设计让任务调度变得可视化、可管理、可监控。简单来说XXL-JOB 把我们从crontab配置文件和代码注解的“原始时代”带进了拥有控制台、日志、报警、失败重试等功能的“工业化时代”。接下来我会从一个实践者的角度带你快速上手它的核心功能并分享一些从零到一部署、使用过程中积累的实战心得和避坑指南。2. 核心架构与组件拆解要玩转 XXL-JOB首先得理解它的两个核心角色调度中心Admin和执行器Executor。这就像一家公司的“总部”和“各地分公司”。2.1 调度中心任务调度的大脑调度中心是一个独立部署的Web应用它是整个调度系统的指挥中枢。你可以把它想象成一个任务调度器的“操作系统”。它的核心职责包括任务管理提供Web界面让你可以动态地创建、修改、暂停、删除定时任务。你不再需要登录服务器去改crontab或者重新发布应用来修改Scheduled的cron表达式。调度触发内部有一个调度线程池它会根据你为每个任务配置的Cron表达式在精确的时间点生成调度请求并将这个请求下发给对应的执行器。执行路由当同一个任务有多个执行器实例集群部署时调度中心负责选择其中一个来执行。它支持多种路由策略比如第一个、最后一个、轮询、随机、一致性HASH等这对于负载均衡和故障转移至关重要。日志与监控它会收集并展示每一次任务调度的详细日志包括触发时间、执行结果、耗时等。任务执行失败时还可以配置邮件报警第一时间通知负责人。失败处理任务执行失败后调度中心可以按照你配置的策略如失败重试进行后续处理。调度中心本身是无状态的它的所有任务配置、调度日志、执行器注册信息等都存储在数据库中支持MySQL等。这意味着你可以轻松地部署多个调度中心实例通过Nginx等负载均衡器对外提供服务从而实现调度中心自身的高可用。只要它们连接同一个数据库就能共享状态协同工作。2.2 执行器任务执行的双手执行器是你的业务应用。你需要引入XXL-JOB的客户端依赖并在你的Spring Boot或其他Java应用中配置并启动一个执行器组件。它的核心职责是注册与心跳启动后执行器会向调度中心注册自己并定期发送心跳告诉调度中心“我还活着可以接受任务”。调度中心的控制台上就能看到在线的执行器列表。任务执行执行器内维护着一个任务处理线程池XxlJobExecutor。当调度中心下发任务触发请求时执行器会从线程池中分配一个线程来执行你预先定义好的JobHandler任务处理器。结果回调任务执行完毕后无论成功或失败执行器会将执行结果日志、耗时、状态码回调给调度中心由调度中心记录到数据库中。一个执行器可以包含多个“JobHandler”每个Handler对应一个具体的任务逻辑。执行器通常以集群方式部署这样同一个任务可以有多个备选执行节点提高了系统的可靠性和吞吐量。注意调度中心和执行器之间的通信是基于HTTP的。调度中心通过向执行器内置的一个HTTP服务默认端口9999发送请求来触发任务和获取日志。因此确保网络连通性特别是执行器端口对调度中心可访问是部署的关键。2.3 工作流程全景图一次完整的任务调度其流程可以概括为以下几步你在调度中心Web界面为一个任务比如“生成日报”配置好Cron表达式和对应的执行器。调度中心的调度线程扫描到该任务到达触发时间。调度中心根据该任务配置的路由策略从其注册的执行器列表中选出一个实例。调度中心向选中的执行器实例发送一个HTTP请求触发任务执行。执行器接收到请求在其本地线程池中调用对应的JobHandler执行业务代码。执行器将执行结果和日志通过HTTP回调给调度中心。调度中心将本次调度日志持久化到数据库并在Web界面上展示。这个流程清晰地将调度逻辑与业务逻辑分离使得两边可以独立开发、部署和扩展。3. 快速开始从零部署与基础配置理论讲完了我们动手搭一个。这里假设你已经有基本的JavaJDK 8、Maven和MySQL环境。3.1 调度中心部署首先搞定调度中心它是独立的管理后台。第一步获取源码与初始化数据库XXL-JOB的源码在GitHub上完全开源。你可以直接下载最新Release版本的源码包或者Clone仓库。解压后在/doc/db目录下找到建表SQL脚本tables_xxl_job.sql在你的MySQL实例中创建一个数据库例如xxl_job并执行这个脚本。这几张表将用来存储任务配置、调度日志、执行器信息等所有核心数据。第二步修改调度中心配置找到调度中心项目下的配置文件/xxl-job-admin/src/main/resources/application.properties。你需要修改的关键配置是数据库连接### 数据库连接按你的实际情况修改 spring.datasource.urljdbc:mysql://127.0.0.1:3306/xxl_job?useUnicodetruecharacterEncodingUTF-8autoReconnecttrueserverTimezoneAsia/Shanghai spring.datasource.usernameroot spring.datasource.passwordyour_password spring.datasource.driver-class-namecom.mysql.cj.jdbc.Driver其他配置如服务器端口默认8080、登录账号密码默认admin/123456可以按需修改。这里有个实操心得在生产环境务必修改默认的登录密码并考虑将xxl.job.accessToken配置项设置一个复杂的字符串。这个Token用于调度中心和执行器之间的通信认证能有效防止未授权的执行器注册和任务触发是一个重要的安全屏障。第三步编译与启动在调度中心项目的根目录下执行Maven打包命令mvn clean package -DskipTests。打包成功后在/xxl-job-admin/target/目录下会生成xxl-job-admin-{version}.jar。使用java -jar命令启动它java -jar xxl-job-admin-2.4.0.jar启动成功后访问http://你的服务器IP:8080/xxl-job-admin就能看到登录页面了。用默认账号登录后你就进入了调度中心的管理后台。首先去“执行器管理”菜单这是接下来配置执行器的前提。3.2 执行器集成与配置调度中心跑起来了现在让我们把一个Spring Boot应用变成执行器。第一步引入客户端依赖在你的Spring Boot项目的pom.xml中添加XXL-JOB执行器客户端的依赖。请确保版本与你的调度中心版本一致。dependency groupIdcom.xuxueli/groupId artifactIdxxl-job-core/artifactId version2.4.0/version /dependency第二步配置执行器参数在application.yml或application.properties中增加XXL-JOB的配置。以下是一个YAML格式的示例xxl: job: admin: addresses: http://你的调度中心IP:8080/xxl-job-admin # 调度中心地址多个用逗号分隔 executor: appname: your-app-name # 执行器AppName在调度中心注册的唯一标识 address: # 执行器地址默认自动注册时留空即可 ip: # 执行器IP自动注册时留空 port: 9999 # 执行器端口内置服务端口用于接收调度中心请求 logpath: /data/applogs/xxl-job/jobhandler # 任务日志文件存储路径 logretentiondays: 30 # 日志保留天数 accessToken: # 与调度中心配置的accessToken一致用于通信认证这里重点解释几个参数admin.addresses必须配置正确这是执行器“找组织”的地址。如果是集群部署的调度中心这里可以配置多个地址用逗号隔开。executor.appname这是最重要的配置之一。它代表了这个执行器集群的逻辑名称。调度中心的所有任务都是关联到某个AppName而不是具体的IP。这样当这个AppName下有多个实例即多个执行器服务器时调度中心就可以根据路由策略选择其中一个执行。请给它起一个有意义的名字如order-service、report-generator。executor.port执行器内嵌的Netty HTTP服务器端口用于接收调度中心的触发命令。确保这个端口在服务器上未被占用且防火墙规则允许调度中心访问此端口。第三步配置XxlJobConfig类你需要创建一个Java配置类来初始化XxlJobSpringExecutor Bean。这是执行器的核心。import com.xxl.job.core.executor.impl.XxlJobSpringExecutor; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.beans.factory.annotation.Value; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; Configuration public class XxlJobConfig { private Logger logger LoggerFactory.getLogger(XxlJobConfig.class); Value(${xxl.job.admin.addresses}) private String adminAddresses; Value(${xxl.job.executor.appname}) private String appname; Value(${xxl.job.executor.port}) private int port; Bean public XxlJobSpringExecutor xxlJobExecutor() { logger.info( xxl-job config init.); XxlJobSpringExecutor xxlJobSpringExecutor new XxlJobSpringExecutor(); xxlJobSpringExecutor.setAdminAddresses(adminAddresses); xxlJobSpringExecutor.setAppname(appname); xxlJobSpringExecutor.setPort(port); // 其他参数如IP、日志路径等如果配置文件里配了这里也可以set进去 // xxlJobSpringExecutor.setLogPath(logPath); // xxlJobSpringExecutor.setAccessToken(accessToken); return xxlJobSpringExecutor; } }当Spring容器启动时这个Bean会被初始化执行器会自动向配置的调度中心地址进行注册。第四步开发你的第一个JobHandler现在我们来创建一个真正的定时任务。XXL-JOB支持两种模式“Bean模式”和“GLUE模式”。Bean模式更常用任务逻辑以Spring Bean的形式编写。创建一个类用Component注解并在方法上使用XxlJob注解。import com.xxl.job.core.context.XxlJobHelper; import com.xxl.job.core.handler.annotation.XxlJob; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.stereotype.Component; Component public class SampleXxlJob { private static Logger logger LoggerFactory.getLogger(SampleXxlJob.class); /** * 一个简单的示例任务 * 任务名称demoJobHandler */ XxlJob(demoJobHandler) public void demoJobHandler() throws Exception { // 通过 XxlJobHelper 获取任务参数 String jobParam XxlJobHelper.getJobParam(); XxlJobHelper.log(XXL-JOB, Hello World. Param: jobParam); // 你的业务逻辑写在这里 logger.info(开始执行数据处理任务...); try { // 模拟业务处理 Thread.sleep(2000); // 业务处理成功 XxlJobHelper.handleSuccess(任务执行成功处理参数: jobParam); } catch (InterruptedException e) { logger.error(任务执行异常, e); // 业务处理失败 XxlJobHelper.handleFail(任务执行失败原因: e.getMessage()); } } }关键点说明XxlJob(demoJobHandler)注解中的值demoJobHandler就是这个任务的唯一标识后续在调度中心创建任务时需要填写这个值。XxlJobHelper这是一个工具类非常重要。通过它你可以获取本次任务调度的参数getJobParam、记录任务执行日志log、设置任务执行结果handleSuccess/handleFail。特别注意任务执行结果必须通过handleSuccess或handleFail告知调度中心否则调度中心会认为任务执行超时或失败。任务逻辑写在方法体内你可以在这里调用任何Spring Bean执行数据库操作、调用外部接口等。启动你的Spring Boot应用如果配置正确你应该能在调度中心Web界面的“执行器管理”页面看到你配置的appname对应的执行器并且其状态是“在线”。4. 调度中心Web界面实操详解登录调度中心界面主要分为几个模块执行器管理、任务管理、调度日志。我们按操作顺序来走一遍。4.1 执行器管理让你的应用被调度中心识别在“执行器管理”页面点击“新增”。这里有两种注册方式自动注册执行器启动后主动向调度中心注册并定时发送心跳。这是我们最推荐的方式配置简单适合动态扩缩容。你只需要填写“AppName”必须与执行器配置的appname完全一致和“名称”一个易读的备注即可。执行器列表会自动显示在线实例的地址。手动录入手动填写执行器的地址IP:Port。这种方式不够灵活执行器地址变更时需要手动修改一般只在网络隔离等特殊场景下使用。实操心得务必使用“自动注册”。在微服务架构下实例的IP和端口可能是动态的如K8S环境自动注册能完美适配。确保执行器配置的appname和这里填写的完全一致大小写敏感这是执行器能成功注册并接收任务的关键。4.2 任务管理创建与配置你的第一个定时任务在“任务管理”页面点击“新增”。执行器选择你刚刚创建或注册好的执行器AppName。这个下拉框里的选项来自“执行器管理”模块。任务描述给自己看的写清楚这个任务是干嘛的比如“每日凌晨清理临时文件”。路由策略当该执行器有多个实例时调度中心如何选择。对于大多数场景“轮询”或“随机”是不错的选择可以实现负载均衡。如果是需要幂等性处理的任务可以考虑“一致性HASH”让同一任务始终落到同一台机器。Cron填写Cron表达式。这是定时任务的核心。如果你不熟悉Cron语法可以点击输入框旁边的“生成语法”按钮通过图形界面生成。例如每天凌晨2点执行就是0 0 2 * * ?。运行模式选择“BEAN”对应我们代码中XxlJob注解的模式。JobHandler这里必须填写你代码中XxlJob注解里定义的名字比如我们前面例子中的demoJobHandler。调度中心就是通过这个名称来定位到具体要执行哪个方法。任务参数可选。可以传递一个字符串参数给任务在JobHandler中通过XxlJobHelper.getJobParam()获取。可以用来控制任务的具体行为比如传递一个日期范围。阻塞处理策略当任务触发时如果上一次调度还没执行完可能因为执行时间过长怎么办单机串行默认排队等上一个执行完再触发下一个。保证严格串行。丢弃后续调度如果上次没执行完本次触发直接忽略。适合对实时性要求不高的补偿任务。覆盖之前调度终止正在运行的任务直接执行新的。慎用可能造成数据不一致。并行执行直接新开线程执行允许任务并发。这是最需要小心的策略除非你的任务逻辑是线程安全的否则容易引发资源竞争和数据错乱。子任务ID可选。可以配置一个任务链当本任务执行成功后会自动触发另一个任务。任务超时时间设置一个任务执行的超时时间秒超时后调度中心会标记本次调度为失败。失败重试次数任务执行失败后自动重试的次数。这是提高任务可靠性的重要手段。注意这里的失败指的是任务回调结果为FAIL或者网络超时等。通常建议设置为1-3次。报警邮件填写邮箱任务执行失败后会发送邮件通知。多个邮箱用逗号分隔。填写完毕后点击保存。任务默认是“停止”状态你需要点击操作栏的“启动”按钮它才会被调度线程扫描并按时触发。4.3 调度日志任务执行的显微镜“调度日志”页面记录了每一次任务触发的全生命周期信息是排查问题最重要的地方。点击某次调度记录后的“执行日志”按钮可以看到更详细的日志。调度信息包括调度时间、调度结果成功/失败、调度机器调度中心哪台实例发的指令。执行信息包括执行时间、执行结果成功/失败/超时、执行机器哪个执行器实例执行的、耗时。任务日志这里展示的就是你在JobHandler中通过XxlJobHelper.log()打印的日志。强烈建议在任务关键步骤和异常捕获处都打上日志这对于线上问题定位有极大帮助。你可以在这里手动执行一次任务“执行一次”按钮或者查看历史调度记录分析任务执行的成功率和耗时趋势。5. 高级特性与生产环境实践基础功能跑通后我们来看看那些能让你的调度系统更健壮、更易用的高级特性和实践。5.1 路由策略深度解析路由策略决定了在集群环境下任务的分配逻辑。理解每种策略的适用场景很重要策略描述适用场景第一个固定选择第一个注册的执行器测试环境或需要固定在某台机器执行的任务如文件清理。最后一个固定选择最后一个注册的执行器同上但更少用。轮询依次选择执行器均匀分配最常用。适用于无状态任务实现负载均衡。随机随机选择一台执行器负载均衡结果与轮询类似。一致性HASH对任务ID进行Hash计算相同ID总是路由到同一台机器关键场景。适用于有状态任务或需要保证同一数据源顺序处理的任务如分片任务。最不经常使用选择当前被调用次数最少的执行器追求更精细的负载均衡但调度中心需要维护调用计数。最近最久未使用选择最久未被调用的执行器类似LFU旨在充分利用所有执行器资源。故障转移按照顺序依次进行心跳检测第一个心跳检测成功的机器选定为目标执行器并发起调度保证高可用。当首选执行器故障时自动切换到健康的备用机。忙碌转移按照顺序依次进行空闲检测第一个空闲检测成功的机器选定为目标执行器并发起调度避免任务堆积。当某台执行器线程池繁忙时将新任务路由到其他空闲机器。分片广播广播触发对应集群中所有机器执行一次任务同时系统自动传递分片参数大数据处理利器。用于并行处理下文详述。实操心得对于大多数普通的定时Job使用“轮询”即可。如果任务处理的数据具有分区特性例如按用户ID尾号分库强烈推荐使用“一致性HASH”可以避免数据被路由到错误的机器导致找不到。而“故障转移”和“忙碌转移”是生产环境提升可靠性的重要策略。5.2 分片广播应对海量数据处理的利器这是XXL-JOB非常强大的一个功能。想象一下你需要处理一张有上亿条记录的表单机处理可能要几个小时。分片广播可以将这个任务拆分成多个子任务由集群中的所有执行器实例并行处理。工作原理在调度中心为任务选择“分片广播”路由策略。当任务触发时调度中心会向该执行器集群下的每一个在线实例都发送一次任务触发请求。关键点在于调度中心会为每次请求附带两个分片参数分片索引index和分片总数total。例如集群有3个实例那么实例A收到的参数是(0, 3)实例B是(1, 3)实例C是(2, 3)。在你的JobHandler中通过XxlJobHelper.getShardIndex()和XxlJobHelper.getShardTotal()获取这两个参数。你的业务逻辑根据这两个参数决定自己处理哪一部分数据。经典的做法是根据ID取模id % total index。示例代码分片处理任务XxlJob(shardingJobHandler) public void shardingJobHandler() throws Exception { // 获取分片参数 int shardIndex XxlJobHelper.getShardIndex(); int shardTotal XxlJobHelper.getShardTotal(); XxlJobHelper.log(分片参数当前分片索引 {}, 总分片数 {}, shardIndex, shardTotal); // 模拟从数据库查询所有待处理数据ID列表 (这里简化) ListLong allIds fetchAllDataIds(); for (Long id : allIds) { // 根据分片参数决定当前实例处理哪些数据 if (id % shardTotal shardIndex) { XxlJobHelper.log(处理数据ID: {}, id); // 执行具体的业务处理 processSingleData(id); } } XxlJobHelper.handleSuccess(分片任务执行完毕分片索引 shardIndex); }注意事项数据划分的均匀性确保你的数据划分逻辑如取模能大致均匀地将数据分配到各个分片避免数据倾斜。任务幂等性分片广播是并行执行要考虑你的任务是否支持重复执行而不产生副作用。如果网络抖动导致调度中心重试可能会再次触发广播。资源竞争如果任务涉及到对共享资源如同一个文件、同一个数据库行的写操作需要引入分布式锁等机制来协调避免冲突。5.3 失败重试与报警机制任务失败是常态一个好的调度系统必须能妥善处理失败。失败重试在任务配置中设置“失败重试次数”。当任务执行失败回调结果为FAIL或超时时调度中心会自动重新触发该任务直到成功或达到重试上限。重试间隔有内置策略如立即重试、间隔一段时间重试。建议对于非幂等性任务如发送消息、创建唯一记录重试次数要谨慎设置最好为0或1并配合业务逻辑做好幂等处理。邮件报警在任务配置中填写“报警邮件”。任务失败且重试耗尽后调度中心会向这些邮箱发送报警邮件。邮件内容包含任务ID、描述、失败信息等方便快速定位。生产环境必备。更高级的报警XXL-JOB原生支持邮件报警。如果你需要对接公司内部的监控系统如Prometheus Alertmanager、钉钉/企业微信机器人可以扩展其XxlJobCompleter组件在任务失败回调时自定义报警逻辑将信息推送到其他渠道。5.4 调度中心集群与高可用部署单点部署的调度中心是故障的潜在风险点。生产环境必须部署集群。数据库共享所有调度中心实例必须连接同一个MySQL数据库。XXL-JOB的所有状态任务、日志、执行器注册信息都存储在DB中这是实现集群化的基础。负载均衡在调度中心实例前部署Nginx等负载均衡器将请求包括执行器的注册请求和回调请求分发到多个实例。执行器配置的admin.addresses可以填写这个负载均衡器的地址或者填写所有实例地址用逗号分隔。调度竞争与锁你可能会担心多个调度中心实例会不会同时触发同一个任务XXL-JOB内部使用了数据库行锁SELECT ... FOR UPDATE来保证集群环境下同一个任务的同一调度周期内只有一个调度中心实例能成功触发。这是一种简单有效的分布式锁实现。执行器感知执行器注册时会向配置的所有调度中心地址注册。任何一个调度中心实例都能看到全量的在线执行器。当某个调度中心实例触发任务时它会从自己感知到的在线执行器列表中根据路由策略选择一个。这样即使某个调度中心实例宕机其他实例可以立即接管所有任务的调度工作实现了高可用。6. 常见问题排查与性能调优在实际使用中你肯定会遇到各种问题。这里总结几个最常见的问题和排查思路。6.1 执行器注册失败现象调度中心“执行器管理”页面看不到你的应用或者状态显示为“离线”。检查1网络连通性。这是最常见的原因。确保执行器所在服务器能访问调度中心的地址和端口默认8080。同时调度中心也必须能访问执行器的executor.port默认9999。可以用telnet或curl命令测试。检查2AppName一致性。核对执行器配置文件中的xxl.job.executor.appname和调度中心Web界面“执行器管理”中配置的AppName是否完全一致包括大小写。检查3调度中心地址。检查执行器配置的xxl.job.admin.addresses是否正确末尾不要有多余的斜杠/。如果是集群地址用逗号分隔不能有空格。检查4AccessToken。如果调度中心配置了xxl.job.accessToken那么执行器配置也必须加上完全相同的Token否则认证失败。检查5执行器日志。查看执行器应用启动日志搜索“XxlJobExecutor”或“注册成功”等关键字看是否有错误信息。通常注册失败会有明确的异常堆栈。6.2 任务触发但未执行现象调度日志显示“调度成功”但“执行结果”是“失败”或“空”且没有执行日志。检查1JobHandler名称。确认调度中心任务配置的“JobHandler”是否与代码中XxlJob注解定义的名称完全一致。检查2执行器线程池。执行器内嵌的Jetty/Netty服务器和任务执行线程池可能已满。查看执行器日志是否有线程池拒绝的异常。可以适当调大xxl.job.executor.corePoolSize等线程池参数在配置文件中配置。检查3任务超时。如果任务执行时间过长超过了配置的“任务超时时间”调度中心会判定为失败。检查任务逻辑是否有性能瓶颈或适当调大超时时间。检查4执行器GC或卡顿。执行器服务器负载过高发生长时间GC导致无法及时处理调度请求或回调结果。监控服务器资源使用情况。6.3 任务被重复执行现象同一个任务在短时间内被执行了多次。检查1阻塞处理策略。确认任务的“阻塞处理策略”是否设置为“并行执行”。如果是那么在上一次调度未完成时新的调度会新起线程执行导致并发。根据业务需要改为“单机串行”或“丢弃后续调度”。检查2调度中心集群与时钟。确保所有调度中心实例的服务器时间同步使用NTP服务。如果时间不同步可能导致同一个调度周期在不同实例上被误判为不同周期从而重复触发。检查3失败重试。检查是否是任务失败后重试机制导致的重复执行。这是正常现象需确保你的任务逻辑是幂等的。6.4 性能调优建议调度中心数据库连接池调度中心对数据库的读写非常频繁调度扫描、日志记录。务必配置一个合适的数据库连接池如HikariCP并监控连接数。调度线程池配置文件application.properties中的xxl.job.triggerpool.fast.max和xxl.job.triggerpool.slow.max控制了调度线程池的大小。如果任务数量非常多成千上万可以适当调大这些值但也要考虑数据库的压力。日志清理调度日志表xxl_job_log会快速增长定期清理配置xxl.job.logretentiondays或归档历史数据避免影响调度性能。执行器任务线程池通过xxl.job.executor.corePoolSize等参数调整执行器任务线程池大小。根据任务的平均耗时和并发量来设定。太小会导致任务排队太大会耗尽服务器资源。日志输出XxlJobHelper.log()输出的日志会同时写入本地文件logpath和回调给调度中心存入数据库。对于非常高频的任务过多的日志会影响性能。生产环境建议对日志进行分级只在必要时记录详细日志。从简单的Scheduled注解到引入完整的XXL-JOB调度平台最深的体会是“可控性”和“可观测性”带来的安心感。以前定时任务就像黑盒跑了没有、成功与否、为什么失败都要去翻服务器日志效率极低。现在所有任务的状态、日志、历史记录一目了然报警机制也能让我们第一时间响应问题。几个让我印象深刻的点一是分片广播功能它用一种相对简单的方式解决了大数据量批处理的并行化问题实用性超强二是失败重试和路由策略的组合让任务具备了初步的容错和负载均衡能力三是其架构的简洁性调度中心与执行器通过HTTP解耦部署和扩展都非常方便。最后分享一个小技巧对于非常重要的核心业务任务除了配置邮件报警我通常会将其“任务ID”记录下来并编写一个简单的脚本定期通过XXL-JOB提供的RESTful API调度中心内置查询该任务最近一次的执行状态。如果发现连续失败或超过一定时间未执行就通过更强烈的渠道如电话告警形成多级保障。XXL-JOB的API文档在其官方GitHub Wiki上可以找到这为集成运维监控提供了很大便利。
)
