為什么用etcd而不用Zookeeper？

官網(wǎng)的一句話

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

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

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

另外在官方的FAQ文檔中

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

etcd 是一個(gè)一致的分布式鍵值存儲。在分布式系統(tǒng)中主要用作單獨(dú)的協(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等項(xiàng)目在開源社區(qū)日益火熱，它們項(xiàng)目中都用到的etcd組件作為一個(gè)高可用、強(qiáng)一致性的服務(wù)發(fā)現(xiàn)存儲倉庫，漸漸為開發(fā)人員所關(guān)注。

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

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

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

• 安全：可選SSL客戶認(rèn)證機(jī)制。

• 快速：每個(gè)實(shí)例每秒支持一千次寫操作。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| 場景三：負(fù)載均衡

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

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

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

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

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

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

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

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

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

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

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

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

| 場景五：分布式鎖

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

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

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

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

| 場景六：分布式隊(duì)列

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

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

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

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

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

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

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

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

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

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

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

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

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

相較之下，Zookeeper有如下缺點(diǎn)：

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

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

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

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

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

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

• 安全。etcd支持SSL客戶端安全認(rèn)證。

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