elasticjob是使用zk做分布式协调,包括分片参数配置,再分片,选主节点,作业状态等一系列配置和运行状态的数据都是保存在zk中,包括console是直接通过修改zk节点数据,使配置项直接生效的。
那么,当zk节点参数发生变化,elasticJob是如何感知的?
ListenerManager.png
在初始化JobScheduler对象中的schedulerFacade该属性的时候,构造方法中曾经初始化过ListenterManager,该对象主要做了一件事情,就是监控各zk节点数据的变化。
在这张图中,能看到所有的对zk节点监控的listener都是通过一些Listener去实现的。看类图:
zk监听.png
从类图上看,所有的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的相关配置重新生效。
作者:一滴水的坚持
链接:https://www.jianshu.com/p/4c3aaaedcddd