etcd選型對比
前言
對比 Consul, ZooKeeper。選型etcd有那些好處呢？
基本架構和原理
etcd
ETCD是一個分散式、可靠的key-value儲存的分散式系統，用於儲存分散式系統中的關鍵資料；當然，它不僅僅用於儲存，還提供配置共享及服務發現；基於Go語言實現 。
etcd的特點
完全複製：叢集中的每個節點都可以使用完整的存檔
高可用性：Etcd可用於避免硬體的單點故障或網路問題
一致性：每次讀取都會返回跨多主機的最新寫入
簡單：包括一個定義良好、面向使用者的API（gRPC）
安全：實現了帶有可選的客戶端證書身份驗證的自動化TLS
可靠：使用Raft演算法實現了強一致、高可用的服務儲存目錄
etcd 是基於 raft 演算法實現的，具體的實現可參見etcd實現raft原始碼解讀
Consul
先放一張 consul 的架構圖
consul 使用的是 Gossip 協議
Gossip 中文名稱叫流言協議，它是一種訊息傳播協議。它的核心思想其實源自我們生活中的八卦、閒聊。我們在日常生活中所看到的勁爆訊息其實源於兩類，一類是權威機構如國家新聞媒體釋出的訊息，另一類則是大家通過微信等社交聊天軟體相互八卦，一傳十，十傳百的結果。
Gossip 協議的基本工作原理與我們八卦類似，在 Gossip 協議中，如下圖所示，各個節點會週期性地選擇一定數量節點，然後將訊息同步給這些節點。收到訊息後的節點同樣做出類似的動作，隨機的選擇節點，繼續擴散給其他節點。
Gossip 協議的基本工作原理與我們八卦類似，在 Gossip 協議中，如下圖所示，各個節點會週期性地選擇一定數量節點，然後將訊息同步給這些節點。收到訊息後的節點同樣做出類似的動作，隨機的選擇節點，繼續擴散給其他節點。
最終經過一定次數的擴散、傳播，整個叢集的各個節點都能感知到此訊息，各個節點的資料趨於一致。Gossip 協議被廣泛應用在多個知名專案中，比如 Redis Cluster 叢集版，Apache Cassandra，AWS Dynamo。
Consul 天然支援多資料中心，但是多資料中心內的服務資料並不會跨資料中心同步，各個資料中心的 Server 叢集是獨立的,Consul 提供了 Prepared Query 功能，它支援根據一定的策略返回多資料中心下的最佳的服務例項地址，使你的服務具備跨資料中心容災。
這裡來看下 Prepared Query 查詢的過程：
比如當你的 API 閘道器收到使用者請求查詢 A 服務，API 閘道器服務優先從快取中查詢 A 服務對應的最佳例項。若無快取則向 Consul 發起一個 Prepared Query 請求查詢 A 服務例項，Consul 收到請求後，優先返回本資料中心下的服務例項。如果本資料中心沒有或異常則根據資料中心間 RTT 由近到遠查詢其它資料中心資料，最終閘道器可將使用者請求轉發給最佳的資料中心下的例項地址。
Consul 支援以下三種模式的讀請求：
預設（default）。預設是此模式，絕大部分場景下它能保證資料的強一致性。但在老的 Leader 出現網路分割槽被隔離、新的 Leader 被選舉出來的一個極小時間視窗內，可能會導致 stale read。這是因為 Consul 為了提高讀效能，使用的是基於 Lease 機制來維持 Leader 身份，避免了與其他節點進行互動確認的開銷。
強一致性（consistent）。強一致性讀與 etcd 預設線性讀模式一樣，每次請求需要叢集多數節點確認 Leader 身份，因此相比 default 模式讀，效能會有所下降。
弱一致性（stale)。任何節點都可以讀，無論它是否 Leader。可能讀取到陳舊的資料，類似 etcd 的序列讀。這種讀模式不要求叢集有 Leader，因此當叢集不可用時，只要有節點存活，它依然可以響應讀請求。
ZooKeeper
ZooKeeper 是一個典型的分散式資料一致性解決方案，分散式應用程式可以基於 ZooKeeper 實現諸如資料釋出/訂閱、負載均衡、命名服務、分散式協調/通知、叢集管理、Master 選舉、分散式鎖和分散式佇列等功能。
ZooKeeper 的有點：
順序一致性： 從同一客戶端發起的事務請求，最終將會嚴格地按照順序被應用到 ZooKeeper 中去。
原子性： 所有事務請求的處理結果在整個叢集中所有機器上的應用情況是一致的，也就是說，要麼整個叢集中所有的機器都成功應用了某一個事務，要麼都沒有應用。
單一系統映像 ： 無論客戶端連到哪一個 ZooKeeper 伺服器上，其看到的服務端資料模型都是一致的。
可靠性： 一旦一次更改請求被應用，更改的結果就會被持久化，直到被下一次更改覆蓋。
再來看下 ZooKeeper 的架構圖，圖片摘自etcd實戰課
ZooKeeper 叢集中的所有機器通過一個 Leader 選舉過程來選定一臺稱為 “Leader” 的機器，Leader 既可以為客戶端提供寫服務又能提供讀服務。
除了 Leader 外，Follower 和 Observer 都只能提供讀服務。Follower 和 Observer 唯一的區別在於 Observer 機器不參與 Leader 的選舉過程，也不參與寫操作的“過半寫成功”策略，因此 Observer 機器可以在不影響寫效能的情況下提升叢集的讀效能。
ZooKeeper 使用的是 Zab 協議
ZAB（ZooKeeper Atomic Broadcast 原子廣播） 協議是為分散式協調服務 ZooKeeper 專門設計的一種支援崩潰恢復的原子廣播協議。 在 ZooKeeper 中，主要依賴 ZAB 協議來實現分散式資料一致性，基於該協議，ZooKeeper 實現了一種主備模式的系統架構來保持叢集中各個副本之間的資料一致性。
Zab 協議可以分為以下階段：
Phase 0，Leader 選舉（Leader Election)。一個節點只要求獲得半數以上投票，就可以當選為準 Leader；
Phase 1，發現（Discovery）。準 Leader 收集其他節點的資料資訊，並將最新的資料複製到自身；
Phase 2，同步（Synchronization）。準 Leader 將自身最新資料複製給其他落後的節點，並告知其他節點自己正式當選為 Leader；
Phase 3，廣播（Broadcast）。Leader 正式對外服務，處理客戶端寫請求，對訊息進行廣播。當收到一個寫請求後，它會生成 Proposal 廣播給各個 Follower 節點，一半以上 Follower 節點應答之後，Leader 再發送 Commit 命令給各個 Follower，告知它們提交相關提案；
關於 ZAB 中的兩種模式：崩潰恢復和訊息廣播
崩潰恢復
當整個服務框架在啟動過程中，或是當 Leader 伺服器出現網路中斷、崩潰退出與重啟等異常情況時，ZAB 協議就會進人恢復模式並選舉產生新的Leader伺服器。
當選出 leader ,並且完成了上面 Phase 2 的同步過程，就退出崩潰恢復模式
訊息廣播
當準 Leader 將自身最新資料複製給其他落後的節點，並告知其他節點自己正式當選為 Leader。這時候就可以進入廣播模式，當有客戶端進行資料寫入操作的時候，就可以通過廣播模式通知所有的 follower 了。
當叢集中已經有過半的Follower伺服器完成了和Leader伺服器的狀態同步，那麼整個服務框架就可以進人訊息廣播模式了。
選型對比
1、併發原語：etcd 和 ZooKeeper 並未提供原生的分散式鎖、Leader 選舉支援，只提供了核心的基本資料讀寫、併發控制 API，由應用上層去封裝，consul 就簡單多了，提供了原生的支援，通過簡單點命令就能使用；
2、服務發現：etcd 和 ZooKeeper 並未提供原生的服務發現支援，Consul 在服務發現方面做了很多解放使用者雙手的工作，提供了服務發現的框架，幫助你的業務快速接入，並提供了 HTTP 和 DNS 兩種獲取服務方式；
3、健康檢查：consul 的健康檢查機制，是一種基於 client、Gossip 協議、分散式的健康檢查機制，具備低延時、可擴充套件的特點。業務可通過 Consul 的健康檢查機制，實現 HTTP 介面返回碼、記憶體乃至磁碟空間的檢測，相比 etcd、ZooKeeper 它們提供的健康檢查機制和能力就非常有限了；
etcd 提供了 Lease 機制來實現活性檢測。它是一種中心化的健康檢查，依賴使用者不斷地傳送心跳續租、更新 TTL
ZooKeeper 使用的是一種名為臨時節點的狀態來實現健康檢查。當 client 與 ZooKeeper 節點連線斷掉時，ZooKeeper 就會刪除此臨時節點的 key-value 資料。它比基於心跳機制更復雜，也給 client 帶去了更多的複雜性，所有 client 必須維持與 ZooKeeper server 的活躍連線並保持存活。
4、watch 特性：相比於 etcd , Consul 儲存引擎是基於Radix Tree實現的，因此它不支援範圍查詢和監聽，只支援字首查詢和監聽，而 etcd 都支援, ZooKeeper 的 Watch 特性有更多的侷限性，它是個一次性觸發器;
5、線性讀。etcd 和 Consul 都支援線性讀，而 ZooKeeper 並不具備。
6、許可權機制比較。etcd 實現了 RBAC 的許可權校驗，而 ZooKeeper 和 Consul 實現的 ACL。
7、事務比較。etcd 和 Consul 都提供了簡易的事務能力，支援對欄位進行比較，而 ZooKeeper 只提供了版本號檢查能力，功能較弱。
8、多資料中心。在多資料中心支援上，只有 Consul 是天然支援的，雖然它本身不支援資料自動跨資料中心同步，但是它提供的服務發現機制、Prepared Query功能，賦予了業務在一個可用區後端例項故障時，可將請求轉發到最近的資料中心例項。而 etcd 和 ZooKeeper 並不支援。
總結
總的看下來，consul 提供了原生的分散式鎖、健康檢查、服務發現機制支援，讓業務可以更省心，同時也對多資料中心進行了支援；
當然 etcd 和 ZooKeeper 也都有相應的庫，也能很好的進行支援，但是這兩者不支援多資料中心；
ZooKeeper 在 Java 業務中選型使用的較多，etcd 因為是 go 語言開發的，所以如果本身就是 go 的技術棧，使用這個也是個不錯的選擇，Consul 在國外應用比較多，中文文件及實踐案例相比 etcd 較少；
參考
【服務發現框架選型: Consul、Zookeeper還是etcd ？】https://www.cnblogs.com/sunsky303/p/11127324.html
【23 | 選型：etcd/ZooKeeper/Consul等我們該如何選擇？】https://time.geekbang.org/column/article/351898
【服務發現比較】https://developer.aliyun.com/article/759139
【ZooKeeper講解】https://juejin.cn/post/6844903677367418893
【ETCD對比Consul和zooKeeper如何選型】https://boilingfrog.github.io/2021/09/16/etcd對比consul和zooKeeper/