elasticjob是使用zk做分布式协调，包括分片参数配置，再分片，选主节点，作业状态等一系列配置和运行状态的数据都是保存在zk中，包括console是直接通过修改zk节点数据，使配置项直接生效的。
那么，当zk节点参数发生变化，elasticJob是如何感知的？
在初始化JobScheduler对象中的schedulerFacade该属性的时候，构造方法中曾经初始化过ListenterManager，该对象主要做了一件事情，就是监控各zk节点数据的变化。
在这张图中，能看到所有的对zk节点监控的listener都是通过一些Listener去实现的。看类图：
从类图上看，所有的zk节点的监控都是实现TreeCacheListener接口的，那么TreeCacheListener这个接口到底是什么？
在curator中，提供了三种缓存方式，PathCache，NodeCache，TreeCache，并支持对这三种缓存做监控，进而间接监控了zk节点。分别如下：
-
Path Cache 可以监控某个节点的子节点
- PathChildrenCacheListener 节点监听器接口
-
Node Cache 监控某一个特定节点
- NodeCacheListener 节点监听器接口
-
Tree Cache 除了监控节点，还可以监控该节点的子节点，像Path Cache和Node Cache的组合，监控整个树
- TreeCacheListener 节点监听器接口
再回头看看上篇博客，在elastic-Job中，是使用treeCache去缓存数据的，并且在JobScheduler.init()方法中，调用了JobRegistry.getInstance().registerJob()方法，该方法里又调用了regCenter.addCacheData("/" + jobName);
public void init() {
LiteJobConfiguration liteJobConfigFromRegCenter = schedulerFacade.updateJobConfiguration(liteJobConfig);
JobRegistry.getInstance().setCurrentShardingTotalCount(liteJobConfigFromRegCenter.getJobName(), liteJobConfigFromRegCenter.getTypeConfig().getCoreConfig().getShardingTotalCount());
JobScheduleController jobScheduleController = new JobScheduleController(
createScheduler(), createJobDetail(liteJobConfigFromRegCenter.getTypeConfig().getJobClass()), liteJobConfigFromRegCenter.getJobName());
//在这里注册作业，添加TreeCache
JobRegistry.getInstance().registerJob(liteJobConfigFromRegCenter.getJobName(), jobScheduleController, regCenter);
schedulerFacade.registerStartUpInfo(!liteJobConfigFromRegCenter.isDisabled());
jobScheduleController.scheduleJob(liteJobConfigFromRegCenter.getTypeConfig().getCoreConfig().getCron());
}
public void registerJob(final String jobName, final JobScheduleController jobScheduleController, final CoordinatorRegistryCenter regCenter) {
schedulerMap.put(jobName, jobScheduleController);
regCenterMap.put(jobName, regCenter);
//添加一条TreeCache
regCenter.addCacheData("/" + jobName);
}
在作业注册的时候添加了一个treeCache，实现对这个jobname命名的节点及其子节点监控。所以，当该节点及其子节点发生变化，所有监听该treeCache的Listener都会有感知。各个Listenter根据自己的逻辑判断是否是该节点变化，EventType是不是自己关心的类型等等做自己的义务逻辑。
class CronSettingAndJobEventChangedJobListener extends AbstractJobListener {
@Override
protected void dataChanged(final String path, final Type eventType, final String data) {
if (configNode.isConfigPath(path) && Type.NODE_UPDATED == eventType && !JobRegistry.getInstance().isShutdown(jobName)) {
JobRegistry.getInstance().getJobScheduleController(jobName).rescheduleJob(LiteJobConfigurationGsonFactory.fromJson(data).getTypeConfig().getCoreConfig().getCron());
}
}
}
//AbstractListenerManager.java
protected void addDataListener(final TreeCacheListener listener) {
jobNodeStorage.addDataListener(listener);
}
//JobNodeStorage.java
public void addDataListener(final TreeCacheListener listener) {
TreeCache cache = (TreeCache) regCenter.getRawCache("/" + jobName);
cache.getListenable().addListener(listener);
}
比如，CronSettingAndJobEventChangedJobListener该Listener，当节点数据发生变化，比如修改了zk上保存的cron表达式，首先该Listener会去判断是不是config节点，该节点发生的类型是否是update类型，是否又修改过节点信息，该job是不是已经停止，倘若符合这几个条件，就重启rescheduleJob该作业对应的调度器，使job的相关配置重新生效。
