etcd

etcd是一種無狀態的分佈式數據存儲集羣,用於配置共享和服務發現。數據庫

值得注意的是,分佈式系統中的數據分爲控制數據和應用數據。使用 etcd 的場景默認處理的數據都是控制數據,對於應用數據,只推薦數據量很小,可是更新訪問頻繁的狀況分佈式

 

1、存儲服務spa

A. etcd 數據的組織形式設計

etcd的API分爲兩種, 分別用export ETCDCTL_API=3和export ETCDCTL_API=2來區分. 兩種API的調用接口不一樣, 其數據組織形式也不一樣. API_2下,其key和value都存儲在內存中.接口

而API_3下,key存儲在內存中,value存儲在硬盤中. 顯然, API_3更有優點,由於key是相較於value來講要短小的多. 這裏咱們討論的是更爲經常使用的API_3下的數據組織.
在etcd中,key以B樹的形式存儲在內存中, value以B+樹的形式存儲在硬盤中. 爲何要以B/B+樹的形式來存儲呢? 這涉及到一個全部的數據系統都要面對的問題, 如何花更少的時間內存

將數據從硬盤中讀取出來. 衆所周知, 計算機的存儲體系裏, cache> 內存>>> 磁盤, 也就是說對於etcd來講,訪問一個數據最大的時間消耗在磁盤訪問. 那麼就要千方百計下降訪問磁盤的io

次數. 這個時候B/B+樹的優點就體現出來了. 下面詳細分析一下.集羣

B/B+樹模型的源頭是AVL(二叉平衡樹). 對於AVL來講, 它每個節點只存儲一個數據, 所以對於一個很龐大的AVL樹來講, 訪問一個數據的時間複雜度是log2 n. 這裏n是這棵AVL樹變量

存儲的數據總數. 假設有一個數據總量爲1023的AVL, 訪問某個數據最壞的狀況下須要訪問10個節點. 因爲AVL樹的節點之間不像數元素在內存中連續存儲, 這10次節點訪問操做配置

頗有可能包含屢次磁盤訪問. 所以拖慢了訪問速度. 而對於B/B+樹來講, 設計者將每個節點的大小設置爲內存一個分頁的大小(通常是4kb), 而內存的一個分頁的大小又等同於磁盤一個數據塊的大小.所以, B/B+樹相對於AVL來講的優點在於,它在硬盤中讀取數據時, 單位是4kb的數據塊而不是單個數據. 這樣, 它將數據塊讀取到內存中後再進一步查找,從而大大減小了磁盤I/O的次數.  關於B/B+樹在數據庫系統應用中更爲詳細的介紹網上有不少相關資料.再也不贅述.至於B樹和B+樹的區別,B+樹只在葉子節點中存儲data, 在非葉子節點中只存儲search_key,  B樹在非葉子節點中存儲的就是真正的數據.

B. etcd中如何存儲一個key-value

瞭解了B/B+樹的概念後, 咱們分析一下etcd如何將數據存儲到硬盤中. 首先,etcd中有個概念叫revision, 這個revision能夠理解爲是一個全局變量. 用戶每次執行一個操做, 例如插入一個

key-pair, 這個revision就會自增1, 能夠理解爲這個revision就是一個全局的ID,表示已經執行了多少次操做, 每一次操做都有惟一的revision來識別.  對於內存中的B樹來講, 它在進行查找時所使用的search-key是etcd key,  節點中存儲的就是revision信息.而硬盤中存儲的B+樹的search-key就是revision值, 其節點中存儲的是etcd key和etcd value. 經過這樣的組織結構, etcd作到了保存每個key 的每個歷史記錄. 

至此,咱們能夠梳理一下etcd查找關鍵字,例如"spe",的過程, 首先etcd根據"spe"去內存中遍歷B樹, 找到這個key所對應的revision, 這裏revision是一組數字,包含了"spe"的每一次修改. 從

這一組revision中找到最大的那一個,若是用戶指定了某個revision的話, 那麼就取出用戶指定的那個. 而後拿着revision去硬盤中查找B+樹, 依次將節點讀入內存進行查找.直至到達葉子節點,而且最終找到想要的值.

 

2、

相關文章
相關標籤/搜索