看圖輕鬆瞭解etcd

用一些圖示結合場景和文字輕鬆瞭解etcd，文章是針對etcd初學者的，目的是讓你們瞭解etcd是什麼、主要在什麼場景下使用、etcd集羣是怎麼工做的以及建立集羣時應該如何選擇集羣的節點數。

etcd 是一個高可用強一致性的鍵值倉庫在不少分佈式系統架構中獲得了普遍的應用，其最經典的使用場景就是服務發現。

做爲一個受到 ZooKeeper啓發而催生的項目，它除了擁有與之相似的功能外，更專一於如下四點。

• 簡單：易於部署，易使用。基於 HTTP+JSON 的 API 讓你用 curl 就能夠輕鬆使用。
• 安全：可選 SSL 客戶認證機制。
• 快速：每一個實例每秒支持一千次寫操做。
• 可信：使用一致性 Raft 算法充分實現了分佈式。

etcd 的場景默認處理的數據都是系統中的控制數據。因此etcd在系統中的角色不是其餘NoSQL產品的替代品，更不能做爲應用的主要數據存儲。etcd中應該儘可能只存儲系統中服務的配置信息，對於應用數據只推薦把數據量很小，可是更新和訪問頻次都很高的數據存儲在etcd中。

服務發現（Service Discovery）

服務發現要解決的是分佈式系統中最多見的問題之一，即在同一個分佈式集羣中的進程或服務，要如何才能找到對方並創建鏈接。本質上來講，服務發現就是想要了解集羣中是否有進程在監聽 udp 或 tcp 端口，而且經過名字就能夠查找和鏈接。要解決服務發現的問題，須要有下面三大支柱，缺一不可。

1. 一個強一致性、高可用的服務存儲目錄。基於 Raft 算法的 etcd 就是一個強一致性高可用的服務存儲目錄。
2. 一種註冊服務和監控服務健康狀態的機制。用戶能夠在 etcd 中註冊服務，而且對註冊的服務設置 key TTL，定時保持服務的心跳以達到監控健康狀態的效果。
3. 一種查找和鏈接服務的機制。經過在 etcd 指定的主題（由服務名稱構成的服務目錄）下注冊的服務也能在對應的主題下查找到。

etcd的核心組件

從 etcd 的架構圖中咱們能夠看到，etcd 主要分爲四個部分。

• HTTP Server：用於處理用戶發送的 API 請求以及其它 etcd 節點的同步與心跳信息請求。
• Store：用於處理 etcd 支持的各種功能的事務，包括數據索引、節點狀態變動、監控與反饋、事件處理與執行等等，是 etcd 對用戶提供的大多數 API 功能的具體實現。
• Raft：Raft 強一致性算法的具體實現，是 etcd 的核心。
• WAL：Write Ahead Log（預寫式日誌），是 etcd 的數據存儲方式。除了在內存中存有全部數據的狀態以及節點的索引之外，etcd 就經過 WAL 進行持久化存儲。WAL 中，全部的數據提交前都會事先記錄日誌。Snapshot 是爲了防止數據過多而進行的狀態快照；Entry 表示存儲的具體日誌內容。

一般，一個用戶的請求發送過來，會經由 HTTP Server 轉發給 Store 進行具體的事務處理，若是涉及到節點的修改，則交給 Raft 模塊進行狀態的變動、日誌的記錄，而後再同步給別的 etcd 節點以確認數據提交，最後進行數據的提交，再次同步。

用戶從集羣中哪一個節點讀寫數據？

爲了保證數據的強一致性，etcd集羣中全部的數據流向都是一個方向，從 Leader （主節點）流向 Follower，也就是全部 Follower 的數據必須與 Leader 保持一致，若是不一致會被覆蓋。

簡單點說就是，用戶能夠對etcd集羣中的全部節點進行讀寫，讀取很是簡單由於每一個節點保存的數據是強一致的。對於寫入來講，etcd集羣中的節點會選舉出Leader節點，若是寫入請求來自Leader節點便可直接寫入而後Leader節點會把寫入分發給全部Follower，若是寫入請求來自其餘Follower節點那麼寫入請求會給轉發給Leader節點，由Leader節點寫入以後再分發給集羣上的全部其餘節點。

下面的圖示中一、3節點都有寫入請求，節點1爲Leader因此3的寫入請求會轉發給1，寫入完成後再同步給全部節點。

如何選舉Leader節點

假設集羣中有三個節點，集羣啓動之初節點中並無被選舉出的Leader。

Raft算法使用隨機Timer來初始化Leader選舉流程。好比說在上面三個節點上都運行了Timer（每一個Timer的持續時間是隨機的），第一個節點率先完成了Timer，隨後它就會向其餘兩個節點發送成爲Leader的請求，其餘節點接收到請求後會以投票迴應而後第一個節點被選舉爲Leader。

成爲Leader後，該節點會以固定時間間隔向其餘節點發送通知，確保本身還是Leader。有些狀況下當Follower們收不到Leader的通知後，好比說Leader節點宕機或者失去了鏈接，其餘節點會重複以前選舉過程選舉出新的Leader。

判斷寫入是否成功

etcd認爲寫入請求被Leader節點處理並分發給了多數節點後，就是一個成功的寫入。如何界定多數節點呢？很簡單，假設總結點數是N，那麼多數節點 Majority=N/2+1，不過在etcd中使用的術語是 Quorum而不是 Majority。因此界定多數節點的公式是 Quorum=N/2+1。

關於節點數的最佳實踐

關於如何肯定etcd集羣應該有多少個節點的問題，上圖的左側的圖表給出了集羣中節點總數(Instances)對應的Quorum數量，用Instances減去Quorom就是集羣中容錯節點（容許出故障的節點）的數量。

因此在集羣中推薦的最少節點數量是3個，由於1和2個節點的容錯節點數都是0，一旦有一個節點宕掉整個集羣就不能正常工做了。

當決定集羣中節點的數量時，強烈推薦奇數數量的節點，好比下圖表中高亮的那幾個選項。

具體來講，6個節點的集羣它的容錯能力並無比5個節點的好，他們的容錯節點數同樣，一旦容錯節點超過2後，因爲Quorum節點數小於4整個集羣也變爲不可用的狀態了。

因此在決定集羣中的節點數時，奇數要優於偶數。

因爲etcd以前接觸的很少網上成體系資料也比較少一開始理解起來有些困難，最近看了很多文章同時偶然在Youtube上發現了一個介紹etcd入門的視頻，以爲很好。文中的圖片大部分都是來自視頻的截圖，推薦能訪問油管的同窗都去看看，比看我這裏的文章更易懂。若是英語聽力不太好的同窗能夠先看看個人文章再去油管上看視頻。

視頻連接 https://www.youtube.com/watch...