开源配置中心xxl-conf的核心原理分析

XXL-CONF是一款轻量级的开源配置中心项目,由国内大牛许雪里开发.下面是官方对其优势做出的描述:

一个轻量级分布式配置管理平台，拥有"轻量级、秒级动态推送、多环境、跨语言、跨机房、配置监听、权限控制、版本回滚"等特性。现已开放源代码，开箱即用。

开源项目地址:

https://gitee.com/xuxueli0323/xxl-conf

鄙人有幸拜读了大神的源码,分享一下本身的理解:

项目分为配置中心服务端和客户端两个部分.
客户端与服务端经过http接口进行通讯.
服务端为客户端提供了两个http接口:
    一个查询配置的接口,一个监控配置是否发生变动的接口.
    查询配置的接口,只会从本地磁盘快照中获取配置,不会查询数据库.
    监控接口返回的是一个DeferredResult对象,它是SpringMVC提供的一种技术,
    能够实现服务器端向客户端推送数据,不过调用该接口时,配置中心并不会直接给客户端返回数据,
    而是先将客户端请求和对应的DeferredResult对象缓存起来.

配置中心在启动时,会建立一个线程池,并启动两个线程:
    其中一个线程用来监控配置是否发生变动,具体是查询数据库中的一张表,
    该表只记录最近刚发生变化的数据,为保证明时性,线程会每隔1秒就查询一次该表,
    若是该表中有数据,就说明配置有变化,就当即更新本地快照,并广播给全部客户端;
    另外一个线程用于从数据库加载全量数据,考虑到数据量可能比较大,
    线程会间隔30秒查询一次数据库.若是数据有变化,就当即更新本地快照并广播给全部客户端.

配置中心广播机制:
    配置中心的广播机制是利用了SpringMCU提供的DeferredResult对象特性实现的.
    配置发生变动,配置中心不会直接将变动的数据推送给客户端,而是告诉客户端数据有变化,
    须要客户端主动发起http请求调用配置中心的查询接口获取最新的配置.
    DeferredResult对象默认的超时时间是30秒,若是配置没有发生变化,则等待超时返回.

客户端在启动的时候:
    首先会建立一个本地缓存用于保存配置数据,刚建立时本地缓存是空的.
    而后会启动一个守护线程,每隔3秒钟查看一下本地缓存是否有数据,线程会在此阻塞.
    同时客户端会去解析全部加了@XxlConf注解的字段或使用$XxlConf{}占位符配置,拿到key,
    向配置中心发送http请求查询数据,先将查询到的数据放入本地缓存,而后再给这些字段赋值.

    当客户端本地缓存中有数据的时候,会被守护线程扫描到,
    会向配置中心发送http请求查询本身须要的配置信息,查询到配置后,
    它会先比对一下配置中心的配置项和本地缓存中配置项是否相同,
    若是相同就直接忽略不处理,若是不相同,说明有变化,
    若是本地缓存仓库中没有该key,或该key的值为空,或该key的值有变化,
    则更新本地缓存;最后将缓存中的配置同步到镜像文件.

客户会经过守护线程与服务端保持长链接:
    客户端会循环调用配置中心的监控接口,
    若是配置中心数据有变化,会马上通知客户端,
    客户端接收到通知会马上调用配置中心的查询接口获取数据;
    若是配置中心的数据没有变动,则默认30秒后再调用查询接口;

 

客户端和配置中心的快照文件:
    客户端和配置中心都有使用快照文件来保证数据的安全性,
    快照文件都是一些properties文件,考虑到value的值可能比较大,
    为了提升检索效率,每个配置项用一个单独的文件来保存.
    文件名由环境+项目名+key组成,这样作便于查询的时候可以快速精准定位.
    
    配置中心的快照文件是在配置中心启动30秒左右被建立,
    前面提到过配置中启动的时候会启动一个线程,负责每隔30秒,
    会从数据库加载全量的配置数据,更新到快照文件.
    若是某个配置项有变动就覆盖其对应的快照文件,
    配置中心第一次启动的时候,快照文件是不存在的,
    快照文件不存在的话,会直接被建立.
    
    客户端的快照文件由客户端启动后开启的那个守护线程建立.
    守护线程会循环调用配置中心的监控接口,
    每隔30秒拉取一次配置,更新到快照文件.

 

注意:
    若是配置中心增长了新的配置,客户端是不会收到通知的,
    由于客户端每次请求接口只拉取本身所使用到的配置,
    本身所使用到的配置,是在客户端启动的时候经过扫描
    @XxlConf注解和$XxlConf{}占位符时就已经肯定了的.