《云計(jì)算技術(shù)系列叢書 云原生分布式存儲基石： etcd深入解析》—2為什么使用etcd

第二部分

實(shí)戰(zhàn)篇

本部分著重講解etcd的常見功能及使用場景，包括etcd的架構(gòu)分析、命令行使用、API調(diào)用、運(yùn)維部署等內(nèi)容，主要包括以下章節(jié)：

第2章　為什么使用etcd

第3章　etcd初體驗(yàn)

第4章　etcd開放API之v2

第5章　etcd開放API之v3

第6章　etcd集群運(yùn)維與穩(wěn)定性

第7章　etcd安全

第2章

為什么使用etcd

開發(fā)分布式系統(tǒng)是一件比較困難的事情，其中的困難主要體現(xiàn)在分布式系統(tǒng)的“部分失敗”上。“部分失敗”是指信息在網(wǎng)絡(luò)的兩個(gè)節(jié)點(diǎn)之間傳送的時(shí)候，網(wǎng)絡(luò)出現(xiàn)了故障，發(fā)送者無法知道接收者是否收到了這個(gè)信息，而且導(dǎo)致這種故障的原因很復(fù)雜，接收者可能在出現(xiàn)網(wǎng)絡(luò)錯(cuò)誤之前就已經(jīng)收到了信息，也可能沒有收到，又或者接收者的進(jìn)程結(jié)束而沒能接收。

現(xiàn)代的鍵值（Key-Value）存儲系統(tǒng)都是分布式的，ZooKeeper是其中歷史最悠久的項(xiàng)目之一，它起源于Hadoop。

ZooKeeper的主要優(yōu)勢是其具有成熟、健壯以及豐富的特性，然而，它也有自己的缺點(diǎn)，具體體現(xiàn)在如下幾個(gè)方面。

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

Java編寫。這里不是對Java有偏見，而是Java本身就偏向重型應(yīng)用，它會引入大量的依賴。而運(yùn)維人員則普遍希望機(jī)器集群能盡可能地簡單，維護(hù)起來也不容易出錯(cuò)。另外，它對資源的占用也非常高，這一點(diǎn)下面會有實(shí)際數(shù)據(jù)的說明。

發(fā)展緩慢。Apache基金會項(xiàng)目特有的“Apache Way”在開源界飽受爭議，其中一大原因就是由于基金會龐大的結(jié)構(gòu)和松散的管理導(dǎo)致項(xiàng)目發(fā)展緩慢。這一點(diǎn)在對比GitHub和etcd項(xiàng)目的star、fork和release的數(shù)據(jù)時(shí)就一目了然。

現(xiàn)在，我們有了更好的選擇—etcd。與ZooKeeper相比，它更簡單，安裝、部署和使用更加容易，并且etcd的某些功能是ZooKeeper所沒有的。因此，在很多場景下，etcd比ZooKeeper更受用戶的青睞，具體表現(xiàn)在如下幾個(gè)方面。

etcd更加穩(wěn)定可靠，它的唯一目標(biāo)就是把分布式一致性KV存儲做到極致，所以它更注重穩(wěn)定性和擴(kuò)展性。

在服務(wù)發(fā)現(xiàn)的實(shí)現(xiàn)上，etcd使用的是節(jié)點(diǎn)租約（Lease），并且支持Group（多key）；而ZooKeeper使用的是臨時(shí)節(jié)點(diǎn)，臨時(shí)節(jié)點(diǎn)存在不少的問題，這些問題后面會提到。

etcd支持穩(wěn)定的watch，而不是ZooKeeper一樣簡單的單次觸發(fā)式（one time trigger）watch。因?yàn)樵谖磥砦⒎?wù)的環(huán)境下，通過調(diào)度系統(tǒng)的調(diào)度，一個(gè)服務(wù)隨時(shí)可能會下線，也可能為應(yīng)對臨時(shí)訪問壓力而增加新的服務(wù)節(jié)點(diǎn)，而很多調(diào)度系統(tǒng)是需要得到完整節(jié)點(diǎn)歷史記錄的，在這方面，etcd可以存儲數(shù)十萬個(gè)歷史變更。

etcd支持MVCC（多版本并發(fā)控制），因?yàn)橛袇f(xié)同系統(tǒng)需要無鎖操作。

etcd支持更大的數(shù)據(jù)規(guī)模，支持存儲百萬到千萬級別的key。

相比ZooKeeper，etcd的性能更好。在一個(gè)由3臺8核節(jié)點(diǎn)組成的云服務(wù)器上，etcd v3版本可以做到每秒數(shù)萬次的寫操作和數(shù)十萬次的讀操作。

etcd這個(gè)名字由兩部分組成：etc和d，即UNIX/Linux操作系統(tǒng)的“/etc”目錄和分布式（distributed）首字母的“d”。我們都知道，/etc目錄一般用于存儲UNIX/Linux操作系統(tǒng)的配置信息，因此etc和d合起來就是一個(gè)分布式的/etc目錄。由此可見，etcd的寓意是為大規(guī)模分布式系統(tǒng)存儲配置信息。

etcd是由一家位于舊金山的初創(chuàng)公司CoreOS公司（現(xiàn)已被Red Hat收購）于2013年6月發(fā)起的開源項(xiàng)目，旨在構(gòu)建一個(gè)高可用的分布式鍵值（key-value）存儲系統(tǒng)。CoreOS系統(tǒng)通過etcd來解決分布式系統(tǒng)配置信息共享、服務(wù)發(fā)現(xiàn)等問題。目前etcd托管在GitHub上，倉庫地址為github.com/coreos/etcd。etcd作為一個(gè)相對較新的項(xiàng)目，在本書出版之際已有超過15 000的star數(shù)，超過3000的fork數(shù)，超過100的release版本數(shù)，社區(qū)非常活躍。

熟悉Cloud Foundry和Kubernetes的讀者必定都聽說過etcd。谷歌的開源集群容器管理軟件Kubernetes和Pivotal的開源PaaS軟件Cloud Foundry不約而同地都使用了etcd，它們都依賴etcd來進(jìn)行集群管理。

CoreOS的前CEO Alex Polvi曾說過，etcd是Chubby的開源實(shí)現(xiàn)，Chubby是谷歌為處理分布式系統(tǒng)中的一致性問題而開發(fā)的基于Paxos協(xié)議的分布式鎖系統(tǒng)。

CoreOS的前etcd項(xiàng)目主管Blake Mizerany在他的一篇博客中解釋道：“分布式系統(tǒng)集群管理是一項(xiàng)復(fù)雜的業(yè)務(wù)，etcd通過創(chuàng)建一個(gè)hub跟蹤一個(gè)集群中每個(gè)節(jié)點(diǎn)的狀態(tài)并管理這些狀態(tài)，將會使得這項(xiàng)工作變得簡單易行。etcd會復(fù)制集群中所有節(jié)點(diǎn)的狀態(tài)數(shù)據(jù)，防止單個(gè)節(jié)點(diǎn)故障影響整個(gè)組”。

那么，etcd到底是什么？下面就讓我們一探究竟。

2.1　etcd是什么

etcd的官方定義如下：

A highly-available key value store for shared configuration and service discovery.

很多人看到上述官方定義的第一反應(yīng)可能是，etcd是一個(gè)鍵值存儲倉庫，卻沒有重視官方定義的后半句—用于配置共享和服務(wù)發(fā)現(xiàn)。

也就是說，etcd是一個(gè)Go語言編寫的分布式、高可用的一致性鍵值存儲系統(tǒng)，用于提供可靠的分布式鍵值（key-value）存儲、配置共享和服務(wù)發(fā)現(xiàn)等功能。etcd可以用于存儲關(guān)鍵數(shù)據(jù)和實(shí)現(xiàn)分布式調(diào)度，它在現(xiàn)代化的集群運(yùn)行中能夠起到關(guān)鍵性的作用。本書后面的篇幅中，將會詳細(xì)介紹etcd的應(yīng)用和實(shí)踐，其中會涉及etcd的安裝、部署，API的使用介紹，以及如何對運(yùn)行的etcd集群進(jìn)行監(jiān)控等。

etcd以一致和容錯(cuò)的方式存儲數(shù)據(jù)。分布式系統(tǒng)可以使用etcd實(shí)現(xiàn)一致性鍵值存儲、配置管理、服務(wù)發(fā)現(xiàn)和分布式系統(tǒng)的協(xié)同等功能。常見的etcd使用場景包括：服務(wù)發(fā)現(xiàn)、分布式鎖、分布式數(shù)據(jù)隊(duì)列、分布式通知和協(xié)調(diào)、主備選舉等。

etcd基于Raft協(xié)議，通過復(fù)制日志文件的方式來保證數(shù)據(jù)的強(qiáng)一致性。當(dāng)客戶端應(yīng)用寫一個(gè)key時(shí)，首先會存儲到etcd的Leader上，然后再通過Raft協(xié)議復(fù)制到etcd集群的所有成員中，以此維護(hù)各成員（節(jié)點(diǎn)）狀態(tài)的一致性與實(shí)現(xiàn)可靠性。雖然etcd是一個(gè)強(qiáng)一致性的系統(tǒng)，但也支持從非Leader節(jié)點(diǎn)讀取數(shù)據(jù)以提高性能，而且寫操作仍然需要Leader的支持，所以當(dāng)發(fā)生網(wǎng)絡(luò)分區(qū)時(shí)，寫操作仍可能失敗。etcd實(shí)現(xiàn)了一個(gè)Go語言版的Raft程序庫，并廣泛應(yīng)用于各種項(xiàng)目，除了etcd之外，各項(xiàng)目中還包括docker swarm kit等。

etcd具有一定的容錯(cuò)能力，假設(shè)集群***有n個(gè)節(jié)點(diǎn)，即便集群中（n-1）/2個(gè)節(jié)點(diǎn)發(fā)生了故障，只要剩下的（n+1）/2個(gè)節(jié)點(diǎn)達(dá)成一致，也能操作成功。因此，它能夠有效地應(yīng)對網(wǎng)絡(luò)分區(qū)和機(jī)器故障帶來的數(shù)據(jù)丟失風(fēng)險(xiǎn)。

etcd默認(rèn)數(shù)據(jù)一更新就落盤持久化，數(shù)據(jù)持久化存儲使用WAL（write ahead log，預(yù)寫式日志）格式。WAL記錄了數(shù)據(jù)變化的全過程，在etcd中所有數(shù)據(jù)在提交之前都要先寫入WAL中；etcd的Snapshot（快照）文件則存儲了某一時(shí)刻etcd的所有數(shù)據(jù)，默認(rèn)設(shè)置為每10 000條記錄做一次快照，經(jīng)過快照后WAL文件即可刪除。

分布式 專屬分布式存儲服務(wù)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。