在初始化 GroupDataSource 的时候,会往它的配置管理器 DefaultDataSourceConfigManager中添加了一个配置监听器
代码路径:GroupDataSource#init() -> initConfig();
|
this.dataSourceConfigManager.addListerner(new GroupDataSourceConfigChangedListener()); |
|
public class GroupDataSourceConfigChangedListener implements PropertyChangeListener { |
|
|
|
public synchronized void propertyChange(PropertyChangeEvent evt) { |
|
**refresh**(evt.getPropertyName()); |
|
} |
|
} |
|
在监听到配置变更(zk或http)的时候,会调用分组ds内部的 GroupDataSource#refresh
方法进行刷新
参考 分组GroupDataSource及其初始化 中初始化的写库和读库的 ds 类型
-
刷新写库
writeDataSource#refresh (FailOverDataSource#refresh)
筛选配置中的第一个写库,新建SingleDataSource 替换掉老的,然后销毁老的sds -
刷新读库
readDataSource#refresh (LoadBalanceDataSource#refresh)
- 筛选配置中的所有读库,新建SingleDataSource 替换掉老的,然后销毁老的sds
一般是直接重建底层 DataSource连接池 ,不然要根据底层数据库连接池的支持情况来 更新单个属性,这样适配起来就会非常的繁琐, 而这种db配置变更本身是非常低频或者在故障的时候急救措施, 重建 DataSource 期间少许的报错也可以接受
除了这个实时的配置更新之外,还有一个 DataSourceConfigRefresh 每隔1分钟,检查一次group分组和分组内single的配置是否发生变化; 这样就避免了 配置更新的时候由于网络异常等原因 数据源刷新失败
zebra 只支持整个GroupDataSource 粒度的配置刷新,没有单独刷新 SingleDataSource配置, 不能单独调整连接池的配置 如果读写分离中其中一个db节点故障,要切换成备份节点,这个时候 zebra就只能整体变动整个Group分组,切换会比较费时; 个人觉得还是需要支持单个 db节点(SingleDataSouce)的配置变更,方便故障切换
完整目录:数据库中间件zebra源码分析