完全搞懂 etcd 系列文章（一）：初識 etcd

0 專輯概述

etcd 是雲原生架構中重要的基礎組件，由 CNCF 孵化託管。etcd 在微服務和 Kubernates 集羣中不只能夠做爲服務註冊於發現，還能夠做爲 key-value 存儲的中間件。算法

《完全搞懂 etcd 系列文章》將會從 etcd 的基本功能實踐、API 接口、實現原理、源碼分析，以及實現中的踩坑經驗等幾方面具體展開介紹 etcd。預計會有 20 篇左右的文章，筆者將會每週持續更新，歡迎關注。數據庫

1 etcd 介紹

etcd 是 CoreOS 團隊於 2013 年 6 月發起的開源項目，它的目標是構建一個高可用的分佈式鍵值(key-value)數據庫。具備如下特色：安全

簡單：安裝配置簡單，並且提供了 HTTP API 進行交互，使用也很簡單
鍵值對存儲：將數據存儲在分層組織的目錄中，如同在標準文件系統中
監測變動：監測特定的鍵或目錄以進行更改，並對值的更改作出反應
安全：支持 SSL 證書驗證
快速：根據官方提供的 benchmark 數據，單實例支持每秒 2k+ 讀操做
可靠：採用 raft 算法，實現分佈式系統數據的可用性和一致性

etcd 採用 Go 語言編寫，它具備出色的跨平臺支持，很小的二進制文件和強大的社區。 etcd 機器之間的通訊經過 Raft 算法處理。服務器

etcd 是一個高度一致的分佈式鍵值存儲，它提供了一種可靠的方式來存儲須要由分佈式系統或機器集羣訪問的數據。它能夠優雅地處理網絡分區期間的 leader 選舉，以應對機器的故障，即便是在 leader 節點發生故障時。微信

從簡單的 Web 應用程序到 Kubernetes 集羣，任何複雜的應用程序均可以從 etcd 中讀取數據或將數據寫入 etcd。markdown

etcd 於 2018 年 12 月正式加入雲原生計算基金會(CNCF，全稱 Cloud Native Computing Foundation)，並由 CNCF 支持。CNCF 是一個廠商中立的基金會、雲原生技術推廣和普及的領導者。網絡

2 使用場景

etcd 比較多的應用場景是用於服務註冊與發現，除此以外，也能夠用於鍵值對存儲，應用程序能夠讀取和寫入 etcd 中的數據。架構

一個簡單的用例是將數據庫鏈接詳細信息或功能標誌存儲在 etcd 中做爲鍵值對。能夠觀察這些值，使咱們的應用在更改時能夠從新配置本身。高級用法是利用 etcd 的一致性保證來實施數據庫 leader 選舉或在一組 follower 之間執行分佈式鎖定。異步

2.1 鍵值對存儲

A highly-available key value store for shared configuration and service discovery.
一個用於配置共享和服務發現的鍵值存儲系統。分佈式

歸根結底，etcd 是一個鍵值存儲的組件，其餘的應用都是基於其鍵值存儲的功能展開。etcd 的存儲有以下特色：

採用kv型數據存儲，通常狀況下比關係型數據庫快。
支持動態存儲(內存)以及靜態存儲(磁盤)。
分佈式存儲，可集成爲多節點集羣。
存儲方式，採用相似目錄結構。
- 只有葉子節點才能真正存儲數據，至關於文件。
- 葉子節點的父節點必定是目錄，目錄不能存儲數據。

etcd leader 的延遲是要跟蹤的最重要的指標，而且內置儀表板具備專用於此的視圖。在咱們的測試中，嚴重的延遲會在羣集內形成不穩定，由於 Raft 的速度僅與大多數機器中最慢的機器同樣快。咱們能夠經過適當地調整羣集來緩解此問題。etcd 已在具備高度可變網絡的雲提供商上進行了預調。

2.2 服務註冊與發現

服務註冊與發現(Service Discovery)要解決的是分佈式系統中最多見的問題之一，即在同一個分佈式集羣中的進程或服務如何才能找到對方並創建鏈接。從本質上說，服務發現就是要了解集羣中是否有進程在監聽 UDP 或者 TCP 端口，而且經過名字就能夠進行查找和連接。

要解決服務發現的問題，須要下面三大支柱，缺一不可。

強一致性、高可用的服務存儲目錄。基於 Raft 算法的 etcd 天生就是這樣一個強一致性、高可用的服務存儲目錄。
一種註冊服務和服務健康情況的機制。用戶能夠在 etcd 中註冊服務，而且對註冊的服務配置 key TTL，定時保持服務的心跳以達到監控健康狀態的效果。
一種查找和鏈接服務的機制。經過在 etcd 指定的主題下注冊的服務業能在對應的主題下查找到。爲了確保鏈接，咱們能夠在每一個服務機器上都部署一個 Proxy 模式的 etcd，這樣就能夠確保訪問 etcd 集羣的服務都可以互相鏈接。

etcd2 中引入的 etcd/raft 庫，是目前最穩定、功能豐富的開源一致性協議之一。做爲 etcd、TiKV、CockcorachDB、Dgraph 等知名分佈式數據庫的核心數據複製引擎，etcd/raft 驅動了超過十萬個集羣，是被最爲普遍採用一致性協議實現之一。etcd3 中引入的多版本控制、事務等功能，大大的簡化了分佈式應用的開發流程，提升了效率和穩定性。通過 5 年的演進，etcd 也已經成爲了各類容器編排系統的默認存儲選項。Kubernetes 是流行的容器平臺，運行在任何環境的 Kubernetes 集羣都依賴 etcd 來提供穩定而可靠的存儲服務。

2.3 消息發佈與訂閱

在分佈式系統中，最適用的一種組件間通訊方式就是消息發佈與訂閱。即構建一個配置共享中心，數據提供者在這個配置中心發佈消息，而消息使用者則訂閱他們關心的主題，一旦主題有消息發佈，就會實時通知訂閱者。經過這種方式能夠作到分佈式系統配置的集中式管理與動態更新。

應用中用到的一些配置信息放到etcd上進行集中管理。這類場景的使用方式一般是這樣：應用在啓動的時候主動從etcd獲取一次配置信息，同時，在etcd節點上註冊一個Watcher並等待，之後每次配置有更新的時候，etcd都會實時通知訂閱者，以此達到獲取最新配置信息的目的。

分佈式搜索服務中，索引的元信息和服務器集羣機器的節點狀態存放在etcd中，供各個客戶端訂閱使用。使用etcd的key TTL功能能夠確保機器狀態是實時更新的。

分佈式日誌收集系統。這個系統的核心工做是收集分佈在不一樣機器的日誌。收集器一般是按照應用（或主題）來分配收集任務單元，所以能夠在etcd上建立一個以應用（主題）命名的目錄P，並將這個應用（主題相關）的全部機器ip，以子目錄的形式存儲到目錄P上，而後設置一個 etcd 遞歸的Watcher，遞歸式的監控應用（主題）目錄下全部信息的變更。這樣就實現了機器IP（消息）變更的時候，可以實時通知到收集器調整任務分配。

系統中信息須要動態自動獲取與人工干預修改信息請求內容的狀況。一般是暴露出接口，例如JMX接口，來獲取一些運行時的信息。引入etcd以後，就不用本身實現一套方案了，只要將這些信息存放到指定的etcd目錄中便可，etcd的這些目錄就能夠經過HTTP的接口在外部訪問。

2.4 分佈式通知與協調

這裏說到的分佈式通知與協調，與消息發佈和訂閱有些類似。在分佈式系統中，最適用的一種組件間通訊方式就是消息發佈與訂閱。即構建一個配置共享中心，數據提供者在這個配置中心發佈消息，而消息使用者則訂閱他們關心的主題，一旦主題有消息發佈，就會實時通知訂閱者。經過這種方式能夠作到分佈式系統配置的集中式管理與動態更新。

這裏用到了etcd中的Watcher機制，經過註冊與異步通知機制，實現分佈式環境下不一樣系統之間的通知與協調，從而對數據變動作到實時處理。實現方式一般是這樣：不一樣系統都在etcd上對同一個目錄進行註冊，同時設置Watcher觀測該目錄的變化（若是對子目錄的變化也有須要，能夠設置遞歸模式），當某個系統更新了etcd的目錄，那麼設置了Watcher的系統就會收到通知，並做出相應處理。

經過etcd進行低耦合的心跳檢測。檢測系統和被檢測系統經過etcd上某個目錄關聯而非直接關聯起來，這樣能夠大大減小系統的耦合性。

經過etcd完成系統調度。某系統有控制檯和推送系統兩部分組成，控制檯的職責是控制推送系統進行相應的推送工做。管理人員在控制檯做的一些操做，其實是修改了etcd上某些目錄節點的狀態，而etcd就把這些變化通知給註冊了Watcher的推送系統客戶端，推送系統再做出相應的推送任務。

經過etcd完成工做彙報。大部分相似的任務分發系統，子任務啓動後，到etcd來註冊一個臨時工做目錄，而且定時將本身的進度進行彙報（將進度寫入到這個臨時目錄），這樣任務管理者就可以實時知道任務進度。

2.5 分佈式鎖

當在分佈式系統中，數據只有一份（或有限制），此時須要利用鎖的技術控制某一時刻修改數據的進程數。與單機模式下的鎖不只須要保證進程可見，分佈式環境下還須要考慮進程與鎖之間的網絡問題。

分佈式鎖能夠將標記存在內存，只是該內存不是某個進程分配的內存而是公共內存如 Redis、Memcache。至於利用數據庫、文件等作鎖與單機的實現是同樣的，只要保證標記能互斥就行。

由於etcd使用Raft算法保持了數據的強一致性，某次操做存儲到集羣中的值必然是全局一致的，因此很容易實現分佈式鎖。鎖服務有兩種使用方式，一是保持獨佔，二是控制時序。

保持獨佔即全部獲取鎖的用戶最終只有一個能夠獲得。etcd爲此提供了一套實現分佈式鎖原子操做CAS（CompareAndSwap）的API。經過設置prevExist值，能夠保證在多個節點同時去建立某個目錄時，只有一個成功。而建立成功的用戶就能夠認爲是得到了鎖。

控制時序，即全部想要得到鎖的用戶都會被安排執行，可是得到鎖的順序也是全局惟一的，同時決定了執行順序。etcd爲此也提供了一套API（自動建立有序鍵），對一個目錄建值時指定爲POST動做，這樣etcd會自動在目錄下生成一個當前最大的值爲鍵，存儲這個新的值（客戶端編號）。同時還可使用API按順序列出全部當前目錄下的鍵值。此時這些鍵的值就是客戶端的時序，而這些鍵中存儲的值能夠是表明客戶端的編號。

3. 小結

本章主要介紹了 etcd 的相關概念，以及 etcd 主要的使用場景。etcd 在分佈式環境中是一個利器，在一致性存儲方面有普遍的應用。下一篇將會具體介紹 etcd 的安裝以及使用的實踐。

優質圖書推薦

歡迎購買筆者的圖書，現已出版上市：

原創不易，但願你們多多支持，期待與各位的交流學習。

訂閱最新文章，歡迎關注個人公衆號

參考

etcd