etcd -> Highly-avaliable key value store for shared configuration and service discovery

The name "etcd" originated from two ideas, the unix "/etc" folder and "d"istributed systems. The "/etc" folder is a place to store configuration data for a single system whereas etcd stores configuration information for large scale distributed systems. Hence, a "d"istributed "/etc" is "etcd".

 

Overview

　　etcd is a distributed key value store that provides a reliable way to store data across a cluster of machines. It's open-source and avaliable on GitHub.etcd gracefully handles leader elections during network partitions and will tolerate machine failure, including the leader.

　　your applications can read and write data into etcd. A simple use-case is to store database connection details or feature flags in etcd as key value pairs. these values can be watched, allowing your app to reconfigure itself when they change. advanced uses take advantage of the consistency guarantees to implement database leader elections or do distributed locking across a cluster of workers.

 

Use cases

　　Kubernets stores configuration data into etcd for service discovery and cluster management; etcd's consistency is crucial for correctly scheduling and operating services. The Kubernetes API server persists cluster state into etcd. It uses etcd's watch API to monitor the cluster and roll out critical configuration changes.　　

 

Features

• 簡單：基於Http+Json的API讓你用curl命名便可輕鬆使用，使用Go語言編寫部署簡單。
• 安全：可選SSL客戶認證機制。
• 快速：每一個實例每秒支持1000次寫操做。
• 可信：使用Raft算法充分實現了分佈式。

架構

　　

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

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

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

 

場景1. Service Discovery

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

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

 

　　微服務協同工做架構中，服務動態添加。隨着Docker容器的流行，多種微服務共同協做，構成一個相對功能強大的架構的案例愈來愈多。透明化的動態添加這些服務的需求也日益強烈。經過服務發現機制，在etcd中註冊某個服務名字的目錄，在該目錄下存儲可用的服務節點的IP。在使用服務的過程當中，只要從服務目錄下查找可用的服務節點去使用便可。

 

場景二：消息發佈與訂閱

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

 

場景三：分佈式通知與協調

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

場景四：分佈式鎖

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

• 保持獨佔即全部獲取鎖的用戶最終只有一個能夠獲得。etcd爲此提供了一套實現分佈式鎖原子操做CAS（CompareAndSwap）的API。經過設置prevExist值，能夠保證在多個節點同時去建立某個目錄時，只有一個成功。而建立成功的用戶就能夠認爲是得到了鎖。
• 控制時序，即全部想要得到鎖的用戶都會被安排執行，可是得到鎖的順序也是全局惟一的，同時決定了執行順序。etcd爲此也提供了一套API（自動建立有序鍵），對一個目錄建值時指定爲POST動做，這樣etcd會自動在目錄下生成一個當前最大的值爲鍵，存儲這個新的值（客戶端編號）。同時還可使用API按順序列出全部當前目錄下的鍵值。此時這些鍵的值就是客戶端的時序，而這些鍵中存儲的值能夠是表明客戶端的編號。

 

　　

參考資料：

http://www.infoq.com/cn/articles/etcd-interpretation-application-scenario-implement-principle