解决ElasticJob项目重启ZooKeeper注册冲突以及zkCli删除目录
背景
在现代化的分布式调度系统中，ElasticJob 是一个非常流行的选择。它利用 ZooKeeper 作为注册中心来管理任务分片。然而，有时在项目重启时，会遇到 ZooKeeper 注册冲突的问题，即任务名已在注册中心存在。本文将详细讲解如何解决此问题，以及如何使用 zkCli 删除ZooKeeper的目录。
问题描述
ElasticJob 重启时的注册冲突
使用 ElasticJob 的最新版本（3.0.1）时，重启项目会碰到 ZooKeeper 注册冲突的问题。具体表现为，因定时任务使用了代理，导致项目重启时报任务名冲突，提示任务已经在注册中心存在。
zkCli 删除目录
删除ZooKeeper节点目录也是我们维护和管理ZooKeeper时常见的操作。当需要清理已经废弃的节点时，删除操作显得尤为重要。
解决方案
依赖配置
首先，确保项目中使用的是 ElasticJob 的最新版本：
<dependency>
<groupId>org.apache.shardingsphere.elasticjob</groupId>
<artifactId>elasticjob-lite-spring-boot-starter</artifactId>
<version>3.0.1</version>
</dependency>
使用自定义的 JobClassNameProvider
问题原因：
定时任务使用了代理，默认情况下会读取代理类名称，而不是原始类名称，导致任务名冲突。解决思路：
自定义一个JobClassNameProvider，在项目重启时，确保读取到的是原始类名称，而不是代理类名称。实现自定义
JobClassNameProvider：
public class CustomJobClassNameProvider implements JobClassNameProvider {
@Override
public String getJobClassName(ElasticJob elasticJob) {
String elasticJobClassName = ClassUtils.getUserClass(elasticJob).getName();
return AopUtils.isAopProxy(elasticJob) ? elasticJobClassName : elasticJob.getClass().getName();
}
}
在这里，我们使用 ClassUtils.getUserClass(elasticJob).getName() 方法获取原始类名，这样就避免了代理类引起的冲突问题。
- 注册自定义类：
在项目的src/main/resources目录下新建一个META-INF目录，在META-INF目录下创建services目录，创建一个名为org.apache.shardingsphere.elasticjob.lite.internal.setup.JobClassNameProvider的文件，内容如下：
你的类全路径名，例如：com.example.CustomJobClassNameProvider
使用 zkCli 命令操作ZooKeeper
以下是常用的 zkCli 操作步骤：
进入 ZooKeeper 安装目录的
bin文件夹：cd /var/www/data/zookeeper/zookeeper-3.8.0/bin启动 zkCli：
./zkCli.sh查看节点目录：
[zk: localhost:2181(CONNECTED) 21] ls /删除节点目录：
删除/elasticjob-admin-api-v0.7目录及其子目录：[zk: localhost:2181(CONNECTED) 22] deleteall /elasticjob-admin-api-v0.7
总结
通过自定义 JobClassNameProvider，可以有效解决 ElasticJob 在重启时引起的 ZooKeeper 注册冲突问题。使用 zkCli 也可以方便地管理和删除 ZooKeeper 节点，这对于维护一个健康的 ZooKeeper 集群系统至关重要。
希望这篇文章能够帮助你解决 ElasticJob 项目重启冲突以及 ZooKeeper 节点管理的问题。如果你有其他的疑问或更好的解决方案，欢迎在评论区留言讨论！
