一、Etcd簡介
etcd 是一個分佈式鍵值對存儲系統，由coreos 開發，內部採用 raft 協議作爲一致性算法，用於可靠、快速地保存關鍵數據，並提供訪問。通過分佈式鎖、leader選舉和寫屏障(write barriers)，來實現可靠的分佈式協作。etcd集羣是爲高可用、持久化數據存儲和檢索而準備。
"etcd"這個名字源於兩個想法，即 unix “/etc” 文件夾和分佈式系統"d"istibuted。 “/etc” 文件夾爲單個系統存儲配置數據的地方，而 etcd 存儲大規模分佈式系統的配置信息。因此，"d"istibuted 的 “/etc” ，是爲 “etcd”。
etcd 以一致和容錯的方式存儲元數據。分佈式系統使用 etcd 作爲一致性鍵值存儲系統，用於配置管理、服務發現和協調分佈式工作。使用 etcd 的通用分佈式模式包括領導選舉、分佈式鎖和監控機器活動。
雖然 etcd 也支持單點部署，但是在生產環境中推薦集羣方式部署。由於etcd內部使用投票機制，一般 etcd 節點數會選擇 3、5、7等奇數。etcd 會保證所有的節點都會保存數據，並保證數據的一致性和正確性。
etcd 目前默認使用 2379 端口提供 HTTP API 服務，2380 端口和 peer 通信（這兩個端口已經被 IANA 官方預留給 etcd）。在之前的版本中，可能會分別使用 4001 和 7001，在使用的過程中需要注意這個區別。
二、etcd概念詞彙
Raft：etcd所採用的保證分佈式系統強一致性的算法。
Node：一個Raft狀態機實例。
Member： 一個etcd實例。它管理着一個Node，並且可以爲客戶端請求提供服務。
Cluster：由多個Member構成、可以協同工作的etcd集羣。
Peer：對同一個etcd集羣中另外一個Member的稱呼。
Client： 向etcd集羣發送HTTP請求的客戶端。
WAL：預寫式日誌，etcd用於持久化存儲的日誌格式。
snapshot：etcd防止WAL文件過多而設置的快照，存儲etcd數據狀態。
Proxy：etcd的一種模式，爲etcd集羣提供反向代理服務。
Leader：Raft算法中，通過競選而產生的、處理所有數據提交的節點。
Follower：競選失敗的節點作爲Raft中的從屬節點，爲算法提供強一致性保證。
Candidate：當Follower超過一定時間接收不到Leader的心跳時轉變爲Candidate開始競選。
Term：某個節點成爲Leader到下一次競選時間，稱爲一個Term。
Index：數據項編號。Raft中通過Term和Index來定位數據。
三、etcd優點
etcd作爲一個受到ZooKeeper與doozer啓發而催生的項目，除了擁有與之類似的功能外，更專注於以下四點：
簡單：安裝配置簡單，而且提供了 HTTP API 進行交互，使用也很簡單
安全：支持 SSL 證書驗證
快速：根據官方提供的 benchmark 數據，單實例支持每秒 2k+ 讀操作
可靠：採用 raft 算法，實現分佈式系統數據的可用性和一致性
四、使用案例
4.1CoreOS 的容器 Linux: 在Container Linux上運行的應用程序，獲得自動的不宕機 Linux 內核更新。 容器 Linux 使用locksmith來協調更新。locksmith 在 etcd 上實現分佈式信號量，確保在任何給定時間只有集羣的一個子集重新啓動。
4.2Kubernetes： 將docker集羣的配置信息存儲到etcd中，用於服務發現和集羣管理；etcd 的一致性對於正確安排和運行服務至關重要。Kubernetes API 服務器將羣集狀態持久化在 etcd 中。它使用etcd的 watch API監視集羣，併發布關鍵的配置更改。
4.3 cloudfoundry：使用etcd作爲hm9000的應用狀態信息存等。
五、應用場景
場景一：服務發現（Service Discovery）
場景二：消息發佈與訂閱
場景三：負載均衡
場景四：分佈式通知與協調
場景五：分佈式鎖、分佈式隊列
場景六：集羣監控與Leader競選
六、工作原理
etcd的工作原理圖如下所示：
從etcd的架構圖中我們可以看到，etcd主要分爲四個部分：
第1部分是HTTP Server： 用於處理用戶發送的API請求，以及其它etcd節點的同步與心跳信息請求。
第2部分是Store：用於處理etcd支持的各類功能的事務，包括數據索引、節點狀態變更、監控與反饋、事件處理與執行等等，是etcd對用戶提供的大多數API功能的具體實現。
第3部分是Raft：Raft強一致性算法的具體實現，是etcd的核心。
第4部分是WAL：Write Ahead Log（預寫式日誌），是etcd的數據存儲方式。除了在內存中存有所有數據的狀態以及節點的索引以外，etcd就通過WAL進行持久化存儲。在WAL中，所有的數據提交前都會事先記錄日誌。Snapshot是爲了防止數據過多而進行的狀態快照；Entry表示存儲的具體日誌內容。
通常，一個用戶的請求發送過來，會經由HTTP Server轉發給Store，以進行具體的事務處理。如果涉及到節點修改，則交給Raft模塊進行狀態變更、日誌記錄；然後，再同步給別的etcd節點，以確認數據提交；最後，進行數據提交，再次同步。