Soul API網(wǎng)關(guān)源碼解析08 - 數(shù)據(jù)同步篇

目標(biāo)

  • 配置連接zookeeper(zk)注冊中心

    • soul-admin注釋websocket配置打開zk配置
    • soul-bootstrap同理注釋掉websocket配置打開zk配置
  • 啟動zk注冊中心并且查看是否啟動成功

  • zk數(shù)據(jù)節(jié)點注冊原理

    • 什么是Zookeeper
    • zk設(shè)計總覽
    • zk架構(gòu)
    • znode存儲結(jié)構(gòu)
    • watch機制
  • soul-admin之zk注冊流程

配置連接zookeeper注冊中心

soul-admin注釋websocket配置打開zk配置

image.png

soul-bootstrap同理注釋掉websocket配置打開zk配置

image.png

配置之前我本地運行了端口為 2181 的zk服務(wù)

啟動zk注冊中心,并且查看是否啟動成功

zkServer.sh start // 啟動服務(wù)
 zkServer.sh stop  // 關(guān)閉服務(wù) 
zkCli.sh // 啟動命令客戶端
image.png

出現(xiàn)如上圖圈出的SyncConnected代表zk啟動成功

小結(jié)

經(jīng)過源碼大致流程分析,非zk部分流程與websocket數(shù)據(jù)同步相同最終數(shù)據(jù)更新到當(dāng)前正在使用的plugin,和具體緩存。但是關(guān)于zk本身的節(jié)點注冊和數(shù)據(jù)變動如何通知關(guān)心的一方這塊的原理不是很清楚,臨時調(diào)整方案,先去研究下zk關(guān)于這兩塊的實現(xiàn)方式,之后再來完善soul這部分。

zk數(shù)據(jù)注冊原理分析

什么是Zookeeper

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them, which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed.

大概意思就是zk是一個維護配置信息,命名,提供分布式同步以及提供組(集群)服務(wù)的集中式服務(wù)。所有這些類型的服務(wù)都被應(yīng)用在分布式服務(wù)程序中。下面就是講zk誕生的前世吧,也就是背景。大概就是分布式應(yīng)用不好管理,沒有一個統(tǒng)一的方式方法區(qū)管理他們,由此zk誕生。

zk設(shè)計總覽

本次觀看的官網(wǎng)文檔 Zookeeper 3.6 Documentation

  • 設(shè)計目標(biāo)

zk很簡單,它允許分布式進(jìn)程(soul-admin,soul-bootstarp)通過共享分層名稱空間(/soul/plugin...)相互協(xié)調(diào),該命名空間的組織方式類似于標(biāo)準(zhǔn)的文件系統(tǒng)。命名空間由數(shù)據(jù)寄存器(znode)組成。它類似文件目錄。與設(shè)計用于存儲文件系統(tǒng)的目錄結(jié)構(gòu)又不同,因為zk是節(jié)點存儲在內(nèi)存中。這樣就意味著zk 可以實現(xiàn)高吞吐量和低延遲。

  • 設(shè)計初衷

大家知道分布式協(xié)調(diào)服務(wù)很難做。進(jìn)程之間很容易出現(xiàn)諸如競爭條件和死鎖之類的問題。zk為了讓后來者實施簡單規(guī)避這些問題,從此誕生主要是為了減輕分布式應(yīng)用程序從頭開始做協(xié)調(diào)性任務(wù)。

  • zk特性

  • zk本身是可復(fù)制的。ZooKeeper itself is intended to be replicated over a set of hosts called an ensemble. 組成zk服務(wù)的服務(wù)器都是必須相互了解的。他們維護內(nèi)存中的狀態(tài)圖像,以及持久存儲中的事務(wù)日志與快照。只要大多數(shù)服務(wù)可用,zk就可用。

ZK架構(gòu)

image.png

ZNode存儲結(jié)構(gòu)

  • 一次寫入、多次讀取,數(shù)據(jù)寫入后不可更改。

  • 可以存儲多個版本的數(shù)據(jù),以實現(xiàn)更新順序性。

  • 一次性讀取整個Znode,不支持部分讀取。

  • 根據(jù)數(shù)據(jù)的生命周期,具有4種節(jié)點,在創(chuàng)建時確定并且不能再修改。

  • 臨時節(jié)點(EPHEMERAL):不支持子節(jié)點,會在客戶端會話結(jié)束時被刪除。

  • 臨時順序節(jié)點(EPHEMERAL_SEQUENTIAL):臨時節(jié)點,但父節(jié)點會為一級子節(jié)點記錄創(chuàng)建時間,記錄節(jié)點的創(chuàng)建順序。

  • 持久節(jié)點(PERSISTENT):持久存儲,一般根據(jù)客戶端需求刪除。

  • 持久順序節(jié)點(PERSISTENT_SEQUENTIAL):持久節(jié)點,但父節(jié)點會為一級子節(jié)點記錄創(chuàng)建時間,記錄節(jié)點的創(chuàng)建順序。

Watch機制

客戶端可以通過watch機制關(guān)注Znode的信息變化,實現(xiàn)配置管理、數(shù)據(jù)同步和分布式鎖等功能。

客戶端首先需要注冊一個watch,來觀察某個Znode。當(dāng)出現(xiàn)數(shù)據(jù)更新或被刪除、子節(jié)點發(fā)生變化等情況時,Zookeeper集群會通過異步消息向客戶端發(fā)送事件通知。通知發(fā)送后,該watcher就會失效,如果此時再發(fā)送信息變化,客戶端就無法獲取新的通知,除非客戶端在進(jìn)行新的注冊(這塊soul就根據(jù)首次初始化watch之后,后面數(shù)據(jù)發(fā)生變化進(jìn)入處理前又再次注冊一次。也就解決watch使用完一次之后作廢掉,再次注冊原因了)??梢姡瑆atch機制能夠確保消息的順序性(舊消息被接收之前,客戶端無法獲得新消息)以及最終一致性,但無法確保所有的數(shù)據(jù)變化都能夠被觀察到。

Soul-Admin ZK注冊流程

經(jīng)過上面對zk特性了解之后,我們下面就分析下soul-admin端zk初始化的流程。

ZookeeperDataInit

image.png

因為實現(xiàn)了CommandLineRunner,在Bean初始化之后就會執(zhí)行run方法。這里面run 方法主要就是初始化soul那幾種基礎(chǔ)數(shù)據(jù)Rule,Auth,Meta。

image.png

根據(jù)圖和驗證我們知道soul在注冊數(shù)據(jù)到zk時候采用的持久節(jié)點。所以一般zk服務(wù)器不換的話,這里syncAll只會執(zhí)行一次,這個syncAll里面也就是從數(shù)據(jù)庫中全量拿出數(shù)據(jù),通過昨天分析的事件分發(fā)器,被zk的監(jiān)聽器接收到就將數(shù)據(jù)寫到zk對應(yīng)的節(jié)點里面

基礎(chǔ)數(shù)據(jù)改變數(shù)據(jù)同步

  • 數(shù)據(jù)發(fā)生變動ApplicationEvent 觸發(fā)DataChanged事件
  • zk監(jiān)聽器接收到數(shù)據(jù)發(fā)生變化,就判斷事件更新類型是否是DELETE,如果是Plugin數(shù)據(jù)變動,還要刪除對應(yīng)的Selector,Rule數(shù)據(jù),如果不是刪除就執(zhí)行創(chuàng)建或者更新節(jié)點的操作
image.png
  • 判斷節(jié)點數(shù)據(jù)是否存在,存在就寫數(shù)據(jù),不存在則先創(chuàng)建節(jié)點,然后在寫數(shù)據(jù)
image.png

總結(jié)

到這里我們了解清楚了zk到底是什么東西,具體admin端關(guān)于zk初始化以及基礎(chǔ)數(shù)據(jù)的處理化。同時數(shù)據(jù)發(fā)生變動之后是如何更新到zk節(jié)點的。中間事件通知分發(fā)原理早在前面已經(jīng)介紹過了,這里就不累贅了。至于bootstrap 那邊如何知道數(shù)據(jù)變化的下一章分析。

參考

soul github
soul document

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容