简介: 本篇文章只是笔者使用xxl-job后的一些小心的,感觉xxl-job这块还是需要优化一些,个人感触,欢迎大家多交流
一.常用的策略模式不太合理
如上图所示,我们一般最常用的是两种,一个是轮询,一个是故障转移; 会遇到这种情况,执行器挂了,但是admin不知道,从前面文章我们可以知道,执行器从admin移除注册,有两种情况
- 1.执行器服务是优雅关闭,会自动调用 /reigstRomeve方法告诉admin,自己移除
- 2.admin会通过定时任务扫描,每90秒扫描一次执行器上次注册到时间,如果超过90s,就主动移除这个执行器
这样就会有一种情况,如果执行器的项目,我们在关闭的时候,脚本使用kill -9的方式,执行器就不会发送registerRemve方法,需要90s后,admin主动剔除执行器,在这90s内,如果我们选择路由策略是"轮询",并且失败次数为0时候,这个时候如果任务分发到这个执行器的话,就会一直失败
如果要保证任务执行都是成功的,我们可以的路由策略可以选择"故障转移",但是根据故障转移的代码,每次都是从执行器地址列表的第一个来尝试,可能会导致下面情况
- 只要执行器第一个服务一直是可用的,就会永远使用第一个服务,导致第一个服务的任务数量很多,其他服务没有任务
总结:针对上面场景,我建议是"轮询+故障转移",每次轮询一个服务,再通过"故障转移",发送一个心跳,判断这个服务是否可用,这样感觉就会更加合理了
二.公司有这种场景
项目有一些场景,比如部署了10台服务器,有一个任务B,要查询所有的区域,然后对这些区域进行业务处理,非常耗时,业务方需要把所有区域查出来后,分发到这10台机器上,让每一台执行一部分业务的处理,类似hadoop的map-reduce思路,让所有的机器并行执行任务
但是xxl-job 只有一个分片策略,这个策略是所有的机器都执行相同的参数,不满足参数的分发执行,下面是我自己实现的"分片-并行执行"策略
代码已经提交到我的项目中,地址 项目
扩展:如果我们要执行的参数是需要动态查询的,我们就能创建两个任务
- 任务A,定时触发,查询动态参数,查出来之后,调用xxl-job的api,执行任务B
- 任务B:就是上面讲解的那个需要动态分发的任务,路由策略配置"分片-并行计算" 流程如下如所示:
