在初始化 GroupDataSource 的时候,会往它的配置管理器 DefaultDataSourceConfigManager中添加了一个配置监听器

代码路径:GroupDataSource#init() -> initConfig();

this.dataSourceConfigManager.addListerner(new GroupDataSourceConfigChangedListener());
	public class GroupDataSourceConfigChangedListener implements PropertyChangeListener {
		@Override
		public synchronized void propertyChange(PropertyChangeEvent evt) {
			**refresh**(evt.getPropertyName());
		}
}

在监听到配置变更(zk或http)的时候,会调用分组ds内部的 GroupDataSource#refresh 方法进行刷新
[zebra源码]GroupDataSource配置变更实时生效_配置管理

[zebra源码]GroupDataSource配置变更实时生效_配置管理_02

参考 分组GroupDataSource及其初始化 中初始化的写库和读库的 ds 类型

  1. 刷新写库 writeDataSource#refresh (FailOverDataSource#refresh) 筛选配置中的第一个写库,新建SingleDataSource 替换掉老的,然后销毁老的sds
  2. 刷新读库 readDataSource#refresh (LoadBalanceDataSource#refresh)
  3. 筛选配置中的所有读库,新建SingleDataSource 替换掉老的,然后销毁老的sds

一般是直接重建底层 DataSource连接池 ,不然要根据底层数据库连接池的支持情况来 更新单个属性,这样适配起来就会非常的繁琐, 而这种db配置变更本身是非常低频或者在故障的时候急救措施, 重建 DataSource 期间少许的报错也可以接受

除了这个实时的配置更新之外,还有一个 DataSourceConfigRefresh 每隔1分钟,检查一次group分组和分组内single的配置是否发生变化; 这样就避免了 配置更新的时候由于网络异常等原因 数据源刷新失败

zebra 只支持整个GroupDataSource 粒度的配置刷新,没有单独刷新 SingleDataSource配置, 不能单独调整连接池的配置
如果读写分离中其中一个db节点故障,要切换成备份节点,这个时候 zebra就只能整体变动整个Group分组,切换会比较费时; 个人觉得还是需要支持单个 db节点(SingleDataSouce)的配置变更,方便故障切换

完整目录:数据库中间件zebra源码分析