小编点评

**改造流程：** 1. 新增注册、删除 Catalog 的需要的一些 API 接口对外提供服务。 2. 通过 Coordinator 节点 API 注册新的数据源同时将相关的数据源信息保存到数据库，状态 Status=2。 3. 新增 WorkerCatalogSyncTask，Worker节点同步功能，参考了 Trino 里面的 CatalogPruneTask 功能，通过Coordinator定时任务捕获到新增数据源[Status=2]通知到所有的Worker节点进行注册。 4. 所有 Worker 注册完毕后，修改数据源状态为 0。 5. 让 Worker 节点启动的时候也能跟 Coordinator 一样加载是有数据源【DynamicCatalogManageMoudle 模式、文件模式本来就可以加载的】。 **代码实现：** 1. 让 Worker 跟 Coordinator 一样有加载 catalog 目录的功能，新增 WorkerDynamicCatalogManager 这个参考 CoordinatorDynamicCatalogManager 实现，基本一样，把 Worker 跟 Coordinator 一样的服务启动的时候注入，让 Worker 跟 Coordinator有一样的功能，否则Worker 初始化不会自动加载数据源。 2. WorkerCatalogSyncTask，参考 CatalogPruneTask ，只要API的部分改造完成，这个地方就很好弄了，仿照一个就可以自动固定时间去访问各个Worker节点的API信息进行注册，这样就只需要跟Coordinator 通信就可以了。

正文

     原来没事的时候改了一个这样的功能，当时也没有仔细研究，后来也没继续弄。详细可以参考 https://www.cnblogs.com/liuzx8888/p/17635913.html

当时有1个问题：新增数据源需要每一个节点都去调取API注册，这样非常麻烦，最近闲下来又研究了一下，在原先的基础上做了一些改造。

具体流程：

具体的流程：

        1.新增注册、删除 Catalog的需要的一些Api接口对外提供服务

        2.通过 Coordinator 节点 API 注册新的数据源同时将相关的数据源信息保存到数据库，状态Status=2

        3.新增 WorkerCatalogSyncTask，Worker节点同步功能，参考了Trino 里面的 CatalogPruneTask功能，通过Coordinator定时任务捕获到新增数据源[Status=2]通知到所有的Worker节点进行注册

        4.所有的Worker注册完毕后，修改数据源状态为0

        5.让Worker节点启动的时候也能跟Coordinator 一样加载是有数据源 【DynamicCatalogManageMoudle 模式、文件模式本来就可以加载的】

 

     这样的改造好处就是所有的Catalog存储在数据库不容易丢失，无论哪个节点失败了或者新增节点都能从数据库获取到最近的Catalog目录，保证每个节点的Catalog都是最新的。

 

具体的一些代码实现截图给大家参考下，前前后后调试了很多，写的有点乱。

 

这些具体的可以参照前面的文章，Github 2个推送已经实现了基本的功能，我这里截图我自己实现的一部分：

1.让Worker 跟 Coordinator 一样有加载catalog目录的功能，新增WorkerDynamicCatalogManager 这个参考 CoordinatorDynamicCatalogManager 实现，基本一样，

把Worker跟Coordinator 一样的服务启动的时候注入，让Worker跟Coordinator有一样的功能，不然Worker初始化不会自动加载数据源。

 

2.WorkerCatalogSyncTask，参考CatalogPruneTask ，只要API的部分改造完成，这个地方就很好弄了，仿照一个就可以自动固定时间去访问各个Worker节点的API信息进行注册，这样就只需要跟Coordinator 通信就可以了

 

 

 

实践效果：

 定时获取是否有新增的数据源

 

API注册

 Coordinator：数据库会捕获到新增了1个Catalog，Worker注册完，数量从1变成0

 Worker：新增了相同的Catalog