開源配置中心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{}佔位符時就已經肯定了的.