什么是GLUE模式
我们先来回顾一下当前定时任务的应用流程:首先,在调度中心内配置一个定时任务,随后,在项目代码中,针对需要定时执行的方法,我们需添加XXL-JOB的注解来标记。这意味着,如果后续需要对某个已存在的方法启用定时执行功能,或者修改定时任务的逻辑,通常需要经过代码的修改、重新发布及部署这一系列流程。
然而,利用XXL-JOB提供的GLUE模式,我们可以直接在线上对某个方法进行改造,将其转变为定时任务,而无需经历代码的修改、打包及重新部署的繁琐过程。这种方式极大地提高了定时任务配置的灵活性和效率,使得在不中断服务的情况下,能够快速地调整和优化定时任务的执行逻辑。
使用GLUE模式
首先声明一个测试方法,如下:
@Service
public class GlueTestService {
public void testMethod() {
System.out.println("定时任务执行时间" + new Date() + "testMethod()");
}
}
假如我们现在的场景需要我们不重新发布服务,只需要临时地定时调用它,就可以用GLUE模式。于是,我们先回到调度中心的任务管理,如下:
新增一个任务,把运行模式调整成GLUE这里的执行频率每十秒执行一次,如下:
打开这个任务的GLUE IDE
打开后进入到一个在线IDE的界面,在这里我们将需要定时执行的Service注入进来并将需要定时执行的方法在执行方法中调用即可
保存后,可以先进行一次测试
返回到项目控制台,可以看到执行的记录了
启动服务后,可以看到每隔十秒输出日志
负载均衡策略
在多实例部署的线上服务环境中,确保定义的定时任务不会重复执行是至关重要的。幸运的是,XXL-JOB已经为我们解决了这一难题,通过其内置的分布式调度机制来保证任务执行的唯一性和正确性。尽管我们在这里不深入探究其背后的具体实现原理,但可以简要地提及它在处理这种情况时采用的路由策略。
XXL-JOB通过一种高效的分布式锁或者类似的机制来协调多个实例之间的任务执行。当一个定时任务被触发时,它会首先尝试获取一个锁,只有成功获取到锁的实例才会执行该任务。其他实例在检测到锁已被占用时,会放弃执行该任务,从而避免了重复执行的问题。这种路由策略确保了任务在分布式环境中的正确性和可靠性,使我们能够放心地在多实例环境下部署和运行定时任务。
代码示例
需要在本地启动多个demo实例进行测试,如下
本地测试环境中,使用虚拟机进行配置时,需要注意出来服务的端口号还需要对执行器的端口号进行区分
来到调度中心可以看到,执行器的机器地址显示两个实例
任务启动后观察项目控制台,可以看到只有一个机器有执行记录,且没有重复,要实现负载均衡就需要修改任务的路由策略。
修改任务的路由策略
这里我改成轮训策略,但需要注意的是:修改路由策略需要停止任务并重新启动,保存成功后,再次观察控制台,如下:
、