1. ETCD是什么
ETCD是用於共享配置和服務發現的分布式，一致性的KV存儲系統。該項目目前最新穩定版本為2.3.0. 具體信息請參考[項目首頁]和[Github]。ETCD是CoreOS公司發起的一個開源項目，授權協議為Apache。
提供配置共享和服務發現的系統比較多，其中最為大家熟知的是[Zookeeper]（后文簡稱ZK），而ETCD可以算得上是后起之秀了。在項目實現，一致性協議易理解性，運維，安全等多個維度上，ETCD相比Zookeeper都占據優勢。
2. ETCD vs ZK
本文選取ZK作為典型代表與ETCD進行比較，而不考慮[Consul]項目作為比較對象，原因為Consul的可靠性和穩定性還需要時間來驗證（項目發起方自身服務並未使用Consul, 自己都不用)。
- 一致性協議： ETCD使用[Raft]協議， ZK使用ZAB（類PAXOS協議），前者容易理解，方便工程實現；
- 運維方面：ETCD方便運維，ZK難以運維；
- 項目活躍度：ETCD社區與開發活躍，ZK已經快死了；
- API：ETCD提供HTTP+JSON, gRPC接口，跨平台跨語言，ZK需要使用其客戶端；
- 訪問安全方面：ETCD支持HTTPS訪問，ZK在這方面缺失；
3. ETCD的使用場景
和ZK類似，ETCD有很多使用場景，包括：
- 配置管理
- 服務注冊於發現
- 選主
- 應用調度
- 分布式隊列
- 分布式鎖
4. ETCD讀寫性能
按照官網給出的[Benchmark], 在2CPU，1.8G內存，SSD磁盤這樣的配置下，單節點的寫性能可以達到16K QPS, 而先寫后讀也能達到12K QPS。這個性能還是相當可觀的。
5. ETCD工作原理
ETCD使用Raft協議來維護集群內各個節點狀態的一致性。簡單說，ETCD集群是一個分布式系統，由多個節點相互通信構成整體對外服務，每個節點都存儲了完整的數據，並且通過Raft協議保證每個節點維護的數據是一致的。
如圖所示，每個ETCD節點都維護了一個狀態機，並且，任意時刻至多存在一個有效的主節點。主節點處理所有來自客戶端寫操作，通過Raft協議保證寫操作對狀態機的改動會可靠的同步到其他節點。
ETCD工作原理核心部分在於Raft協議。本節接下來將簡要介紹Raft協議，具體細節請參考其[論文]。
Raft協議正如論文所述，確實方便理解。主要分為三個部分：選主，日志復制，安全性。
5.1 選主
Raft協議是用於維護一組服務節點數據一致性的協議。這一組服務節點構成一個集群，並且有一個主節點來對外提供服務。當集群初始化，或者主節點掛掉后，面臨一個選主問題。集群中每個節點，任意時刻處於Leader, Follower, Candidate這三個角色之一。選舉特點如下：
- 當集群初始化時候，每個節點都是Follower角色；
- 集群中存在至多1個有效的主節點，通過心跳與其他節點同步數據；
- 當Follower在一定時間內沒有收到來自主節點的心跳，會將自己角色改變為Candidate，並發起一次選主投票；當收到包括自己在內超過半數節點贊成后，選舉成功；當收到票數不足半數選舉失敗，或者選舉超時。若本輪未選出主節點，將進行下一輪選舉（出現這種情況，是由於多個節點同時選舉，所有節點均為獲得過半選票）。
-
Candidate節點收到來自主節點的信息后，會立即終止選舉過程，進入Follower角色。
為了避免陷入選主失敗循環，每個節點未收到心跳發起選舉的時間是一定范圍內的隨機值，這樣能夠避免2個節點同時發起選主。
5.2 日志復制
所謂日志復制，是指主節點將每次操作形成日志條目，並持久化到本地磁盤，然后通過網絡IO發送給其他節點。其他節點根據日志的邏輯時鍾(TERM)和日志編號(INDEX)來判斷是否將該日志記錄持久化到本地。當主節點收到包括自己在內超過半數節點成功返回，那么認為該日志是可提交的(committed），並將日志輸入到狀態機，將結果返回給客戶端。
這里需要注意的是，每次選主都會形成一個唯一的TERM編號，相當於邏輯時鍾。每一條日志都有全局唯一的編號。
主節點通過網絡IO向其他節點追加日志。若某節點收到日志追加的消息，首先判斷該日志的TERM是否過期，以及該日志條目的INDEX是否比當前以及提交的日志的INDEX跟早。若已過期，或者比提交的日志更早，那么就拒絕追加，並返回該節點當前的已提交的日志的編號。否則，將日志追加，並返回成功。
當主節點收到其他節點關於日志追加的回復后，若發現有拒絕，則根據該節點返回的已提交日志編號，發生其編號下一條日志。
主節點像其他節點同步日志，還作了擁塞控制。具體地說，主節點發現日志復制的目標節點拒絕了某次日志追加消息，將進入日志探測階段，一條一條發送日志，直到目標節點接受日志，然后進入快速復制階段，可進行批量日志追加。
按照日志復制的邏輯，我們可以看到，集群中慢節點不影響整個集群的性能。另外一個特點是，數據只從主節點復制到Follower節點，這樣大大簡化了邏輯流程。
5.3 安全性
截止此刻，選主以及日志復制並不能保證節點間數據一致。試想，當一個某個節點掛掉了，一段時間后再次重啟，並當選為主節點。而在其掛掉這段時間內，集群若有超過半數節點存活，集群會正常工作，那么會有日志提交。這些提交的日志無法傳遞給掛掉的節點。當掛掉的節點再次當選主節點，它將缺失部分已提交的日志。在這樣場景下，按Raft協議，它將自己日志復制給其他節點，會將集群已經提交的日志給覆蓋掉。
這顯然是不可接受的。
其他協議解決這個問題的辦法是，新當選的主節點會詢問其他節點，和自己數據對比，確定出集群已提交數據，然后將缺失的數據同步過來。這個方案有明顯缺陷，增加了集群恢復服務的時間（集群在選舉階段不可服務），並且增加了協議的復雜度。
Raft解決的辦法是，在選主邏輯中，對能夠成為主的節點加以限制，確保選出的節點已定包含了集群已經提交的所有日志。如果新選出的主節點已經包含了集群所有提交的日志，那就不需要從和其他節點比對數據了。簡化了流程，縮短了集群恢復服務的時間。
這里存在一個問題，加以這樣限制之后，還能否選出主呢？答案是：只要仍然有超過半數節點存活，這樣的主一定能夠選出。因為已經提交的日志必然被集群中超過半數節點持久化，顯然前一個主節點提交的最后一條日志也被集群中大部分節點持久化。當主節點掛掉后，集群中仍有大部分節點存活，那這存活的節點中一定存在一個節點包含了已經提交的日志了。
至此，關於Raft協議的簡介就全部結束了。
6. ETCD使用案例
據公開資料顯示，至少有CoreOS, Google Kubernetes, Cloud Foundry, 以及在Github上超過500個項目在使用ETCD。
7. ETCD接口
ETCD提供HTTP協議，在最新版本中支持Google gRPC方式訪問。具體支持接口情況如下：
- ETCD是一個高可靠的KV存儲系統，支持PUT/GET/DELETE接口；
- 為了支持服務注冊與發現，支持WATCH接口（通過http long poll實現）；
- 支持KEY持有TTL屬性；
- CAS（compare and swap)操作;
- 支持多key的事務操作；
- 支持目錄操作