Skip to content

Latest commit

 

History

History
9 lines (6 loc) · 2.37 KB

多个节点定时任务如何设置.md

File metadata and controls

9 lines (6 loc) · 2.37 KB

定时任务是一个常见的需求,如果只是单机部署的话, 可以直接使用springboot自带的schedule来完成。但是在分布式系统中,如何确保多个节点在同一时间只有一个服务执行定时任务?

在实际的过程中,换过几个定时任务框架,针对使用过的框架做一个简单的说明和分析。

框架对比和选择

  • 最开始使用的是xxl-job,这个项目是个人开发者维护的,不过github上star还是比较多的,所以就准备做个尝试。开始使用的时候就发现它是一个集中管理和集中调度的模式。有一个中心节点来进行任务分配,并且分配的方式还是通过自带的rpc调用方式,还需要在springboot服务中部署额外的jetty服务,感觉和现在的模式冲突太大,并且给官方提供了意见,不过被官方给否决了。后面查看了xxl-job的源码,感觉代码质量很一般,所以最终放弃了这个框架。
  • 然后引入了elastic-job,算是当当开源的框架,代码质量明显比xxl-job有了提升,他没有中心节点,是通过zk来实现了分布式的调度,支持的模式种类比较多,不过常用的只有一种模式,就是在多个节点中选择一个节点进行调度执行,算是比较完美的解决了定时调度的问题。但是随着springboot和springcloud的基础框架不停的迭代和升级,发现elastic-job已经没有更新,并且社区逐渐不活跃,作者也把主要的精力转移到另外的项目里面,这一块的维护力度明显下降。所以也打算选择新的框架来替换elastic-job
  • 本着项目轻量和简洁的目的,后面发现了shedlock这个项目,仅仅是利用底层存储(mysql、redis等)作为分布式锁。通过自定义的注解,并且结合springboot原生的schedule来完成分布式调度的执行的功能。他设计目标非常明确,并且代码十分简单,代码质量也不错,底层的依赖也特别少,并且也在持续更新。所以最后用shedlock替换了elastic-job,目前使用得也十分稳定。不过shedlock由于功能很基础,后面自己通过springboot的endpoint来进行了功能的扩展,实现了定时任务的触发、停止、改变调度周期等常规需求,来弥补一些业务上的需求。最终减少了基础组件依赖的同时高效的完成了目标。