关于java:使用Elastic-Job的时候报Job-conflict-with-register-center如何处理

昨天,有群友反馈依据之前这篇《应用Elastic Job实现定时工作》文章编写测试定时工作的时候,报了相似上面的这个谬误:

Caused by: org.apache.shardingsphere.elasticjob.infra.exception.JobConfigurationException: Job conflict with register center. The job 'my-simple-job' in register center's class is 'com.didispace.chapter72.MySimpleJob', your job class is 'com.didispace.chapter74.MySimpleJob'
    at org.apache.shardingsphere.elasticjob.lite.internal.config.ConfigurationService.checkConflictJob(ConfigurationService.java:86) ~[elasticjob-lite-core-3.0.0.jar:3.0.0]
    at org.apache.shardingsphere.elasticjob.lite.internal.config.ConfigurationService.setUpJobConfiguration(ConfigurationService.java:70) ~[elasticjob-lite-core-3.0.0.jar:3.0.0]
    at org.apache.shardingsphere.elasticjob.lite.internal.setup.SetUpFacade.setUpJobConfiguration(SetUpFacade.java:66) ~[elasticjob-lite-core-3.0.0.jar:3.0.0]
    at org.apache.shardingsphere.elasticjob.lite.internal.schedule.JobScheduler.<init>(JobScheduler.java:84) ~[elasticjob-lite-core-3.0.0.jar:3.0.0]
    at org.apache.shardingsphere.elasticjob.lite.api.bootstrap.impl.ScheduleJobBootstrap.<init>(ScheduleJobBootstrap.java:36) ~[elasticjob-lite-core-3.0.0.jar:3.0.0]
    at org.apache.shardingsphere.elasticjob.lite.spring.boot.job.ElasticJobBootstrapConfiguration.registerClassedJob(ElasticJobBootstrapConfiguration.java:101) ~[elasticjob-lite-spring-boot-starter-3.0.0.jar:3.0.0]
    at org.apache.shardingsphere.elasticjob.lite.spring.boot.job.ElasticJobBootstrapConfiguration.constructJobBootstraps(ElasticJobBootstrapConfiguration.java:84) ~[elasticjob-lite-spring-boot-starter-3.0.0.jar:3.0.0]
    at org.apache.shardingsphere.elasticjob.lite.spring.boot.job.ElasticJobBootstrapConfiguration.createJobBootstrapBeans(ElasticJobBootstrapConfiguration.java:57) ~[elasticjob-lite-spring-boot-starter-3.0.0.jar:3.0.0]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_151]
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_151]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_151]
    at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_151]
    at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:389) ~[spring-beans-5.3.8.jar:5.3.8]
    at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMethods(InitDestroyAnnotationBeanPostProcessor.java:333) ~[spring-beans-5.3.8.jar:5.3.8]
    at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:157) ~[spring-beans-5.3.8.jar:5.3.8]
    ... 17 common frames omitted

依据谬误音讯Job conflict with register center. The job 'my-simple-job' in register center's,初步判断是ZooKeeper中存储的工作配置呈现抵触:工作名一样,但实现类不同。

通过一番交换,原来他是应用公司测试环境的ZooKeeper来写的例子做测试,同时之前有共事(也是DD的读者)也写过相似的工作,因为配置的工作名称是拷贝的,所以呈现了工作名称绝对,但实现类不同的状况。

实际上,如果咱们在一个大一些的团队做开发的时候,只有存在多零碎的话,那么定时工作的重名其实是很有可能产生。比方:很多利用都可能存在一些定时清理某些资源的工作,就很可能起一样的名字,而后注册到同一个ZooKeeper,最初呈现抵触。 那么有什么好方法来解决这个问题吗?

办法一:工作创立的对立治理

最原始的解决办法,就是集中的治理工作创立流程,比方:能够开一个Wiki页面,所有工作在这个页面上注销,每个人注销的时候,能够查一下想起的名字是否曾经存在。如果存在了就再想一个名字,并做好注销。

这种办法很简略,也很好了解。但存在的问题是,当工作十分十分多的时候,这个页面内容就很大,保护起来也是十分麻烦的。

办法二:巧用Elastic Job的namespace属性来隔离工作名称

回顾一下之前第一篇写定时工作的时候,对于注册核心的配置是不是有上面两项:

elasticjob.reg-center.server-lists=localhost:2181
elasticjob.reg-center.namespace=didispace

第一个elasticjob.reg-center.server-lists不多说,就是ZooKeeper的拜访地址。这里要重点讲的就是第二个参数elasticjob.reg-center.namespace

其实在ZooKeeper中注册工作的时候,真正抵触的并不纯正是因为工作名称,而是namespace + 工作名称,全副一样,才会呈现问题。

所以,咱们只须要把每个利用创立的工作都隔离在本人独立的namespace里,那么是不是就不会和其余利用呈现抵触了呢?

最初,我给出了上面这样的倡议:

spring.application.name=chapter74

elasticjob.reg-center.server-lists=localhost:2181
elasticjob.reg-center.namespace=${spring.application.name}

即:将定时工作服务的elasticjob.reg-center.namespace设置为以后Spring Boot利用的名称统一spring.application.name

通常,咱们在布局各个Spring Boot利用的时候,都会做好唯一性的布局,这样将来注册到Eureka、Nacos等注册核心的时候,也能够保障惟一。

利用好这个惟一参数,也能够不便的帮咱们把各个利用的定时工作也都隔离进去,也就解决了文章结尾,咱们所说的场景了。

本系列教程《Spring Boot 2.x基础教程》点击中转!,欢送珍藏与转发!如果学习过程中如遇艰难?能够退出咱们Spring技术交换群,参加交换与探讨,更好的学习与提高!

代码示例

本文的残缺工程能够查看上面仓库中的chapter7-4目录:

  • Github:https://github.com/dyc87112/SpringBoot-Learning/
  • Gitee:https://gitee.com/didispace/SpringBoot-Learning/

如果您感觉本文不错,欢送Star反对,您的关注是我保持的能源!

欢送关注我的公众号:程序猿DD,分享其余中央看不到的常识与思考

【腾讯云】轻量 2核2G4M,首年65元

阿里云限时活动-云数据库 RDS MySQL  1核2G配置 1.88/月 速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据