.NET Core采用的全新配置系统[10]: 配置的同步机制是如何实现的?

配置的同步涉及到两个方面:第一,对原始的配置文件实施监控并在其发生变化之后从新加载配置;第二,配置重新加载之后及时通知应用程序进而使后者能够使用最新的配置。要了解配置同步机制的实现原理,先得从认识一个名为ConfigurationReloadToken的类型开始。

目录 一、从ConfigurationReloadToken说起 二、Configuration对象与配置文件的同步 三、应用重新加载的配置 四、同步流程总结

一、从ConfigurationReloadToken说起

.NET Core绝大部分的数据同步场景下都使用到一个名为ChangeToken的对象,该对象绑定到某个需要被监控的对象,并该对象发生改变是对外发送通知,我们可以注册在被监控数据发生改变时可以自动执行的回调。在配置同步场景中,ConfigurationProvider会利用FileProvider监控配置文件的变化,并在变化时从新加载配置。ConfigurationReloadToken就是一个通知配置已经被重新加载的ChangeToken。

ConfigurationReloadToken本质上是对一个CancellationTokenSource对象的封装。如果我们对.NET基于Task对象的并行/异步编程有所了解的话,相信对CancellationTokenSource应该不会感到模式。总的来说,我们可以利用CancellationTokenSource创建的CancellationToken向某个异步执行的Task发送“取消任务”的信号。如下面的代码片段所示,ConfigurationReloadToken的HasChanged属性对应的是这个CancellationTokenSource对象的IsCancellationRequested。通过调用RegisterChangeCallback方法注册的回调实际上是注册到 CancellationTokenSource创建的CancellationToken对象上。

   1: public class ConfigurationReloadToken : IChangeToken
   2: {
   3:     private CancellationTokenSource _cts = new CancellationTokenSource();
   4:  
   5:     public void OnReload()
   6:     {
   7:         _cts.Cancel();
   8:     }
   9:  
  10:     public IDisposable RegisterChangeCallback(Action<object> callback, object state)
  11:     {
  12:         return _cts.Token.Register(callback, state);
  13:     }
  14:     
  15:     public bool ActiveChangeCallbacks
  16:     {
  17:         get { return true; }
  18:     }
  19:  
  20:     public bool HasChanged
  21:     {
  22:         get { return _cts.IsCancellationRequested; }
  23:     }
  24: }

当ConfigurationReloadToken的OnReload方法被执行的时候,这被封装的CancellationTokenSource对象的Cancel方法随之被调用。我们知道一旦这个Cancel方法被调用之后,CancellationTokenSource的IsCancellationRequested会马上变成True,意味着ConfigurationReloadToken的HasChanged属性也立即变成True。由于调用RegisterChangeCallback方法注册的回调最是注册到CancellationTokenSource创建的CancellationToken上的,所以该回调会在OnLoad方法被调用之后自动执行。

二、Configuration对象与配置文件的同步

在《聊聊默认支持的各种配置源》和《深入了解三种针对文件(JSON、XML与INI)的配置源》中,我们介绍了系统预定义的若干配置源,它们都通过相应的ConfigurationSource类型来表示,对于这些ConfigurationSource来说,只有针对配置文件的FileConfigurationSource才会涉及到配置同步的问题。其实这一点也可以由它们的定义看出来,因为只有FileConfigurationSource这个抽象类才定义了如下这个ReloadOnChange属性来控制当配置文件改变之后是否需要重新加载配置。换句话说,配置的同步首先需要解决的是由ConfigurationBuilder创建的Configuration对象与原始配置文件的内容同步的问题,而解决这个问题的途径就是对配置实施监控,并在文件发生改变之后自动重新加载配置。

   1: public abstract class FileConfigurationSource : IConfigurationSource
   2: {
   3:     ...
   4:     public bool ReloadOnChange { get; set; }
   5: }

我们知道 FileConfigurationProvdier总是利用一个FileProvider对象来读取对应的配置文件,除了读取文件内容之外,FileProvider的Watch方法自身就提供了文件监控的能力。FileConfigurationProvdier利用FileProvider监控配置文件,并在配置文件发生改变时自动加载配置的操作实现在如下所示的代码片段中。

   1: public abstract class FileConfigurationProvider : ConfigurationProvider
   2: {
   3:     ...
   4:     public FileConfigurationProvider(FileConfigurationSource source)
   5:     {
   6:         this.Source = source;
   7:         if (source.ReloadOnChange && (this.Source.FileProvider != null))
   8:         {
   9:             ChangeToken.OnChange(() => source.FileProvider.Watch(source.Path), this.Load);
  10:         }
  11:     }
  12: }

三、应用重新加载的配置

Configuration对象与配置文件的同步问题解决之后,还需要让应用程序感知到使用的Configuration对象已经发生改变,并且使之能够将新的配置应用到程序之中。从编程的角度来讲,这个问题很容易解决,我们只需要调用Configuration对象的GetReloadToeken方法得到一个ChangeToken对象,并将重新应用配置的操作注册作为回调注册到这个ChangeToken上面就可以了。

   1: public interface IConfiguration
   2: {
   3:     ...
   4:     IChangeToken GetReloadToken();
   5: }

程序应用重新配置的回调是注册到Configuration对象的GetReloadToken方法返回的ChangeToken对象上,而Configuration对象的重新加载最终是通过调用所有ConfigurationProvider的Load方法来实现的,所以两者之间必然存在着某种联系。说的具体一点,应用程序可以通过这个ChangeToken感知到配置系统针对ConfigurationProvider的Load方法的调用。要了解两者之间的联系,我们必须先弄清楚Configuration的 GetReloadToken方法返回的是怎样一个ChangeToken对象。

一个Configuration对象代表配置树的某个节点,对于组成同一棵配置树的所有Configuration对象来说,它们的GetReloadToken方法返回的ChangeToken都来源于代表根节点的ConfigurationRoot对象。说的更加具体一点,当我们调用它们的GetReloadToken的时候,返回的其实是调用ConfigurationRoot的同名方法的返回值,那么我们有必要了解一下ConfigurationRoot的GetReloadToken方法的逻辑。

   1: public class ConfigurationRoot : IConfigurationRoot
   2: {
   3:     private ConfigurationReloadToken _changeToken = new ConfigurationReloadToken();
   4:     private IList<IConfigurationProvider> _providers;
   5:  
   6:     public ConfigurationRoot(IList<IConfigurationProvider> providers)
   7:     {
   8:         _providers = providers;
   9:  
  10:         foreach (var provider in providers)
  11:         {
  12:             provider.Load();
  13:             ChangeToken.OnChange(() => provider.GetReloadToken(), this.RaiseChanged);
  14:         }        
  15:     }    
  16:  
  17:     public IChangeToken GetReloadToken()
  18:     {
  19:         return _changeToken;
  20:     }
  21:  
  22:     private void RaiseChanged()
  23:     {
  24:         Interlocked.Exchange<ConfigurationReloadToken>(ref _changeToken, new ConfigurationReloadToken()).OnReload();
  25:     }
  26:  
  27:     public void Reload()
  28:     {
  29:         foreach (var provider in _providers)
  30:         {
  31:             provider.Load();
  32:         }
  33:         this.RaiseChanged();
  34:     }    
  35: }

如上面的代码片段所示,ConfigurationRoot的GetReloadToken方法返回的是通过字段_changeToken表示的一个ConfigurationReloadToken对象。私有方法RaiseChanged通过调用ConfigurationReloadToken对象的OnReload向订阅者发送配置重新被加载的通知,由于ChangeToken只能使用一次,所以该方法总是为_changeToken字段附上一个新的ConfigurationReloadToken对象。

针对这个RaiseChanged方法的调用发生在两个地方,第一个地方发生在ConfigurationRoot的Reload方法上,也就是说当我们调用该方法以手工的方式重新加载配置的时候,注册到Configuration对象提供的ChangeToken上的回调也会自动执行。

针对RaiseChanged方法的调用还出现在ConfigurationRoot构造函数中。如上面的代码片段所示,ConfigurationRoot会调用每个ConfigurationProvdier的GetReloadToken方法,并将针对RaiseChanged方法的调用作为回调注册到返回的ChangeToken上,也就是说注册到Configuration对象提供的ChangeToken上的回调实际上注册到ConfigurationProvider提供的ChangeToken上。既然如此,如果 ConfigurationProvider提供的这个ChangeToken能够反映针对Load方法的调用,那么上面提到的关于Configuration提供的ChangeToken与ConfigurationProvider的Load方法之间的联系就建立起来了。那么ConfigurationProvider的Load方法与ChangeToken方法返回的ChangeToken究竟有没有关系呢?

   1: public abstract class ConfigurationProvider : IConfigurationProvider
   2: {
   3:     private ConfigurationReloadToken _reloadToken = new ConfigurationReloadToken();
   4:  
   5:     public IChangeToken GetReloadToken()
   6:     {
   7:         return_reloadToken;
   8:     }
   9:  
  10:     protected void OnReload()
  11:     {
  12:         Interlocked.Exchange<ConfigurationReloadToken>(ref_reloadToken, new ConfigurationReloadToken()).OnReload();
  13:     }
  14: }

如上面的代码片段所示,抽象类ConfigurationProvider的GetRealoadToken方法返回的是一个通过字段_reloadToken表示的ConfigurationReloadToken对象。该类型还定义了一个受保护的OnReload方法,该方法具有与上面介绍的RaiseChanged方法一样的逻辑,意味着ConfigurationProvider实际上是调用这个方法对外发送配置被重新加载的通知。针对这个OnLoad方法的调用发生在FileConfigurationProvider的Load方法中。所以上面提到的让ConfigurationProvider提供的ChangeToken能够反映针对Load方法的调用最终实现在FileConfigurationProvider中。

   1: public abstract class FileConfigurationProvider : ConfigurationProvider
   2: {
   3:     ...
   4:     public override void Load()
   5:     {
   6:         ...
   7:         base.OnReload();
   8:     }
   9: }

四、同步流程总结

上面我们通过代码分析的方式捋清了配置文件在发生改变的时候为什么会导致配置的重新加载,注册到Configuration通过GetRealoadToken方法提供的ChangeToken上的回调为什么会自动执行。可能都有读者的脑子里面还是比较晕,所以我们利用如下所示的序列图继续对这个过程进行讲解。用于读取配置文件内容的FileConfigurationProvder会调用FileProvder的Watch方法来监控文件的变化(实际上真正用于文件监控的实PhysicalFileProvider所示用的FileSystemWatcher),并且通过向返回的ChangeToken注册回调的方式来调用自身的Load方法来实现配置配置的重新加载。

当Load方法执行的时候,它会在配置加载完成之后调用调用Reload方法,后者利用一个ConfigurationReloadToken对象对外发出配置被重新加载的通知,最终会触发注册到Configuration对象上的回调的执行。注册到Configuration对象上的回调出了可以在配置被改动的时候自动触发之外,我们还可以直接调用ConfigurationRoot的Reload方法来触发它。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏编程

autoload自动加载机制使用

在PHP开发过程中,如果希望从外部引入一个class,通常会使用include和require方法,去把定义这个class的文件包含进来,但是这样可能会使得在...

232100
来自专栏我的博客

CI基础知识笔记

1.知识点 $config[‘url_suffix’] = ”;//url后缀 $config[‘enable_query_strings’] = FALS...

29430
来自专栏好好学java的技术栈

各大公司Java后端开发面试题总结

Java虚拟机规范中将Java运行时数据分为六种。 1.程序计数器:是一个数据结构,用于保存当前正常执行的程序的内存地址。Java虚拟机的多线程就是通过线程轮流...

71650
来自专栏Petrichor的专栏

git: .gitignore文件 (忽略文件)

Note: 切记目录名后面 一定要加 反斜杠 / ,不然会当成 单文件 处理。

21920
来自专栏自动化测试实战

RF接口测试(2)--http请求之get

54880
来自专栏Pythonista

Shell编程实战

Shell脚本语言是实现Linux/Unix系统管理及自动化运维所必须的重要工具,Linux系统的底层以及基础应用软件的核心大都涉及Shell脚本的内容。

34020
来自专栏逸鹏说道

Python3 与 C# 并发编程之~ 进程实战篇

之前说过 Queue:在 Process之间使用没问题,用到 Pool,就使用 Manager().xxx, Value和 Array,就不太一样了:

18840
来自专栏orientlu

FreeRTOS 消息队列

上面这几中方式中, 除了消息通知, 其他几种实现都是基于消息队列。消息队列作为主要的通信方式, 支持在任务间, 任务和中断间传递消息内容。 这一章介绍 Fre...

66420
来自专栏专注 Java 基础分享

Java并发之线程间的协作

     上篇文章我们介绍了synchronized关键字,使用它可以有效的解决我们多线程所带来的一些常见问题。例如:竞态条件,内存可见性等。并且,我们也说明了...

23390
来自专栏IMWeb前端团队

nodejs中错误捕获的一些最佳实践

本文作者:IMWeb yisbug 原文出处:IMWeb社区 未经同意,禁止转载 本文内容大部分来自 https://www.joyent.com/...

23760

扫码关注云+社区

领取腾讯云代金券