官網(wǎng)的一句話

A distributed, reliable key-value store for the most critical data of a distributed system.

翻譯并理解過來就是：一個用于存儲分布式系統(tǒng)中最關(guān)鍵的數(shù)據(jù)的倉庫，它是分布式的、可靠的鍵值對倉庫。

首先它是個數(shù)據(jù)存儲倉庫，它的特性是分布式的、可靠性的，數(shù)據(jù)存儲格式是鍵值對存儲，它主要用于存儲分布式系統(tǒng)中的關(guān)鍵數(shù)據(jù)。

另外在官方的FAQ文檔中

https://etcd.io/docs/v3.5/faq/ 是這么解釋etcd的：

etcd 是一個一致的分布式鍵值存儲。在分布式系統(tǒng)中主要用作單獨的協(xié)調(diào)服務(wù)。并且旨在保存可以完全放入內(nèi)存的少量數(shù)據(jù)。

說明它的數(shù)據(jù)是存在于內(nèi)存的，并且建議存少量數(shù)據(jù)?？吹絽f(xié)調(diào)服務(wù)我們很快會想到Zookeeper，并且Zookeeper也是分布式的高可用的分布式協(xié)調(diào)者，數(shù)據(jù)也是存在于內(nèi)存。那二者有什么區(qū)別呢？下文會講。

隨著CoreOS和Kubernetes等項目在開源社區(qū)日益火熱，它們項目中都用到的etcd組件作為一個高可用、強一致性的服務(wù)發(fā)現(xiàn)存儲倉庫，漸漸為開發(fā)人員所關(guān)注。

在云計算時代，如何讓服務(wù)快速透明地接入到計算集群中，如何讓共享配置信息快速被集群中的所有機器發(fā)現(xiàn)，更為重要的是，如何構(gòu)建這樣一套高可用、安全、易于部署以及響應(yīng)快速的服務(wù)集群，已經(jīng)成為了迫切需要解決的問題。etcd為解決這類問題帶來了福音。

實際上，etcd作為一個受到Zookeeper與doozer啟發(fā)而催生的項目，除了擁有與之類似的功能外，更具有以下4個特點{![引自Docker官方文檔]}。

• 簡單：基于HTTP+JSON的API讓你用curl命令就可以輕松使用。

• 安全：可選SSL客戶認證機制。

• 快速：每個實例每秒支持一千次寫操作。

• 可信：使用Raft算法充分實現(xiàn)了分布式。

隨著云計算的不斷發(fā)展，分布式系統(tǒng)中涉及的問題越來越受到人們重視。受上一篇ZooKeeper應(yīng)用場景匯總（超詳細）一文的啟發(fā)（部分案例引自此文。），我根據(jù)自己的理解也總結(jié)了一些etcd的經(jīng)典使用場景。

值得注意的是，分布式系統(tǒng)中的數(shù)據(jù)分為控制數(shù)據(jù)和應(yīng)用數(shù)據(jù)。使用etcd的場景處理的數(shù)據(jù)默認為控制數(shù)據(jù)，對于應(yīng)用數(shù)據(jù)，只推薦處理數(shù)據(jù)量很小，但是更新訪問頻繁的情況。

| 場景一：服務(wù)發(fā)現(xiàn)

服務(wù)發(fā)現(xiàn)（Service Discovery）要解決的是分布式系統(tǒng)中最常見的問題之一，即在同一個分布式集群中的進程或服務(wù)如何才能找到對方并建立連接。從本質(zhì)上說，服務(wù)發(fā)現(xiàn)就是想要了解集群中是否有進程在監(jiān)聽udp或tcp端口，并且通過名字就可以進行查找和連接。要解決服務(wù)發(fā)現(xiàn)的問題，需要有下面三大支柱，缺一不可。

一個強一致性、高可用的服務(wù)存儲目錄。基于Raft算法的etcd天生就是這樣一個強一致性高可用的服務(wù)存儲目錄。

一種注冊服務(wù)和監(jiān)控服務(wù)健康狀態(tài)的機制。用戶可以在etcd中注冊服務(wù)，并且對注冊的服務(wù)設(shè)置key TTL，定時保持服務(wù)的心跳以達到監(jiān)控健康狀態(tài)的效果。

一種查找和連接服務(wù)的機制。通過在etcd指定的主題下注冊的服務(wù)也能在對應(yīng)的主題下查找到。為了確保連接，我們可以在每個服務(wù)機器上都部署一個proxy模式的etcd，這樣就可以確保能訪問etcd集群的服務(wù)都能互相連接。

圖1所示為服務(wù)發(fā)現(xiàn)示意圖。

下面我們來看一下服務(wù)發(fā)現(xiàn)對應(yīng)的具體應(yīng)用場景。

微服務(wù)協(xié)同工作架構(gòu)中，服務(wù)動態(tài)添加。隨著Docker容器的流行，多種微服務(wù)共同協(xié)作，構(gòu)成一個功能相對強大的架構(gòu)的案例越來越多。透明化的動態(tài)添加這些服務(wù)的需求也日益強烈。

通過服務(wù)發(fā)現(xiàn)機制，在etcd中注冊某個服務(wù)名字的目錄，在該目錄下存儲可用的服務(wù)節(jié)點的IP。在使用服務(wù)的過程中，只要從服務(wù)目錄下查找可用的服務(wù)節(jié)點進行使用即可。微服務(wù)協(xié)同工作如圖2所示。

PaaS平臺中應(yīng)用多實例與實例故障重啟透明化。PaaS平臺中的應(yīng)用一般都有多個實例，通過域名，不僅可以透明地對多個實例進行訪問，而且還可以實現(xiàn)負載均衡。

但是應(yīng)用的某個實例隨時都有可能故障重啟，這時就需要動態(tài)地配置域名解析（路由）中的信息。通過etcd的服務(wù)發(fā)現(xiàn)功能就可以輕松解決這個動態(tài)配置的問題，如圖3所示。

| 場景二：消息發(fā)布與訂閱

在分布式系統(tǒng)中，最為適用的組件間通信方式是消息發(fā)布與訂閱機制。具體而言，即構(gòu)建一個配置共享中心，數(shù)據(jù)提供者在這個配置中心發(fā)布消息，而消息使用者則訂閱他們關(guān)心的主題，一旦相關(guān)主題有消息發(fā)布，就會實時通知訂閱者。通過這種方式可以實現(xiàn)分布式系統(tǒng)配置的集中式管理與實時動態(tài)更新。

應(yīng)用中用到的一些配置信息存放在etcd上進行集中管理。這類場景的使用方式通常是這樣的：應(yīng)用在啟動的時候主動從etcd獲取一次配置信息，同時，在etcd節(jié)點上注冊一個Watcher并等待，以后每次配置有更新的時候，etcd都會實時通知訂閱者，以此達到獲取最新配置信息的目的。

分布式搜索服務(wù)中，索引的元信息和服務(wù)器集群機器的節(jié)點狀態(tài)信息存放在etcd中，供各個客戶端訂閱使用。使用etcd的key TTL功能可以確保機器狀態(tài)是實時更新的。

分布式日志收集系統(tǒng)。這個系統(tǒng)的核心工作是收集分布在不同機器上的日志。收集器通常按照應(yīng)用（或主題）來分配收集任務(wù)單元，因此可以在etcd上創(chuàng)建一個以應(yīng)用（或主題）命名的目錄P，并將這個應(yīng)用（或主題）相關(guān)的所有機器ip，以子目錄的形式存儲在目錄P下，

然后設(shè)置一個遞歸的etcd Watcher，遞歸式地監(jiān)控應(yīng)用（或主題）目錄下所有信息的變動。這樣就實現(xiàn)了在機器IP（消息）發(fā)生變動時，能夠?qū)崟r通知收集器調(diào)整任務(wù)分配。

系統(tǒng)中信息需要動態(tài)自動獲取與人工干預(yù)修改信息請求內(nèi)容的情況。通常的解決方案是對外暴露接口，例如JMX接口，來獲取一些運行時的信息或提交修改的請求。而引入etcd之后，只需要將這些信息存放到指定的etcd目錄中，即可通過HTTP接口直接被外部訪問。

| 場景三：負載均衡

在場景一中也提到了負載均衡，本文提及的負載均衡均指軟負載均衡。在分布式系統(tǒng)中，為了保證服務(wù)的高可用以及數(shù)據(jù)的一致性，通常都會把數(shù)據(jù)和服務(wù)部署多份，以此達到對等服務(wù)，即使其中的某一個服務(wù)失效了，也不影響使用。

這樣的實現(xiàn)雖然會導(dǎo)致一定程度上數(shù)據(jù)寫入性能的下降，但是卻能實現(xiàn)數(shù)據(jù)訪問時的負載均衡。因為每個對等服務(wù)節(jié)點上都存有完整的數(shù)據(jù)，所以用戶的訪問流量就可以分流到不同的機器上。

etcd本身分布式架構(gòu)存儲的信息訪問支持負載均衡。etcd集群化以后，每個etcd的核心節(jié)點都可以處理用戶的請求。所以，把數(shù)據(jù)量小但是訪問頻繁的消息數(shù)據(jù)直接存儲到etcd中也是個不錯的選擇，如業(yè)務(wù)系統(tǒng)中常用的二級代碼表。

二級代碼表的工作過程一般是這樣，在表中存儲代碼，在etcd中存儲代碼所代表的具體含義，業(yè)務(wù)系統(tǒng)調(diào)用查表的過程，就需要查找表中代碼的含義。所以如果把二級代碼表中的小量數(shù)據(jù)存儲到etcd中，不僅方便修改，也易于大量訪問。

利用etcd維護一個負載均衡節(jié)點表。etcd可以監(jiān)控一個集群中多個節(jié)點的狀態(tài)，當有一個請求發(fā)過來后，可以輪詢式地把請求轉(zhuǎn)發(fā)給存活著的多個節(jié)點。類似KafkaMQ，通過Zookeeper來維護生產(chǎn)者和消費者的負載均衡。同樣也可以用etcd來做Zookeeper的工作。

| 場景四：分布式通知與協(xié)調(diào)

這里討論的分布式通知與協(xié)調(diào)，與消息發(fā)布和訂閱有些相似。兩者都使用了etcd中的Watcher機制，通過注冊與異步通知機制，實現(xiàn)分布式環(huán)境下不同系統(tǒng)之間的通知與協(xié)調(diào)，從而對數(shù)據(jù)變更進行實時處理。

實現(xiàn)方式通常為：不同系統(tǒng)都在etcd上對同一個目錄進行注冊，同時設(shè)置Watcher監(jiān)控該目錄的變化（如果對子目錄的變化也有需要，可以設(shè)置成遞歸模式），當某個系統(tǒng)更新了etcd的目錄，那么設(shè)置了Watcher的系統(tǒng)就會收到通知，并作出相應(yīng)處理。

通過etcd進行低耦合的心跳檢測。檢測系統(tǒng)和被檢測系統(tǒng)通過etcd上某個目錄關(guān)聯(lián)而非直接關(guān)聯(lián)起來，這樣可以大大減少系統(tǒng)的耦合性。

通過etcd完成系統(tǒng)調(diào)度。某系統(tǒng)有控制臺和推送系統(tǒng)兩部分組成，控制臺的職責是控制推送系統(tǒng)進行相應(yīng)的推送工作。

管理人員在控制臺做的一些操作，實際上只需要修改etcd上某些目錄節(jié)點的狀態(tài)，而etcd就會自動把這些變化通知給注冊了Watcher的推送系統(tǒng)客戶端，推送系統(tǒng)再做出相應(yīng)的推送任務(wù)。

通過etcd完成工作匯報。大部分類似的任務(wù)分發(fā)系統(tǒng)，子任務(wù)啟動后，到etcd來注冊一個臨時工作目錄，并且定時將自己的進度進行匯報（將進度寫入到這個臨時目錄），這樣任務(wù)管理者就能夠?qū)崟r知道任務(wù)進度。

| 場景五：分布式鎖

因為etcd使用Raft算法保持了數(shù)據(jù)的強一致性，某次操作存儲到集群中的值必然是全局一致的，所以很容易實現(xiàn)分布式鎖。鎖服務(wù)有兩種使用方式，一是保持獨占，二是控制時序。

保持獨占，即所有試圖獲取鎖的用戶最終只有一個可以得到。etcd為此提供了一套實現(xiàn)分布式鎖原子操作CAS（CompareAndSwap）的API。通過設(shè)置prevExist值，可以保證在多個節(jié)點同時創(chuàng)建某個目錄時，只有一個成功，而該用戶即可認為是獲得了鎖。

控制時序，即所有試圖獲取鎖的用戶都會進入等待隊列，獲得鎖的順序是全局唯一的，同時決定了隊列執(zhí)行順序。etcd為此也提供了一套API（自動創(chuàng)建有序鍵），對一個目錄建值時指定為POST動作，這樣etcd會自動在目錄下生成一個當前最大的值為鍵，存儲這個新的值（客戶端編號）。

同時還可以使用API按順序列出所有當前目錄下的鍵值。此時這些鍵的值就是客戶端的時序，而這些鍵中存儲的值可以是代表客戶端的編號。

| 場景六：分布式隊列

分布式隊列的常規(guī)用法與場景五中所描述的分布式鎖的控制時序用法類似，即創(chuàng)建一個先進先出的隊列，保證順序。另一種比較有意思的實現(xiàn)是在保證隊列達到某個條件時再統(tǒng)一按順序執(zhí)行。這種方法的實現(xiàn)可以在/queue這個目錄中另外建立一個/queue/condition節(jié)點。

condition可以表示隊列大小。比如一個大的任務(wù)需要很多小任務(wù)就緒的情況下才能執(zhí)行，每次有一個小任務(wù)就緒，就給這個condition數(shù)字加1，直到達到大任務(wù)規(guī)定的數(shù)字，再開始執(zhí)行隊列里的一系列小任務(wù)，最終執(zhí)行大任務(wù)。

condition可以表示某個任務(wù)在不在隊列。這個任務(wù)可以是所有排序任務(wù)的首個執(zhí)行程序，也可以是拓撲結(jié)構(gòu)中沒有依賴的點。通常，必須執(zhí)行這些任務(wù)后才能執(zhí)行隊列中的其他任務(wù)。

condition還可以表示其它的一類開始執(zhí)行任務(wù)的通知?？梢杂煽刂瞥绦蛑付?，當condition出現(xiàn)變化時，開始執(zhí)行隊列任務(wù)。

| 場景七：集群監(jiān)控與Leader競選

通過etcd來進行監(jiān)控實現(xiàn)起來非常簡單并且實時性強，用到了以下兩點特性。

• 前面幾個場景已經(jīng)提到Watcher機制，當某個節(jié)點消失或有變動時，Watcher會第一時間發(fā)現(xiàn)并告知用戶。

• 節(jié)點可以設(shè)置TTL key，比如每隔30s向etcd發(fā)送一次心跳使代表該節(jié)點仍然存活，否則說明節(jié)點消失。

這樣就可以第一時間檢測到各節(jié)點的健康狀態(tài)，以完成集群的監(jiān)控要求。

另外，使用分布式鎖，可以完成Leader競選。對于一些長時間CPU計算或者使用IO操作，只需要由競選出的Leader計算或處理一次，再把結(jié)果復(fù)制給其他Follower即可，從而避免重復(fù)勞動，節(jié)省計算資源。

Leader應(yīng)用的經(jīng)典場景是在搜索系統(tǒng)中建立全量索引。如果每個機器分別進行索引的建立，不但耗時，而且不能保證索引的一致性。通過在etcd的CAS機制競選Leader，由Leader進行索引計算，再將計算結(jié)果分發(fā)到其它節(jié)點。

| 場景八：為什么用etcd而不用Zookeeper？

閱讀了“ZooKeeper應(yīng)用場景匯總（超詳細）”一文的讀者可能會發(fā)現(xiàn)，etcd實現(xiàn)的這些功能，Zookeeper都能實現(xiàn)。那么為什么要用etcd而非直接使用Zookeeper呢？

相較之下，Zookeeper有如下缺點：

• 復(fù)雜。Zookeeper的部署維護復(fù)雜，管理員需要掌握一系列的知識和技能；而Paxos強一致性算法也是素來以復(fù)雜難懂而聞名于世；另外，Zookeeper的使用也比較復(fù)雜，需要安裝客戶端，官方只提供了java和C兩種語言的接口。

• Java編寫。這里不是對Java有偏見，而是Java本身就偏向于重型應(yīng)用，它會引入大量的依賴。而運維人員則普遍希望機器集群盡可能簡單，維護起來也不易出錯。

• 發(fā)展緩慢。Apache基金會項目特有的“Apache Way”在開源界飽受爭議，其中一大原因就是由于基金會龐大的結(jié)構(gòu)以及松散的管理導(dǎo)致項目發(fā)展緩慢。

而etcd作為一個后起之秀，其優(yōu)點也很明顯。

• 簡單。使用Go語言編寫部署簡單；使用HTTP作為接口使用簡單；使用Raft算法保證強一致性讓用戶易于理解。

• 數(shù)據(jù)持久化。etcd默認數(shù)據(jù)一更新就進行持久化。

• 安全。etcd支持SSL客戶端安全認證。

最后，etcd作為一個年輕的項目，正在高速迭代和開發(fā)中，這既是一個優(yōu)點，也是一個缺點。優(yōu)點在于它的未來具有無限的可能性，缺點是版本的迭代導(dǎo)致其使用的可靠性無法保證，無法得到大項目長時間使用的檢驗。然而，目前CoreOS、Kubernetes和Cloudfoundry等知名項目均在生產(chǎn)環(huán)境中使用了etcd，所以總的來說，etcd值得你去嘗試。