1. etcd 簡介

etcd 官網定義：

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

即一個用于配置共享和服務發現的鍵值存儲系統。

etcd 是一款分布式存儲中間件，使用 Go 語言編寫，并通過 Raft 一致性算法處理和確保分布式一致性，解決了分布式系統中數據一致性的問題。

而且作為一款分布式、可靠的鍵值存儲組件，etcd 常用于微服務架構中的服務注冊與發現中心，相較于 ZooKeeper 部署更簡單，而且具有數據持久化、支持 SSL 客戶端安全認證的獨特優勢。

etcd 作為一個可信賴的分布式鍵值存儲服務，它能夠為整個分布式集群存儲一些關鍵數據，協助分布式集群的正常運轉。

etcd 可集中管理配置信息。服務端將配置信息存儲于 etcd，客戶端通過 etcd 得到服務配置信息，etcd 監聽配置信息的改變，發現改變通知客戶端。

而 etcd 滿足 CAP 理論中的 CP（一致性和分區容錯性） 指標，由此我們知道，etcd 解決了分布式系統中一致性存儲的問題。

2. etcd 特點

etcd 可以用來構建高可用的分布式鍵值數據庫，總結來說有如下特點。

• 簡單：安裝簡單，且為用戶提供了 HTTP API，使用起來也很簡單；
• 存儲：數據分層存儲在文件目錄中，類似于我們日常使用的文件系統；
• Watch 機制：Watch 指定的鍵、前綴目錄的更改，并對更改時間進行通知；
• 安全通信：支持 SSL 證書驗證；
• 高性能：etcd 單實例可以支持 2K/s 讀操作，官方也有提供基準測試腳本；
• 一致可靠：基于 Raft 共識算法，實現分布式系統內部數據存儲、服務調用的一致性和高可用性；
• Revision 機制：每個 Key 帶有一個 Revision 號，每進行一次事務便加一，因此它是全局唯一的，如初始值為 0，進行一次 Put 操作，Key 的 Revision 變為 1，同樣的操作，再進行一次，Revision 變為 2；換成 Key1 進行 Put 操作，Revision 將變為 3。這種機制有一個作用，即通過 Revision 的大小就可知道寫操作的順序，這對于實現公平鎖，隊列十分有益；
• Lease 機制：即租約機制（TTL，Time To Live），Etcd 可以為存儲的 Key-Value 對設置租約，當租約到期，Key-Value 將失效刪除；同時也支持續約，通過客戶端可以在租約到期之前續約，以避免 Key-Value 對過期失效；此外，還支持解約，一旦解約，與該租約綁定的 Key-Value 將失效刪除；

etcd 是一個實現了分布式一致性鍵值對存儲的中間件，支持跨平臺，etcd 集群中的節點基于 Raft 算法進行通信，Raft 算法保證了微服務實例或機器集群所訪問的數據的可靠一致性。

在分布式系統或者 Kubernetes 集群中，etcd 可以作為服務注冊與發現和鍵值對存儲組件。

3. 應用場景

etcd 在穩定性、可靠性和可伸縮性上表現極佳，同時也為云原生應用系統提供了協調機制。etcd 經常用于服務注冊與發現的場景，此外還有鍵值對存儲、消息發布與訂閱、分布式鎖等場景。

3.1 鍵值對存儲

etcd 是一個用于鍵值存儲的組件，存儲是 etcd 最基本的功能，其他應用場景都建立在 etcd 的可靠存儲上。比如 Kubernetes 將一些元數據存儲在 etcd 中，將存儲狀態數據的復雜工作交給 etcd，Kubernetes 自身的功能和架構就能更加穩定。

3.2 服務注冊與發現

etcd 基于 Raft 算法，能夠有力地保證分布式場景中的一致性。各個服務啟動時注冊到 etcd 上，同時為這些服務配置鍵的 TTL 時間。注冊到 etcd 上面的各個服務實例通過心跳的方式定期續租，實現服務實例的狀態監控。

3.3 消息發布與訂閱

在分布式系統中，服務之間還可以通過消息通信，即消息的發布與訂閱，如下圖所示：

通過構建 etcd 消息中間件，服務提供者發布對應主題的消息，消費者則訂閱他們關心的主題，一旦對應的主題有消息發布，就會產生訂閱事件，消息中間件就會通知該主題所有的訂閱者。

3.4 分布式鎖

分布式系統中涉及多個服務實例，存在跨進程之間資源調用，對于資源的協調分配，單體架構中的鎖已經無法滿足需要，需要引入分布式鎖的概念。etcd 基于 Raft 算法，實現分布式集群的一致性，存儲到 etcd 集群中的值必然是全局一致的，因此基于 etcd 很容易實現分布式鎖。

4. etcd 的核心架構

從上圖可知，etcd 有 etcd Server、gRPC Server、存儲相關的 MVCC 、Snapshot、WAL，以及 Raft 模塊。

其中：

• etcd Server 用于對外接收和處理客戶端的請求；
• gRPC Server 則是 etcd 與其他 etcd 節點之間的通信和信息同步；
• MVCC 即多版本控制，etcd 的存儲模塊，鍵值對的每一次操作行為都會被記錄存儲，這些數據底層存儲在 BoltDB 數據庫中；
• WAL 預寫式日志，etcd 中的數據提交前都會記錄到日志；
• Snapshot 快照，以防 WAL 日志過多，用于存儲某一時刻 etcd 的所有數據；
• Snapshot 和 WAL 相結合，etcd 可以有效地進行數據存儲和節點故障恢復等操作；

雖然 etcd 內部實現機制復雜，但對外提供了簡單的 API 接口，方便客戶端調用。我們可以通過 etcdctl 客戶端命令行操作和訪問 etcd 中的數據，或者通過HTTP API 接口直接訪問 etcd。

etcd 中的數據結構很簡單，它的數據存儲其實就是鍵值對的有序映射。etcd 還提供了一種鍵值對監測機制，即 Watch 機制，客戶端通過訂閱相關的鍵值對，獲取其更改的事件信息。Watch 機制實時獲取 etcd 中的增量數據更新，使數據與 etcd 同步。

etcd 目前有 V2.x 和 V3.x 兩個大版本。etcd V2 和 V3 是在底層使用同一套 Raft 算法的兩個獨立應用，但相互之間實現原理和使用方法上差別很大，接口不一樣、存儲不一樣，兩個版本的數據互相隔離。

至于由 etcd V2 升級到 etcd V3 的情況，原有數據只能通過 etcd V2 接口訪問，V3 接口創建的數據只能通過新的 V3 的接口訪問。

etcd 架構圖：
通常，etcd 會監聽兩個端口，默認是 2379 端口和 2380 端口。其中，2380 端口用于集群內部通信，主要涉及集群間數據同步、心跳、選舉等。2379 端口用于與客戶端通信，比如接收客戶端發起的讀/寫數據請求。

etcd 節點在部署的時候有兩種運行模式：集群模式和代理模式。

當 etcd 節點以集群模式運行時，它會加入已有集群中，作為集群的一部分。也就是說，后續的心跳、數據同步、選舉等它都會參與。

集群模式中的節點數一般采用奇數個。為什么呢？因為假如同時有兩個 Candidate 發起選舉，如果是偶數節點的話，可能存在兩個 Candidate 獲得相同票數。

這會導致什么問題？如果兩個 Candidate 票數一樣，就需要再次發起選舉，而再次發起選舉還是有一定概率出現票數一樣，這會導致選舉耗時較多，影響穩定性。所以，采用奇數個節點，能有效降低票數一樣的概率，提升選舉的效率。另外，使用奇數節點來部署，也能讓 etcd 很好地處理分區容錯問題。

當某個 etcd 節點以代理模式運行時，該節點負責將接收到的請求轉發給 etcd 集群節點。目前 etcd 接口有 v2 和 v3 兩個版本，其中 v2 是 HTTP 接口，v3 是 gRPC 接口。需要注意的是，代理模式只支持轉發 v2 版本的請求，也就是只支持轉發 HTTP 請求。

不過，由于 etcd v3 接口在性能、安全、穩定性等方面要比 v2 接口優秀很多，新項目傾向于使用 v3 接口，老項目也逐漸從 v2 接口遷移到 v3 接口。也就是說，代理模式以后可能逐漸被淘汰掉。

5. 分布式中的 CAP 理論

CAP 原理是描述分布式系統下節點數據同步的基本定理，分別指

• Consistency（一致性）

指數據一致性，表示一個系統的數據信息（包括備份數據）在同一時刻都是一致的。在分布式系統下，同一份數據可能存在于多個不同的實例中，在數據強一致性的要求下，修改其中一份數據后必須同步到它的所有備份中。在數據同步的任何時候，都需要保證所有對該份數據的請求將返回同樣的狀態。

• Availability（可用性）

指服務可用性，要求服務在接收到客戶端請求后，都能夠給出響應。服務可用性考量的是系統的可用性，要求系統在高并發情況和部分節點宕機的情況下，系統整體依然能夠響應客戶端的請求。

• Partition tolerance（分區容錯性）

指分區容忍性。在分布式系統中，不同節點之間通過網絡進行通信。由于網絡的不可靠性，位于不同網絡分區的服務節點可能會通信失敗，如果系統能夠容忍這種情況，說明它是滿足分區容忍性的。如果系統不能滿足，將會限制分布式系統的擴展性，即服務節點的部署數量和地區都會受限，也就違背了分布式系統設計的初衷，所以一般來說分布式系統都會滿足分區容忍性。

這三個要素最多只能同時實現兩點，不能三者兼顧。

基于分布式系統的基本特質，P（分區容錯性）是必須要滿足的，所以接下來需要考慮滿足 C（一致性）還是 A（可用性）。

但是在滿足了分區容忍性的前提下，分布式系統并不能同時滿足數據一致性和服務可用性。

假設服務 A 現在有兩個實例 A1 和 A2，它們之間的網絡通信出現了異常，基于分區容忍性，這并不會影響 A1 和 A2 獨立的正常運行。假如此時客戶端請求 A1，請求將數據 B 從 B1 狀態修改為 B2，由于網絡的不可用，數據 B 的修改并不能通知到實例 A2。

如果此時另一個客戶端向 A2 請求數據 B，如果 A2 返回數據 B1，將滿足服務可用性，但并不能滿足數據一致性；如果A2 等待 A1 的通知后才返回數據 B 的正確狀態，雖然滿足了數據一致性，但并不能響應客戶端請求，違背了服務可用性的指標。

在類似銀行之類對金額數據要求強一致性的系統中，要優先考慮滿足數據一致性；而在大眾網頁之類的系統中，用戶對網頁版本的新舊不會有特別的要求，在這種場景下服務可用性會高于數據一致性。

6. 常用術語

7. 分布式原理

7.1 客戶端

當 RPC 服務部署在多個節點上時，客戶端得到的是一個服務列表，有多個 IP 端口對。客戶端的連接池可以隨機地挑選任意的 RPC 服務節點進行連接。

每個服務節點應該有個權重值，當所有節點的權重值一樣時，它們的流量分配就是均勻的。如果某個節點的相對權重值較小，它被客戶端選中的概率也會相對比較小。

class RPCNode {String addr;  // 服務地址int weight; // 節點權重
}class RPCCluster {RPCNode[] nodes; // 節點列表Node random(); // 按權重隨機挑選節點
}

7.2 容災

當有一個服務節點掛掉時，客戶端需要采取一定的策略避免請求失敗。當請求失敗時，客戶端還要進行重試，但是也不可以無限重試，要有一定的重試策略。

比如當節點掛掉時，將失效節點摘除，放置到失效節點列表中。然后每隔一段時間檢查失效節點是否恢復了，如果恢復了，那就從失效節點中移除，再將節點地址重新加入到有效節點列表中。那如何判斷節點真的掛掉了呢，一般需要設置一個時間窗口，統計在一定時間窗口里出現的錯誤數量。如果這個數量過大，那就意味著失效了。這也是為了防止網絡偶然抖動導致服務節點流量的大幅波動。

7.3 降權法

上面提到客戶端會為每個節點賦予一個權值，改變權值就可以改變節點的相對流量。如果某個節點出現了一次調用錯誤，可以對該節點進行降權。如果錯誤次數過多，降權會降的很快，最終達到一個最小值。之所以不應該降到零，那是為了給節點提供一個恢復的機會。被降權的節點后來只要有一次調用成功，那么 weight 值就應該盡快被還原，這樣節點就可以快速恢復為正常節點。

客戶端一次調用失敗會嘗試重試。如果降權太慢，會導致重試次數太多，因為第二次隨機挑選節點時還是很有可能再次挑選到失效節點。降權太快也不好，網絡抖動會導致節點流量分配的快速抖動，瞬間從正常降到近零，又可以瞬間從近零恢復到正常。

一個簡單的策略是權重減半法。錯誤一次權重減半，連續錯誤兩次權重就降到 1/4，如此直到降到最小值。如果初始權重值是 1024，那么權重值就會逐漸衰減1024=>512=>256=>128=>64=>32=>16=>8=>4=>2=>1。如果節點恢復了，那么調用會成功，權重就可以直接恢復到正常值，也可以通過加倍法逐漸恢復到正常值1=>2=>4=>8=>16=>32=>64=>128=>256=>512=>1024。如果希望恢復的更快一點，可以通過乘 4 法，乘 8 法。

7.4 服務發現

健壯的服務應該是可以支持動態擴容的服務。比如 RPC 服務壓力過大，希望通過增加節點的方式來減小單個 RPC 服務的壓力。如果使用的是前面的靜態 RPC 服務地址列表，那么當節點增加時，我們需要修改客戶端的配置重啟才能生效。

通過服務發現技術，當 RPC 服務節點增加或減少時，客戶端可以動態快速收到服務列表的變更信息，從而可以實時調整連接配置，這樣無需重啟就可以完成服務的擴容和縮容。

class ServiceDiscovery(object):def register_service(self, name, addr):passdef get_services(self, name):passdef on_services_changed(self, name):pass

服務發現技術依賴于服務之間的特殊中間節點。這個節點的作用就是接受服務的注冊，提供服務的查找，以及服務列表變更的實時通知功能。它一般使用支持高可用的分布式配置數據庫作為解決方案，如 zookeeper/etcd 等。

• 服務注冊——服務節點在啟動時將自己的服務地址注冊到中間節點
• 服務查找——客戶端啟動時去中間節點查詢服務地址列表
• 服務變更通知——客戶端在中間節點上訂閱依賴服務列表的變更事件。當依賴的服務列表變更時，中間節點負責將變更信息實時通知給客戶端。

總結

以上是生活随笔為你收集整理的etcd 笔记（01）— etcd 简介、特点、应用场景、常用术语、分布式 CAP 理论、分布式原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。